DRM switches dma_resv to refcounting, fixes i915 busy hang

Christian König has posted the third revision of a large series that turns dma_resv reservation objects into properly reference-counted, dynamically allocated structures across the Linux DRM, DMA-buf, and TTM stack.

Reservation objects sit under GEM buffers and DMA-bufs and track the fences that synchronize GPU and CPU access. For years they were mostly embedded inside the objects that used them, or allocated with pointer-arithmetic tricks. That made sharing one reservation among several GEM objects awkward, forced TTM into delayed-delete workarounds that could resurrect zombie buffers, and limited how DMA-buf could handle contention on map and pin. The new model allocates each dma_resv explicitly, takes and drops references, and frees the object only when the last user is gone. Drivers across amdgpu, i915, Xe, Nouveau, MSM, Panthor, Virtio, and the accelerator side are updated to the new helpers, and GEM private-object init now returns errors instead of BUG_ON on bad sizes.

The same series closes a concrete hang in Intel’s i915. The busy ioctl walked an object’s fences under only the RCU read lock. If the GEM object was destroyed at the same time, fence references were dropped without a replacement fence list ever being installed, so the unlocked iterator spun forever. The fix keeps those fence references alive until after the RCU grace period. König credits Sashiko-bot with spotting the pre-existing bug.

König had long considered full refcounting too invasive given how widely dma_resv is used. He first tried the rewrite with Claude Sonnet 4; the model produced a plausible skeleton but missed many edge cases. Human review and the bot caught the rest, which is what this v3 is meant to address. The result is cleaner ownership for shared reservations, a path to simpler TTM teardown, and one fewer way for userspace to hang the Intel driver.