Re: [PATCH] drm/msm: Fix shrinker deadlock

[Boris Brezillon <boris.brezillon@collabora.com>]

Hi,

On Sat, 9 May 2026 08:34:15 -0700
Rob Clark <rob.clark@oss.qualcomm.com> wrote:

> On Thu, May 7, 2026 at 11:57 PM Daniel J Blueman <daniel@quora.org> wrote:
> >
> > With PROVE_LOCKING on an Snapdragon X1 and VM reclaim pressure, we see:
> >
> > """
> > kswapd0/121 is trying to acquire lock:
> > ffff800080ed3800 (reservation_ww_class_acquire){+.+.}-{0:0}, at:
> >   msm_gem_shrinker_scan (drivers/gpu/drm/msm/msm_gem_shrinker.c:189)
> >
> > but task is already holding lock:
> > ffffbf4ddb44ca40 (fs_reclaim){+.+.}-{0:0}, at:
> >   balance_pgdat (mm/vmscan.c:7236 (discriminator 2))
> >
> > which lock already depends on the new lock.
> >
> > the existing dependency chain (in reverse order) is:
> >  
> > -> #2 (fs_reclaim){+.+.}-{0:0}:  
> > lock_acquire (kernel/locking/lockdep.c:5868 kernel/locking/lockdep.c:5825)
> > fs_reclaim_acquire (mm/page_alloc.c:4325 mm/page_alloc.c:4339)
> > dma_resv_lockdep (drivers/dma-buf/dma-resv.c:798)
> > do_one_initcall (init/main.c:1392)
> > kernel_init_freeable (init/main.c:1454 (discriminator 1) init/main.c:1470
> >   (discriminator 1) init/main.c:1490 (discriminator 1) init/main.c:1703
> >   (discriminator 1))
> > kernel_init (init/main.c:1593)
> > ret_from_fork (arch/arm64/kernel/entry.S:858)
> >  
> > -> #1 (reservation_ww_class_mutex){+.+.}-{4:4}:  
> > lock_acquire (kernel/locking/lockdep.c:5868 kernel/locking/lockdep.c:5825)
> > dma_resv_lockdep (./include/linux/ww_mutex.h:164 (discriminator 1)
> >   drivers/dma-buf/dma-resv.c:791 (discriminator 1))
> > do_one_initcall (init/main.c:1392)
> > kernel_init_freeable (init/main.c:1454 (discriminator 1) init/main.c:1470
> >   (discriminator 1) init/main.c:1490 (discriminator 1) init/main.c:1703
> >   (discriminator 1))
> > kernel_init (init/main.c:1593)
> > ret_from_fork (arch/arm64/kernel/entry.S:858)
> >  
> > -> #0 (reservation_ww_class_acquire){+.+.}-{0:0}:  
> > check_prev_add (kernel/locking/lockdep.c:3165)
> > __lock_acquire (kernel/locking/lockdep.c:3284
> >   kernel/locking/lockdep.c:3908 kernel/locking/lockdep.c:5237)
> > lock_acquire (kernel/locking/lockdep.c:5868 kernel/locking/lockdep.c:5825)
> > drm_gem_lru_scan (./include/linux/ww_mutex.h:163 (discriminator 1)
> >   drivers/gpu/drm/drm_gem.c:1681 (discriminator 1))  
> 
> Your line #s don't quite match mine, but AFAICT this is from the
> ww_acquire_init()
> 
> What I'm unsure about is if this could cause live-lock against another
> operation which requires obtaining both obj and vm locks in a
> potentially different order (which would also be using a
> ww_acquire_ctx ticket to backoff in case of conflicting locking
> order).  It wouldn't deadlock because we don't sleep forever if we do
> sleep, but...
> 
> Possibly we should also be using trylock to also acquire the vm lock,
> but lockdep would still complain as it doesn't know the ticket will be
> only used w/ trylock (unless we did something hacky by using a
> different ww_class?)

FWIW, we started using a ticket in the initial version of the Panthor
shrinker, and ditched it at some point because of these unsolvable lock
ordering issues. It also seems to me that trylock-all-the-way is the
right solution, and if we trylock and back off + immediately move to
the next BO if any lock is already held, the ticket approach is not as
useful, because we're not going to use the retry mechanism provided by
ww_mutex anyway.

It's true that it does the bookkeeping, which simplifies the rollback
procedure, but if you look at the other locks taken in the shrinker
path, they are static (one per-component involved in reclaim) for most
of them, meaning the rollback is pretty straightforward. The only
exception is the VM lock (one per vm_bo in case of shared BOs). In
panthor, we just decided to open-code this rollback logic (see
panthor_gem_try_evict_no_resv_wait() [1]) instead of teaching ww_mutex
about non-blocking locks when a ticket is provided. Not saying this is
the best option, but it works...

Regards,

Boris

[1]https://gitlab.freedesktop.org/drm/misc/kernel/-/blob/drm-misc-next/drivers/gpu/drm/panthor/panthor_gem.c?ref_type=heads#L1425