linux-kernel - Re: [RFC][PATCH] locking/rtmutex: Make sure we wake anything on the wake_q when we release the lock->wait

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20241214184631.GD10560@noisy.programming.kicks-ass.net>
Date: Sat, 14 Dec 2024 19:46:31 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: John Stultz <jstultz@...gle.com>
Cc: LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...hat.com>,
	Will Deacon <will@...nel.org>, Waiman Long <longman@...hat.com>,
	Boqun Feng <boqun.feng@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Bert Karwatzki <spasswolf@....de>, kernel-team@...roid.com
Subject: Re: [RFC][PATCH] locking/rtmutex: Make sure we wake anything on the
 wake_q when we release the lock->wait_lock

On Fri, Dec 13, 2024 at 06:39:45PM -0800, John Stultz wrote:
> On Fri, Dec 13, 2024 at 4:46 AM Peter Zijlstra <peterz@...radead.org> wrote:

> I think all of the calls are tied to the unlock (the one you quoted
> earlier was removed with 82f9cc094975240), so would something like a
> special unlock be reasonable:
>    raw_spin_unlock_irq_and_wake(&lock->wait_lock, wake_q)
> ?

Ha, that's what I started with :-) Then found there's two irq_restore()
variants for raisins and it all turned to shit.