[BUG]: VirtualMemoryResource: four pre-existing defects (grow-rollback access loss, dead fast path, finalizer warnings, handle_type docstring)

[leofang]

Component

cuda.core

What happened?

Four pre-existing defects in VirtualMemoryResource, all found while verifying #2235 (verification details in #2235 (review)); none are introduced by that PR.

1. Rollback of a failed grow loses access grants — if modify_allocation() fails after the old range has been remapped (slow path), the _remap_old rollback restores the mapping at the original address but never re-applies the access descriptors, so the rolled-back buffer faults on its next access until cuMemSetAccess is re-run. Reproduced on main by forcing cuMemSetAccess to fail during a grow. Likely fix: _remap_old should re-apply the resource's access descriptors to the old range (best-effort, matching the remap itself).

2. The grow fast path is dead code — this check compares a CUdeviceptr against a plain int, and CUdeviceptr(x) == x is always False, so modify_allocation() always takes the slow path (full re-reserve + remap, base pointer changes) even when the driver granted the exact contiguous extension address. Fix: compare int(new_ptr).

3. Warning spam after every slow-path grow — the slow path calls buf._clear() so the old buffer's destructor won't double-free, but the destructor still calls deallocate(), emitting Warning: mr.deallocate() failed during Buffer destruction: CUDA_ERROR_INVALID_VALUE at GC after each grow. (Adjacent to the existing TODO referencing Bug in _grow_allocation_fast_path #2049.)

4. handle_type docstring is wrong — the docstring claims posix_fd is "required for cuMemRetainAllocationHandle"; retain works on handle_type=None allocations (verified on driver r595) and the driver documentation has no such restriction.

-- Leo's bot

[aryanputta]

I would like to work on this, starting with defect 2. Happy to fold in the others if you would rather have them as one PR.

Confirming defect 2 against main: cuMemAddressReserve returns new_ptr as a CUdeviceptr, and the check at _virtual_memory_resource.py:268 compares it against a plain int. CUdeviceptr in cuda_bindings/cuda/bindings/driver.pyx defines __int__ and __repr__ but no __eq__ or __richcmp__, so the comparison falls back to identity and is always False. That makes the whole condition always true, and modify_allocation() always takes the slow path with a full re-reserve and remap, even when the driver granted exactly the contiguous extension that was requested. Comparing int(new_ptr) fixes it, as noted in the report.

One thing i say what is a direct consequence which is worth flagging is the fast path has effectively never run, it is untested in practice, so enabling it is a behavior change rather than a pure no-op cleanup. I would pair the fix with a unit test pinning the comparison semantics, that CUdeviceptr(x) == x is False so call sites must go through int(), since that is the failure mode likely to recur at other boundaries, plus a GPU test asserting the buffer's base pointer is preserved across a grow the driver can satisfy contiguously.