From: Tejun Heo Date: Fri, 19 Oct 2012 00:40:30 +0000 (-0700) Subject: Revert "cgroup: Remove task_lock() from cgroup_post_fork()" X-Git-Url: https://git.stricted.de/?a=commitdiff_plain;h=d87838321124061f6c935069d97f37010fa417e6;p=GitHub%2FLineageOS%2Fandroid_kernel_motorola_exynos9610.git Revert "cgroup: Remove task_lock() from cgroup_post_fork()" This reverts commit 7e3aa30ac8c904a706518b725c451bb486daaae9. The commit incorrectly assumed that fork path always performed threadgroup_change_begin/end() and depended on that for synchronization against task exit and cgroup migration paths instead of explicitly grabbing task_lock(). threadgroup_change is not locked when forking a new process (as opposed to a new thread in the same process) and even if it were it wouldn't be effective as different processes use different threadgroup locks. Revert the incorrect optimization. Signed-off-by: Tejun Heo LKML-Reference: <20121008020000.GB2575@localhost> Acked-by: Li Zefan Cc: Frederic Weisbecker Cc: stable@vger.kernel.org --- diff --git a/kernel/cgroup.c b/kernel/cgroup.c index 75aec12c78a0..f24f724620dd 100644 --- a/kernel/cgroup.c +++ b/kernel/cgroup.c @@ -4883,19 +4883,10 @@ void cgroup_post_fork(struct task_struct *child) */ if (use_task_css_set_links) { write_lock(&css_set_lock); - if (list_empty(&child->cg_list)) { - /* - * It's safe to use child->cgroups without task_lock() - * here because we are protected through - * threadgroup_change_begin() against concurrent - * css_set change in cgroup_task_migrate(). Also - * the task can't exit at that point until - * wake_up_new_task() is called, so we are protected - * against cgroup_exit() setting child->cgroup to - * init_css_set. - */ + task_lock(child); + if (list_empty(&child->cg_list)) list_add(&child->cg_list, &child->cgroups->tasks); - } + task_unlock(child); write_unlock(&css_set_lock); } }