[Code Health] A5 RDMA/HNS1825 清理失败后丢失资源所有权与错误状态 #2823

Category

Robustness (potential edge-case failure)

Component

Other (please specify in description)

Description

A5 onboard RDMA/HNS1825 的清理结果没有形成从底层 manager 到 simpler domain owner 的闭环：底层 Finalize 返回失败后仍丢弃资源句柄，析构忽略返回值，simpler 通过 reset 销毁 manager 后继续释放 domain window。这里确认的是源码中的错误传播/所有权缺口；尚未新增硬件故障复现，也不声称已经观察到 UAF、驱动崩溃或特定错误码。

初次发现于 simpler fb63f4c02220ed99a70150409c676711dcdbb418 / PTO-ISA 217bb98952a8f9004b95fe938da97d8d5f68f702。补充核对 #2790 未合并 head 8340261cf1d7d45d4a1eddd54054b9d8eee8f59b 及其 pin f83d4b7e4be0a4ca9805944ae2d9ce8c84e581f7，以下机制仍存在；不将其表述为 #2790 新引入的回归。

具体问题：

1. HNS1825 WorkspaceManager::~WorkspaceManager() 调用 (void)Finalize()，清理失败无法经析构返回 simpler。
2. Finalize() 在 channel destroy 失败后仍继续 memory unregister、endpoint destroy、device-info/notify 内存释放，最后无条件 ResetOwnedState()。
3. DestroyChannels() 在检查返回值之前清空 channel 列表；UnregisterMemory()、DestroyEndpoint()、FreeDeviceInfo() 在确认成功前清空对应句柄/指针。失败后 manager 不能准确表示尚未释放或状态不确定的资源。
4. Init() 部分失败会调用并忽略 Finalize() 的结果；重新 Init 时，旧会话清理失败也只记录日志后继续建立新会话。因此仅在 simpler 外层增加一次显式 Finalize 并检查 bool，并不足以修复底层已经丢失的资源状态。
5. simpler 的 reset_domain_workspaces() 返回 void，通过 unique_ptr reset 销毁 RDMA manager。domain 分配回滚、显式 release 和最终 comm_destroy 都会继续释放外层 window/删除 domain 记录，无法依据真实 RDMA 清理结果保留必要资源。

需要核实 HCOMM 各错误返回是否仍可能保留引用、批量 channel destroy 是否部分成功，以及 endpoint 销毁能否兜底解除引用。当前能确认的是错误与资源状态被丢弃；不能仅根据非零返回值断言一定仍有设备访问，也不能假定非零返回值等于安全释放。

Location

以下链接固定到已补充核对的 #2790 head / ISA pin，避免将未合并 PR 混写成 main：

• simpler reset_domain_workspaces：RDMA unique_ptr reset，不返回清理结果。
• simpler domain 初始化回滚、domain release、comm_destroy。
• PTO-ISA 析构与 Init 回滚、Finalize、各阶段释放实现。

Proposed Fix

• 明确 endpoint、channel、注册内存、notify/device info 和外层 symmetric window 的归属、借用关系、依赖及释放前置条件。L2 host 进程负责实际清理，上层 Worker 协调并接收错误。
• 在 ISA manager / wrapper / simpler 间建立显式且可报告失败的 close/rollback 契约。按 API 错误语义保留未释放或状态不确定的资源记录；成功释放的资源及时退出账本，不默认永久保留全部资源。
• 解除引用未确认时，不继续释放仍可能被依赖的内存；允许继续回收的独立资源必须有契约依据。批量部分成功、重试是否安全、再次 Init 是否允许，都要明确。
• 初始化从第一笔资源取得开始持有完整 owner；修正内部 Init 回滚及重新 Init 的失败传播，避免外层尚未来得及处理就丢失资源。
• simpler 不再只依赖 destructor/reset 作为收尾结果；将状态传播到 domain release、comm_destroy 和 ChipWorker/Python，失败后保留必要 owner，避免后续析构再次执行危险清理。
• 必要时关联独立 ISA 修复/支持项；不能通过只在 simpler 外层检查 bool，声称解决 ISA 内部无条件清空状态的问题。

验收：

• 使用真实 HNS1825 manager + 有状态 HCOMM/ACL mock，逐阶段注入 channel destroy、notify/symmetric memory unregister、endpoint destroy、device memory free 失败，检查操作顺序、剩余 owner 和引用关系。
• 覆盖 endpoint/registration/channel 创建后的部分 Init 失败、内部回滚失败及再次 Init；不以 Init 返回 false 或 workspace size 为 0 推断没有剩余资源。
• 覆盖生产 domain rollback/release/comm_destroy 路径的错误向上传播；不能仅测试独立 helper 或替换掉真实 manager。
• 按实际 API 契约验证重复收尾/部分成功后的行为，无双重释放、无盲目重试、无失去 owner 的未完成清理。
• 正常 allocate/release 循环回收 domain 自有资源，释放一个 domain 不影响其他仍存活 domain；保留既有 run completion/reclamation guards。
• 在具备可用 HNS1825/RoCE 配置的 A5 环境验证正常初始化、传输、domain release 和 Worker close，记录源码/pin/产物。Refactor: separate SDMA, URMA and RDMA workspaces #2790 报告的 A5DT 环境缺少可用 RoCE bootstrap 配置，不能把 SDMA/URMA 正常测试计为 RDMA 验收；无需在共享设备上强行制造驱动故障。

Related: #2787（URMA 生命周期；共用所有权原则，但 HCCL-owned URMA 与 HCOMM-owned RDMA 的机制和修复独立）、#2739 / #2790（多后端 workspace 分离与共存，不代表本问题已修复）。

Priority

High (significant risk, fix soon)