On Mon, 11 May 2026 17:27:13 +0100 Liviu Dudau <[email protected]> wrote:
> On Mon, May 11, 2026 at 09:16:49AM -0700, Rob Clark wrote: > > On Mon, May 11, 2026 at 8:44 AM Boris Brezillon > > <[email protected]> wrote: > > > > > > On Mon, 11 May 2026 06:18:44 -0700 > > > Rob Clark <[email protected]> wrote: > > > > > > > On Fri, May 8, 2026 at 3:41 AM Boris Brezillon > > > > <[email protected]> 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 <[email protected]> > > > > > > > > Reviewed-by: Rob Clark <[email protected]> > > > > > > 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? We can't really do that if we want to keep things bisectable, but I can prepare a version against drm-misc-fixes which wouldn't contain any of the panthor changes, and then ask drm-misc maintainers to backmerge the next -rc into drm-misc-next and fix things up in panthor as part of the backmerge.
