Re: Refcounting dma_resv v3

[Matthew Brost <matthew.brost@intel.com>]

On Thu, Sep 03, 2026 at 03:27:55PM +0200, Christian König wrote:
> Hi everybody,
> 
> The idea of ref-counting dma_resv or ww_mutex came up multiple times from
> different people, but so far at least I have abandoned that as to
> complicated to implement considering how widely used that object is.
> 
> Thanks to AI I gave the task to refcount dma_resv to Claude Sonet 4 just
> to check how horrible it would look like.
> 
> Well turns out that this is actually a cleanup we should most likely aim
> for and I'm really wondering why we haven't done it like this in the
> first place.
> 
> Not only resolves it a bunch of issues with dma_resv instances shared by
> multiple GEM objects (we just recently had a bunch of patches for that on
> the mailing list), but also allows TTM to implement it's delayed delete
> handling without any zombie resurrection or similar hacks and DMA-buf to
> have better contention handling on map/pin in the future.
> 
> v2:
> 
> This patch set here is now the idea full flashed out. I smoke tested it
> with amdgpu, self tests and checked everything with kmemleak and of hand
> it seems to work.
> 
> Patch #1 introduces an interim allocated flag to allow switching users
> over to the new interface one by one. Patch #10 then removes that flag
> again after everything is done.
> 
> v3:
> 
> Well distrusting Sonet proved to be correct. It turned out that the AI

Drive by comment - I generally find Sonet to be very bug prone for
anything beyond simple tasks isolated to perhaps a single file or
function. Multiple times I've started on something with Sonet and it
continually makes mistakes or misunderstands the arch I'm dictating and
just start over with Opus (or another flagship model) and immediately
get better results. This series I believe falls into a category where
Sonet would get things wrong as it is a subsystem level change.

Matt

> missed tons of issues. Most of them are hopefully fixed in this
> iteration of the patch set now.
> 
> Sashiko-bot on the other hand proved to be extremely useful. It not only
> pointed out tons of stuff Sonet missed but also a complicated pre-existing
> bug in i915.
> 
> The first patch in this series is now fixing this i915 bug, I've send
> this to the relevant mainatiners separately and only include it here for
> completeness.
> 
> Please review and comment.
> 
> Cheers,
> Christian.
> 
> 
>