diff options
| author | Peter Zijlstra <peterz@infradead.org> | 2022-02-14 10:16:57 +0100 |
|---|---|---|
| committer | Peter Zijlstra <peterz@infradead.org> | 2022-02-19 11:11:05 +0100 |
| commit | b1e8206582f9d680cff7d04828708c8b6ab32957 (patch) | |
| tree | 75b3f3e6b2a396995b68db17b96efa51b4e499a6 /kernel/fork.c | |
| parent | 754e0b0e35608ed5206d6a67a791563c631cec07 (diff) | |
| download | linux-b1e8206582f9d680cff7d04828708c8b6ab32957.tar.gz | |
sched: Fix yet more sched_fork() races
Where commit 4ef0c5c6b5ba ("kernel/sched: Fix sched_fork() access an
invalid sched_task_group") fixed a fork race vs cgroup, it opened up a
race vs syscalls by not placing the task on the runqueue before it
gets exposed through the pidhash.
Commit 13765de8148f ("sched/fair: Fix fault in reweight_entity") is
trying to fix a single instance of this, instead fix the whole class
of issues, effectively reverting this commit.
Fixes: 4ef0c5c6b5ba ("kernel/sched: Fix sched_fork() access an invalid sched_task_group")
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: Tadeusz Struk <tadeusz.struk@linaro.org>
Tested-by: Zhang Qiao <zhangqiao22@huawei.com>
Tested-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Link: https://lkml.kernel.org/r/YgoeCbwj5mbCR0qA@hirez.programming.kicks-ass.net
Diffstat (limited to 'kernel/fork.c')
| -rw-r--r-- | kernel/fork.c | 13 |
1 files changed, 12 insertions, 1 deletions
diff --git a/kernel/fork.c b/kernel/fork.c index d75a528f7b219..c607d238fc23b 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -2267,6 +2267,17 @@ static __latent_entropy struct task_struct *copy_process( goto bad_fork_put_pidfd; /* + * Now that the cgroups are pinned, re-clone the parent cgroup and put + * the new task on the correct runqueue. All this *before* the task + * becomes visible. + * + * This isn't part of ->can_fork() because while the re-cloning is + * cgroup specific, it unconditionally needs to place the task on a + * runqueue. + */ + sched_cgroup_fork(p, args); + + /* * From this point on we must avoid any synchronous user-space * communication until we take the tasklist-lock. In particular, we do * not want user-space to be able to predict the process start-time by @@ -2376,7 +2387,7 @@ static __latent_entropy struct task_struct *copy_process( write_unlock_irq(&tasklist_lock); proc_fork_connector(p); - sched_post_fork(p, args); + sched_post_fork(p); cgroup_post_fork(p, args); perf_event_fork(p); |