linux-kernel - Re: re. Spurious wakeup on a newly created kthread

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: <Yrn1nQU3h+vHK1nz@google.com>
Date:   Mon, 27 Jun 2022 18:23:25 +0000
From:   Wedson Almeida Filho <wedsonaf@...gle.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     "Eric W. Biederman" <ebiederm@...ssion.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Christian Brauner <brauner@...nel.org>,
        Tejun Heo <tj@...nel.org>, Petr Mladek <pmladek@...e.com>,
        Lai Jiangshan <jiangshanlai@...il.com>,
        Michal Hocko <mhocko@...e.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Oleg Nesterov <oleg@...hat.com>
Subject: Re: re. Spurious wakeup on a newly created kthread

On Mon, Jun 27, 2022 at 09:11:10AM +0200, Peter Zijlstra wrote:
> Current freezer can thaw at random points in time, even before SMP
> bringup if you're unlucky. And yes, I think it can induce 'spurious'
> wakeups as well.

Thanks, Peter, that's good to know!

> But really; like Linus already said upsteam, every wait loop *MUST*
> already be able to deal with spurious wakeups. This is why pretty much
> every wait primitive we have looks like:
> 
> 	for (;;) {
> 		set_current_state(state);
> 		if (cond)
> 			break;
> 		schedule();
> 	}
> 	__set_current_state(RUNNING);
> 
> Which is immune to random wake-ups since it need @cond to make progress.
> *NEVER* rely on just the wakeup itself for progress, that's buggy as
> heck in lots of ways.

Yes, I wonder how many more instances of this kind of bug we have
lurking around given that this one in core kernel code appears to have
been around for at least 17 years.