linux-kernel - Re: [PATCH] sched: remove false-positive warning from wake_up

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]

Date:	Mon, 30 Nov 2015 19:14:02 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Rik van Riel <riel@...hat.com>
Cc:	Sasha Levin <sasha.levin@...cle.com>,
	Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Oleg Nesterov <oleg@...hat.com>
Subject: Re: [PATCH] sched: remove false-positive warning from wake_up_process()

On Mon, Nov 30, 2015 at 6:48 PM, Rik van Riel <riel@...hat.com> wrote:
>
> What would the correct behaviour in that case be?
>
> Does waking up the task while it is being traced, and ptrace
> (or gdb) is not expecting a wakeup, break the tracing?

It would.

We already do the right thing (thanks to that commit 9067ac85d533),
namely just ignore the spurious wakeup.

Basically, all "normal" wait events have to be in a loop around the
event condition because of spurious wakeups like this, and they
already are (ie helpers like "wait_event()" etc do the right thing,
and in general it's actually fairly hard to do the wrong thing).

And special things like TASK_STOPPED now only get woken up by properly
serialized things that are supposed to wake them up.

So we're ok. It's just that the sanity check WARN_ON() was racily too
eager to warn about mis-use. The warning was *meant* to trigger in
case somebody depended on the old broken behavior of
"wake_up_process() wakes up anything" that the code moved away from.
But the warning also triggered for this race condition, that was
actually fixed by the commit in question.

             Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/