Re: Switching over to GEM refcounts and a bunch of cleanups

["Thomas Hellström" <thomas.hellstrom@linux.intel.com>]

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.
> 
>