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 stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html