fix(rocr): Dup dmabuf fd on VMemoryImportShareableHandle for deferred import#8440
Conversation
Co-authored-by: Cursor <cursoragent@cursor.com>
❌ PR Check — Action Required
📖 Need help? See the Policy FAQ for details on every check and how to fix failures. |
|
🚫 Please fix the failed policies before requesting reviews. The following policy checks failed:
The |
|
Errors:
https://github.com/ROCm/rocm-systems/actions/runs/29136101237/job/86515367484?pr=8440#step:11:1800
https://github.com/ROCm/rocm-systems/actions/runs/29136101237/job/86515367476?pr=8440#step:11:1878
https://github.com/ROCm/rocm-systems/actions/runs/29136101237/job/86515367468?pr=8440#step:11:1890
|
|
These errors are not caused by this change: Other PRs with identical Windows ROCR failuresThe same 4/4 shard ROCR failure pattern appears on unrelated open PRs — same platform (
Failure themes are printf, occupancy, memcpy batch, event IPC, RTC, and device allocation — none related to dmabuf fd duplication or deferred VMM import. Conclusion: Windows |
Summary
Re-land the dmabuf fd duplication fix from #8304, which was reverted in #8436 to unblock TheRock R-S bump.
After #6471 deferred per-GPU dmabuf import to
hsa_amd_vmem_set_accesstime,VMemoryImportShareableHandlemust own a dup of the caller's fd so deferred import still works after the caller closes its fd (normal IPC ownership). This restores correct behavior for multi-rank VMM/IPC peer-access flows (e.g. RCCL CE collectives).Also removes
LogPrintfromDmaBufDupon Linux to avoid rocdxg WSL link issues (same pattern as #8436 follow-up).Adds a rocrtst regression test that imports a shareable handle, closes the caller fd before
set_access, and verifies GPU access succeeds.JIRA ID
JIRA ID : ROCM-27777
Test plan
ImportedShareableHandleSetAccessAfterFdCloserocrtst subtest on Linux with VMM supportDmaBufDupMade with Cursor