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@xxxxxxxxxxxxx> AuthorDate: Mon, 21 Dec 2015 18:17:10 +0100 Committer: Ingo Molnar <mingo@xxxxxxxxxx> 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@xxxxxxxxxxxxx> Signed-off-by: Peter Zijlstra (Intel) <peterz@xxxxxxxxxxxxx> Cc: Davidlohr Bueso <dbueso@xxxxxxx> Cc: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx> Cc: Steven Rostedt <rostedt@xxxxxxxxxxx> Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx> Fixes: 7675104990ed ("sched: Implement lockless wake-queues")Shouldn't that go into stable?
Yes, as of v4.2 afaict. Ccing. Thanks, Davidlohr -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|