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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250122103914.GI7145@noisy.programming.kicks-ass.net>
Date: Wed, 22 Jan 2025 11:39:14 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Waiman Long <longman@...hat.com>
Cc: Ingo Molnar <mingo@...hat.com>, Will Deacon <will.deacon@....com>,
	Boqun Feng <boqun.feng@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] locking/semaphore: Use wake_q to wake up processes
 outside lock critical section

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.