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

[Davidlohr Bueso]

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