Re: [PATCH] locking/semaphore: Use wake_q to wake up processes outside lock critical section

[Peter Zijlstra <peterz@infradead.org>]

On Tue, Jan 21, 2025 at 08:13:14PM -0500, Waiman Long wrote:
> A circular lock dependency splat has been seen involving down_trylock().
> 
> [ 4011.795602] ======================================================
> [ 4011.795603] WARNING: possible circular locking dependency detected
> [ 4011.795607] 6.12.0-41.el10.s390x+debug
> [ 4011.795612] ------------------------------------------------------
> [ 4011.795613] dd/32479 is trying to acquire lock:
> [ 4011.795617] 0015a20accd0d4f8 ((console_sem).lock){-.-.}-{2:2}, at: down_trylock+0x26/0x90
> [ 4011.795636]
> [ 4011.795636] but task is already holding lock:
> [ 4011.795637] 000000017e461698 (&zone->lock){-.-.}-{2:2}, at: rmqueue_bulk+0xac/0x8f0
> 
>   the existing dependency chain (in reverse order) is:
>   -> #4 (&zone->lock){-.-.}-{2:2}:
>   -> #3 (hrtimer_bases.lock){-.-.}-{2:2}:
>   -> #2 (&rq->__lock){-.-.}-{2:2}:
>   -> #1 (&p->pi_lock){-.-.}-{2:2}:
>   -> #0 ((console_sem).lock){-.-.}-{2:2}:

The whole #3->#4 thing seems dodgy, where is that? Specifically
hrtimer_bases.lock is a raw_spinlock, while zone->lock is a spinlock,
this is not a valid nesting.