linux-kernel - Re: [tip:sched/core] sched/core: Reset task' s lockless wake-queues on fork()

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] [day] [month] [year] [list]

Date:	Sat, 9 Jan 2016 11:25:17 -0800
From:	Davidlohr Bueso <dave@...olabs.net>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	bigeasy@...utronix.de, peterz@...radead.org,
	linux-kernel@...r.kernel.org, dbueso@...e.de, rostedt@...dmis.org,
	mingo@...nel.org, hpa@...or.com, torvalds@...ux-foundation.org,
	linux-tip-commits@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [tip:sched/core] sched/core: Reset task' s lockless wake-queues
 on fork()

On Fri, 08 Jan 2016, Thomas Gleixner wrote:

>On Wed, 6 Jan 2016, tip-bot for Sebastian Andrzej Siewior wrote:
>
>> Commit-ID:  093e5840ae76f1082633503964d035f40ed0216d
>> Gitweb:     http://git.kernel.org/tip/093e5840ae76f1082633503964d035f40ed0216d
>> Author:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>
>> AuthorDate: Mon, 21 Dec 2015 18:17:10 +0100
>> Committer:  Ingo Molnar <mingo@...nel.org>
>> CommitDate: Wed, 6 Jan 2016 11:01:07 +0100
>>
>> sched/core: Reset task's lockless wake-queues on fork()
>>
>> In the following commit:
>>
>>   7675104990ed ("sched: Implement lockless wake-queues")
>>
>> we gained lockless wake-queues.
>>
>> The -RT kernel managed to lockup itself with those. There could be multiple
>> attempts for task X to enqueue it for a wakeup _even_ if task X is already
>> running.
>>
>> The reason is that task X could be runnable but not yet on CPU. The the
>> task performing the wakeup did not leave the CPU it could performe
>> multiple wakeups.
>>
>> With the proper timming task X could be running and enqueued for a
>> wakeup. If this happens while X is performing a fork() then its its
>> child will have a !NULL `wake_q` member copied.
>>
>> This is not a problem as long as the child task does not participate in
>> lockless wakeups :)

It also makes sense in that a new task has no business inherinting whatever
pending wakeups the parent is involved in. It should get a fresh wake_q.

>>
>> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
>> Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
>> Cc: Davidlohr Bueso <dbueso@...e.de>
>> Cc: Linus Torvalds <torvalds@...ux-foundation.org>
>> Cc: Peter Zijlstra <peterz@...radead.org>
>> Cc: Steven Rostedt <rostedt@...dmis.org>
>> Cc: Thomas Gleixner <tglx@...utronix.de>
>> Fixes: 7675104990ed ("sched: Implement lockless wake-queues")
>
>Shouldn't that go into stable?

Yes, as of v4.2 afaict. Ccing.

Thanks,
Davidlohr