Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1302977 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [tip:sched/core] sched/core: Reset task'  s lockless wake-queues on fork() tip-bot for Sebastian Andrzej Siewior <tipbot@zytor.com> - 2016-01-06 19:50 +0100
    Re: [tip:sched/core] sched/core: Reset task' s lockless wake-queues  on fork() Thomas Gleixner <tglx@linutronix.de> - 2016-01-08 10:50 +0100
      Re: [tip:sched/core] sched/core: Reset task' s lockless wake-queues  on fork() Davidlohr Bueso <dave@stgolabs.net> - 2016-01-09 20:30 +0100

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

Commit-ID:  093e5840ae76f1082633503964d035f40ed0216d
Gitweb:     http://git.kernel.org/tip/093e5840ae76f1082633503964d035f40ed0216d
Author:     Sebastian Andrzej Siewior <bigeasy@linutronix.de>
AuthorDate: Mon, 21 Dec 2015 18:17:10 +0100
Committer:  Ingo Molnar <mingo@kernel.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 :)

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Davidlohr Bueso <dbueso@suse.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: 7675104990ed ("sched: Implement lockless wake-queues")
Link: http://lkml.kernel.org/r/20151221171710.GA5499@linutronix.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 kernel/fork.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/fork.c b/kernel/fork.c
index fce002e..1155eac 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -380,6 +380,7 @@ static struct task_struct *dup_task_struct(struct task_struct *orig)
 #endif
 	tsk->splice_pipe = NULL;
 	tsk->task_frag.page = NULL;
+	tsk->wake_q.next = NULL;
 
 	account_kernel_stack(ti, 1);
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

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

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@linutronix.de>
> AuthorDate: Mon, 21 Dec 2015 18:17:10 +0100
> Committer:  Ingo Molnar <mingo@kernel.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 :)
>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> Cc: Davidlohr Bueso <dbueso@suse.de>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Steven Rostedt <rostedt@goodmis.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Fixes: 7675104990ed ("sched: Implement lockless wake-queues")

Shouldn't that go into stable?

Thanks,

	tglx

[toc] | [prev] | [next] | [standalone]

#1305349 — 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@linutronix.de>
>> AuthorDate: Mon, 21 Dec 2015 18:17:10 +0100
>> Committer:  Ingo Molnar <mingo@kernel.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@linutronix.de>
>> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
>> Cc: Davidlohr Bueso <dbueso@suse.de>
>> Cc: Linus Torvalds <torvalds@linux-foundation.org>
>> Cc: Peter Zijlstra <peterz@infradead.org>
>> Cc: Steven Rostedt <rostedt@goodmis.org>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Fixes: 7675104990ed ("sched: Implement lockless wake-queues")
>
>Shouldn't that go into stable?

Yes, as of v4.2 afaict. Ccing.

Thanks,
Davidlohr

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web