On Tue, 2025-09-09 at 10:13 +0200, Christian König wrote: > On 09.09.25 09:21, Thomas Hellström wrote: > > > > So what do you think about starting out with a fence, and if / > > > > when > > > > that appears not to be sufficient, we have a backup plan to > > > > move to > > > > a > > > > struct completion? > > > > > > Well we need to start somewhere, so grabbing an unsignaled > > > dma_fence > > > reference sounds like the best plan for now. > > > > True. A good starting point. Although I have a feeling it will turn > > out > > to be not fully sufficient. > > Had another sleepiness night because of pain in my joints, but that > got me another idea how to solve this. > > What if the first thread who sees the BO with the zero refcount does > the zombiefication? > > In other words we grab the LRU lock and try to grab a reference to > the BO, if that works we do our current handling. > > If grabbing the BO reference doesn't work we individualize the > dma_resv and turn the BO into a zombie by adjusting the object funcs, > init the reference count to 1 again and eventually schedule the > cleanup worker (e.g. mostly everything currently done in > ttm_bo_release()). > > As far as I can see that should work, only problem might be that we > need to turn the LRU lock into a mutex to be able to alloc memory and > sleep.
Yes that would probably work. It mighte become a little complex, though, and we'd still have to deal with the unorthodox practice of resurrecting a refcount. Turning the LRU lock into a mutex is probably OK as well. Another solution in the other direction is if we allow dma-buf unmapping under a separate lock without holding the dma-resv, with associated slight locking complications. Thanks, Thomas > > Regards, > Christian. > >
