Hi, Christian, On Fri, 2026-07-10 at 20:52 +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. > > The patch set is totally work in progress and only survives a smoke > test > with amdgpu, but I still wanted to check if the idea is valuable and > should be looked in further. > > Please comment and/or tear apart :)
Before starting to look at this, in the spirit of trying to aligning on a "final" solution for ww transactions used in TTM, could we agree on how we are supposed to pass the importer's ww transaction context to the exporter's dma_map_attachment() operation to handle exporter evictions while mapping, because that decides what abstaction we should use for WW transations within TTM. drm_exec_init() xe_bo_validate() // IMporter dma_buf_map() // importer; map_attachment() // callback in exporter xe_bo_validate() // exporter tries to move exportert bo to VRAM but runs out of memory. ttm_bo_evict() // exporter's evict needs importer's drm_exec As mentioned a couple of times before, we can't pass a drm_exec to the exporter because that would make dma-buf depend on drm. So with this series it would be sufficient to move drm_exec to the dma- buf layer and rename it, but I still think we should have a plan. Thanks, Thomas > > Cheers, > Christian.
