Re: [PATCH v2 4/4] drm/gem: Make the GEM LRU lock part of drm_device

[Liviu Dudau <liviu.dudau@arm.com>]

On Mon, May 11, 2026 at 09:16:49AM -0700, Rob Clark wrote:
> On Mon, May 11, 2026 at 8:44 AM Boris Brezillon
> <boris.brezillon@collabora.com> wrote:
> >
> > On Mon, 11 May 2026 06:18:44 -0700
> > Rob Clark <rob.clark@oss.qualcomm.com> wrote:
> >
> > > On Fri, May 8, 2026 at 3:41 AM Boris Brezillon
> > > <boris.brezillon@collabora.com> wrote:
> > > >
> > > > Recently, a few races have been discovered in the GEM LRU logic, all
> > > > of them caused by the fact the LRU lock is accessed through
> > > > gem->lru->lock, and that lock itself also protects changes to
> > > > gem->lru, leading to situations where gem->lru needs to first be
> > > > accessed without the lock held, to then get the lru to access the lock
> > > > through and finally take the lock and do the expected operation.
> > > >
> > > > Currently, the two drivers making use of this API declare device-wide
> > > > locks, and there's no clue that we will ever have a driver that wants
> > > > different pools of LRUs protected by different locks under the same
> > > > drm_device. So we're better off moving this lock to drm_device and
> > > > always locking it through obj->dev->gem_lru_mutex, or directly through
> > > > dev->gem_lru_mutex.
> > > >
> > > > If anyone ever needs more fine-grained locking, this can be revisited
> > > > to pass some drm_gem_lru_pool object represent the pool of LRUs under
> > > > a specific lock, but for now, the per-device lock seems to be enough.
> > > >
> > > > Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
> > >
> > > Reviewed-by: Rob Clark <rob.clark@oss.qualcomm.com>
> >
> > If every one is happy with patch 4, I'm tempted to drop patch 1 and 3,
> > since they are irrelevant if the locking is fixed the way it is in this
> > patch. Question is, do we care about patch 2 being backported to stable
> > kernels then?
> 
> Or backport patch 4?  It's a bit bigger, but mostly mechanical.. with
> only issue being backporting across addition of panthor shrinker, I
> guess?

I'm agreeing with Rob here, but it makes a mess of the backport. Maybe split
patch 4 into the drm_gem.c and msm changes and make another one for panthor,
as that is still in linux-next?

Best regards,
Liviu

> 
> BR,
> -R

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯