* [PATCH 0/2 v2] cgroup: Remove useless task_lock() @ 2011-12-21 2:02 ` Frederic Weisbecker 0 siblings, 0 replies; 22+ messages in thread From: Frederic Weisbecker @ 2011-12-21 2:02 UTC (permalink / raw) To: Tejun Heo, Li Zefan Cc: LKML, Frederic Weisbecker, Containers, Cgroups, KAMEZAWA Hiroyuki, Oleg Nesterov, Andrew Morton, Paul Menage, Mandeep Singh Baines Hi, It's the same set but rebased on top of cgroup/for-3.3 instead of Mandeep's patch. Although the first patch has changed a bit after the rebase I have kept the Reviewed-by tag of Li and Mandeep because the core change itself hasn't changed much. Second patch is the same. Thanks. Frederic Weisbecker (2): cgroup: Remove unnecessary task_lock before fetching css_set on migration cgroup: Drop task_lock(parent) on cgroup_fork() kernel/cgroup.c | 30 +++++++++++++++++------------- 1 files changed, 17 insertions(+), 13 deletions(-) -- 1.7.5.4 ^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 0/2 v2] cgroup: Remove useless task_lock() @ 2011-12-21 2:02 ` Frederic Weisbecker 0 siblings, 0 replies; 22+ messages in thread From: Frederic Weisbecker @ 2011-12-21 2:02 UTC (permalink / raw) To: Tejun Heo, Li Zefan Cc: LKML, Frederic Weisbecker, Containers, Cgroups, KAMEZAWA Hiroyuki, Oleg Nesterov, Andrew Morton, Paul Menage, Mandeep Singh Baines Hi, It's the same set but rebased on top of cgroup/for-3.3 instead of Mandeep's patch. Although the first patch has changed a bit after the rebase I have kept the Reviewed-by tag of Li and Mandeep because the core change itself hasn't changed much. Second patch is the same. Thanks. Frederic Weisbecker (2): cgroup: Remove unnecessary task_lock before fetching css_set on migration cgroup: Drop task_lock(parent) on cgroup_fork() kernel/cgroup.c | 30 +++++++++++++++++------------- 1 files changed, 17 insertions(+), 13 deletions(-) -- 1.7.5.4 ^ permalink raw reply [flat|nested] 22+ messages in thread
[parent not found: <1324432958-20414-1-git-send-email-fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]
* [PATCH 1/2 v2] cgroup: Remove unnecessary task_lock before fetching css_set on migration 2011-12-21 2:02 ` Frederic Weisbecker @ 2011-12-21 2:02 ` Frederic Weisbecker -1 siblings, 0 replies; 22+ messages in thread From: Frederic Weisbecker @ 2011-12-21 2:02 UTC (permalink / raw) To: Tejun Heo, Li Zefan Cc: Frederic Weisbecker, Containers, Oleg Nesterov, LKML, Cgroups, Andrew Morton, Paul Menage When we fetch the css_set of the tasks on cgroup migration, we don't need anymore to synchronize against cgroup_exit() that could swap the old one with init_css_set. Now that we are using threadgroup_lock() during the migrations, we don't need to worry about it anymore. Signed-off-by: Frederic Weisbecker <fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Reviewed-by: Mandeep Singh Baines <msb-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> Reviewed-by: Li Zefan <lizf-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org> Cc: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> Cc: Containers <containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org> Cc: Cgroups <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> Cc: Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> Cc: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> Cc: Paul Menage <paul-inf54ven1CmVyaH7bEyXVA@public.gmane.org> --- kernel/cgroup.c | 20 ++++++++++---------- 1 files changed, 10 insertions(+), 10 deletions(-) diff --git a/kernel/cgroup.c b/kernel/cgroup.c index bc3caff..24f6d6f 100644 --- a/kernel/cgroup.c +++ b/kernel/cgroup.c @@ -1850,14 +1850,14 @@ static int cgroup_task_migrate(struct cgroup *cgrp, struct cgroup *oldcgrp, struct css_set *newcg; /* - * get old css_set. we need to take task_lock and refcount it, because - * an exiting task can change its css_set to init_css_set and drop its - * old one without taking cgroup_mutex. + * get old css_set. We are synchronized through threadgroup_lock() + * against PF_EXITING setting such that we can't race against + * cgroup_exit() changing the css_set to init_css_set and dropping the + * old one. */ - task_lock(tsk); + WARN_ON_ONCE(tsk->flags & PF_EXITING); oldcg = tsk->cgroups; get_css_set(oldcg); - task_unlock(tsk); /* locate or allocate a new css_set for this task. */ if (guarantee) { @@ -1879,9 +1879,7 @@ static int cgroup_task_migrate(struct cgroup *cgrp, struct cgroup *oldcgrp, } put_css_set(oldcg); - /* @tsk can't exit as its threadgroup is locked */ task_lock(tsk); - WARN_ON_ONCE(tsk->flags & PF_EXITING); rcu_assign_pointer(tsk->cgroups, newcg); task_unlock(tsk); @@ -2182,11 +2180,13 @@ int cgroup_attach_proc(struct cgroup *cgrp, struct task_struct *leader) /* nothing to do if this task is already in the cgroup */ if (tc->cgrp == cgrp) continue; - /* get old css_set pointer */ - task_lock(tc->task); + /* + * get old css_set pointer. threadgroup is locked so this is + * safe against concurrent cgroup_exit() changing this to + * init_css_set. + */ oldcg = tc->task->cgroups; get_css_set(oldcg); - task_unlock(tc->task); /* see if the new one for us is already in the list? */ if (css_set_check_fetched(cgrp, tc->task, oldcg, &newcg_list)) { /* was already there, nothing to do. */ -- 1.7.5.4 ^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH 1/2 v2] cgroup: Remove unnecessary task_lock before fetching css_set on migration @ 2011-12-21 2:02 ` Frederic Weisbecker 0 siblings, 0 replies; 22+ messages in thread From: Frederic Weisbecker @ 2011-12-21 2:02 UTC (permalink / raw) To: Tejun Heo, Li Zefan Cc: LKML, Frederic Weisbecker, Containers, Cgroups, KAMEZAWA Hiroyuki, Oleg Nesterov, Andrew Morton, Paul Menage When we fetch the css_set of the tasks on cgroup migration, we don't need anymore to synchronize against cgroup_exit() that could swap the old one with init_css_set. Now that we are using threadgroup_lock() during the migrations, we don't need to worry about it anymore. Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> Reviewed-by: Mandeep Singh Baines <msb@chromium.org> Reviewed-by: Li Zefan <lizf@cn.fujitsu.com> Cc: Tejun Heo <tj@kernel.org> Cc: Containers <containers@lists.linux-foundation.org> Cc: Cgroups <cgroups@vger.kernel.org> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Paul Menage <paul@paulmenage.org> --- kernel/cgroup.c | 20 ++++++++++---------- 1 files changed, 10 insertions(+), 10 deletions(-) diff --git a/kernel/cgroup.c b/kernel/cgroup.c index bc3caff..24f6d6f 100644 --- a/kernel/cgroup.c +++ b/kernel/cgroup.c @@ -1850,14 +1850,14 @@ static int cgroup_task_migrate(struct cgroup *cgrp, struct cgroup *oldcgrp, struct css_set *newcg; /* - * get old css_set. we need to take task_lock and refcount it, because - * an exiting task can change its css_set to init_css_set and drop its - * old one without taking cgroup_mutex. + * get old css_set. We are synchronized through threadgroup_lock() + * against PF_EXITING setting such that we can't race against + * cgroup_exit() changing the css_set to init_css_set and dropping the + * old one. */ - task_lock(tsk); + WARN_ON_ONCE(tsk->flags & PF_EXITING); oldcg = tsk->cgroups; get_css_set(oldcg); - task_unlock(tsk); /* locate or allocate a new css_set for this task. */ if (guarantee) { @@ -1879,9 +1879,7 @@ static int cgroup_task_migrate(struct cgroup *cgrp, struct cgroup *oldcgrp, } put_css_set(oldcg); - /* @tsk can't exit as its threadgroup is locked */ task_lock(tsk); - WARN_ON_ONCE(tsk->flags & PF_EXITING); rcu_assign_pointer(tsk->cgroups, newcg); task_unlock(tsk); @@ -2182,11 +2180,13 @@ int cgroup_attach_proc(struct cgroup *cgrp, struct task_struct *leader) /* nothing to do if this task is already in the cgroup */ if (tc->cgrp == cgrp) continue; - /* get old css_set pointer */ - task_lock(tc->task); + /* + * get old css_set pointer. threadgroup is locked so this is + * safe against concurrent cgroup_exit() changing this to + * init_css_set. + */ oldcg = tc->task->cgroups; get_css_set(oldcg); - task_unlock(tc->task); /* see if the new one for us is already in the list? */ if (css_set_check_fetched(cgrp, tc->task, oldcg, &newcg_list)) { /* was already there, nothing to do. */ -- 1.7.5.4 ^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH 2/2 v2] cgroup: Drop task_lock(parent) on cgroup_fork() 2011-12-21 2:02 ` Frederic Weisbecker @ 2011-12-21 2:02 ` Frederic Weisbecker -1 siblings, 0 replies; 22+ messages in thread From: Frederic Weisbecker @ 2011-12-21 2:02 UTC (permalink / raw) To: Tejun Heo, Li Zefan Cc: Frederic Weisbecker, Containers, Oleg Nesterov, LKML, Mandeep Singh Baines, Cgroups, Andrew Morton, Paul Menage We don't need to hold the parent task_lock() on the parent in cgroup_fork() because we are already synchronized against the two places that may change the parent css_set concurrently: - cgroup_exit(), but the parent obviously can't exit concurrently - cgroup migration: we are synchronized against threadgroup_lock() So we can safely remove the task_lock() there. Signed-off-by: Frederic Weisbecker <fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Cc: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> Cc: Li Zefan <lizf-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org> Cc: Containers <containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org> Cc: Cgroups <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> Cc: Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> Cc: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> Cc: Paul Menage <paul-inf54ven1CmVyaH7bEyXVA@public.gmane.org> Cc: Mandeep Singh Baines <msb-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> --- kernel/cgroup.c | 10 +++++++--- 1 files changed, 7 insertions(+), 3 deletions(-) diff --git a/kernel/cgroup.c b/kernel/cgroup.c index 24f6d6f..1999f60 100644 --- a/kernel/cgroup.c +++ b/kernel/cgroup.c @@ -4556,7 +4556,7 @@ static const struct file_operations proc_cgroupstats_operations = { * * A pointer to the shared css_set was automatically copied in * fork.c by dup_task_struct(). However, we ignore that copy, since - * it was not made under the protection of RCU or cgroup_mutex, so + * it was not made under the protection of threadgroup_change_begin(), so * might no longer be a valid cgroup pointer. cgroup_attach_task() might * have already changed current->cgroups, allowing the previously * referenced cgroup group to be removed and freed. @@ -4566,10 +4566,14 @@ static const struct file_operations proc_cgroupstats_operations = { */ void cgroup_fork(struct task_struct *child) { - task_lock(current); + /* + * We don't need to task_lock() current because current->cgroups + * can't be changed concurrently here. The parent obviously hasn't + * exited and called cgroup_exit(), and we are synchronized against + * cgroup migration through threadgroup_change_begin(). + */ child->cgroups = current->cgroups; get_css_set(child->cgroups); - task_unlock(current); INIT_LIST_HEAD(&child->cg_list); } -- 1.7.5.4 ^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH 2/2 v2] cgroup: Drop task_lock(parent) on cgroup_fork() @ 2011-12-21 2:02 ` Frederic Weisbecker 0 siblings, 0 replies; 22+ messages in thread From: Frederic Weisbecker @ 2011-12-21 2:02 UTC (permalink / raw) To: Tejun Heo, Li Zefan Cc: LKML, Frederic Weisbecker, Containers, Cgroups, KAMEZAWA Hiroyuki, Oleg Nesterov, Andrew Morton, Paul Menage, Mandeep Singh Baines We don't need to hold the parent task_lock() on the parent in cgroup_fork() because we are already synchronized against the two places that may change the parent css_set concurrently: - cgroup_exit(), but the parent obviously can't exit concurrently - cgroup migration: we are synchronized against threadgroup_lock() So we can safely remove the task_lock() there. Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> Cc: Tejun Heo <tj@kernel.org> Cc: Li Zefan <lizf@cn.fujitsu.com> Cc: Containers <containers@lists.linux-foundation.org> Cc: Cgroups <cgroups@vger.kernel.org> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Paul Menage <paul@paulmenage.org> Cc: Mandeep Singh Baines <msb@chromium.org> --- kernel/cgroup.c | 10 +++++++--- 1 files changed, 7 insertions(+), 3 deletions(-) diff --git a/kernel/cgroup.c b/kernel/cgroup.c index 24f6d6f..1999f60 100644 --- a/kernel/cgroup.c +++ b/kernel/cgroup.c @@ -4556,7 +4556,7 @@ static const struct file_operations proc_cgroupstats_operations = { * * A pointer to the shared css_set was automatically copied in * fork.c by dup_task_struct(). However, we ignore that copy, since - * it was not made under the protection of RCU or cgroup_mutex, so + * it was not made under the protection of threadgroup_change_begin(), so * might no longer be a valid cgroup pointer. cgroup_attach_task() might * have already changed current->cgroups, allowing the previously * referenced cgroup group to be removed and freed. @@ -4566,10 +4566,14 @@ static const struct file_operations proc_cgroupstats_operations = { */ void cgroup_fork(struct task_struct *child) { - task_lock(current); + /* + * We don't need to task_lock() current because current->cgroups + * can't be changed concurrently here. The parent obviously hasn't + * exited and called cgroup_exit(), and we are synchronized against + * cgroup migration through threadgroup_change_begin(). + */ child->cgroups = current->cgroups; get_css_set(child->cgroups); - task_unlock(current); INIT_LIST_HEAD(&child->cg_list); } -- 1.7.5.4 ^ permalink raw reply related [flat|nested] 22+ messages in thread
[parent not found: <1324432958-20414-3-git-send-email-fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]
* Re: [PATCH 2/2 v2] cgroup: Drop task_lock(parent) on cgroup_fork() [not found] ` <1324432958-20414-3-git-send-email-fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> @ 2011-12-21 2:16 ` Li Zefan 0 siblings, 0 replies; 22+ messages in thread From: Li Zefan @ 2011-12-21 2:16 UTC (permalink / raw) To: Frederic Weisbecker Cc: Containers, LKML, Oleg Nesterov, Mandeep Singh Baines, Tejun Heo, Cgroups, Andrew Morton, Paul Menage Frederic Weisbecker wrote: > We don't need to hold the parent task_lock() on the > parent in cgroup_fork() because we are already synchronized > against the two places that may change the parent css_set > concurrently: > > - cgroup_exit(), but the parent obviously can't exit concurrently > - cgroup migration: we are synchronized against threadgroup_lock() > > So we can safely remove the task_lock() there. > > Signed-off-by: Frederic Weisbecker <fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > Cc: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> > Cc: Li Zefan <lizf-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org> > Cc: Containers <containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org> > Cc: Cgroups <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> > Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> > Cc: Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> > Cc: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> > Cc: Paul Menage <paul-inf54ven1CmVyaH7bEyXVA@public.gmane.org> > Cc: Mandeep Singh Baines <msb-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> > --- > kernel/cgroup.c | 10 +++++++--- > 1 files changed, 7 insertions(+), 3 deletions(-) > > diff --git a/kernel/cgroup.c b/kernel/cgroup.c > index 24f6d6f..1999f60 100644 > --- a/kernel/cgroup.c > +++ b/kernel/cgroup.c > @@ -4556,7 +4556,7 @@ static const struct file_operations proc_cgroupstats_operations = { > * > * A pointer to the shared css_set was automatically copied in > * fork.c by dup_task_struct(). However, we ignore that copy, since > - * it was not made under the protection of RCU or cgroup_mutex, so > + * it was not made under the protection of threadgroup_change_begin(), so I think the original comment still stands, but now threadgroup_change_begin() can also protect the cgroup pointer from becoming invalid. > * might no longer be a valid cgroup pointer. cgroup_attach_task() might > * have already changed current->cgroups, allowing the previously > * referenced cgroup group to be removed and freed. > @@ -4566,10 +4566,14 @@ static const struct file_operations proc_cgroupstats_operations = { > */ > void cgroup_fork(struct task_struct *child) > { > - task_lock(current); > + /* > + * We don't need to task_lock() current because current->cgroups > + * can't be changed concurrently here. The parent obviously hasn't > + * exited and called cgroup_exit(), and we are synchronized against > + * cgroup migration through threadgroup_change_begin(). > + */ > child->cgroups = current->cgroups; > get_css_set(child->cgroups); > - task_unlock(current); > INIT_LIST_HEAD(&child->cg_list); > } > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2 v2] cgroup: Drop task_lock(parent) on cgroup_fork() [not found] ` <1324432958-20414-3-git-send-email-fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> @ 2011-12-21 2:16 ` Li Zefan 0 siblings, 0 replies; 22+ messages in thread From: Li Zefan @ 2011-12-21 2:16 UTC (permalink / raw) To: Frederic Weisbecker Cc: Tejun Heo, LKML, Containers, Cgroups, KAMEZAWA Hiroyuki, Oleg Nesterov, Andrew Morton, Paul Menage, Mandeep Singh Baines Frederic Weisbecker wrote: > We don't need to hold the parent task_lock() on the > parent in cgroup_fork() because we are already synchronized > against the two places that may change the parent css_set > concurrently: > > - cgroup_exit(), but the parent obviously can't exit concurrently > - cgroup migration: we are synchronized against threadgroup_lock() > > So we can safely remove the task_lock() there. > > Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> > Cc: Tejun Heo <tj@kernel.org> > Cc: Li Zefan <lizf@cn.fujitsu.com> > Cc: Containers <containers@lists.linux-foundation.org> > Cc: Cgroups <cgroups@vger.kernel.org> > Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> > Cc: Oleg Nesterov <oleg@redhat.com> > Cc: Andrew Morton <akpm@linux-foundation.org> > Cc: Paul Menage <paul@paulmenage.org> > Cc: Mandeep Singh Baines <msb@chromium.org> > --- > kernel/cgroup.c | 10 +++++++--- > 1 files changed, 7 insertions(+), 3 deletions(-) > > diff --git a/kernel/cgroup.c b/kernel/cgroup.c > index 24f6d6f..1999f60 100644 > --- a/kernel/cgroup.c > +++ b/kernel/cgroup.c > @@ -4556,7 +4556,7 @@ static const struct file_operations proc_cgroupstats_operations = { > * > * A pointer to the shared css_set was automatically copied in > * fork.c by dup_task_struct(). However, we ignore that copy, since > - * it was not made under the protection of RCU or cgroup_mutex, so > + * it was not made under the protection of threadgroup_change_begin(), so I think the original comment still stands, but now threadgroup_change_begin() can also protect the cgroup pointer from becoming invalid. > * might no longer be a valid cgroup pointer. cgroup_attach_task() might > * have already changed current->cgroups, allowing the previously > * referenced cgroup group to be removed and freed. > @@ -4566,10 +4566,14 @@ static const struct file_operations proc_cgroupstats_operations = { > */ > void cgroup_fork(struct task_struct *child) > { > - task_lock(current); > + /* > + * We don't need to task_lock() current because current->cgroups > + * can't be changed concurrently here. The parent obviously hasn't > + * exited and called cgroup_exit(), and we are synchronized against > + * cgroup migration through threadgroup_change_begin(). > + */ > child->cgroups = current->cgroups; > get_css_set(child->cgroups); > - task_unlock(current); > INIT_LIST_HEAD(&child->cg_list); > } > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2 v2] cgroup: Drop task_lock(parent) on cgroup_fork() @ 2011-12-21 2:16 ` Li Zefan 0 siblings, 0 replies; 22+ messages in thread From: Li Zefan @ 2011-12-21 2:16 UTC (permalink / raw) To: Frederic Weisbecker Cc: Tejun Heo, LKML, Containers, Cgroups, KAMEZAWA Hiroyuki, Oleg Nesterov, Andrew Morton, Paul Menage, Mandeep Singh Baines Frederic Weisbecker wrote: > We don't need to hold the parent task_lock() on the > parent in cgroup_fork() because we are already synchronized > against the two places that may change the parent css_set > concurrently: > > - cgroup_exit(), but the parent obviously can't exit concurrently > - cgroup migration: we are synchronized against threadgroup_lock() > > So we can safely remove the task_lock() there. > > Signed-off-by: Frederic Weisbecker <fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > Cc: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> > Cc: Li Zefan <lizf-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org> > Cc: Containers <containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org> > Cc: Cgroups <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> > Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> > Cc: Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> > Cc: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> > Cc: Paul Menage <paul-inf54ven1CmVyaH7bEyXVA@public.gmane.org> > Cc: Mandeep Singh Baines <msb-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> > --- > kernel/cgroup.c | 10 +++++++--- > 1 files changed, 7 insertions(+), 3 deletions(-) > > diff --git a/kernel/cgroup.c b/kernel/cgroup.c > index 24f6d6f..1999f60 100644 > --- a/kernel/cgroup.c > +++ b/kernel/cgroup.c > @@ -4556,7 +4556,7 @@ static const struct file_operations proc_cgroupstats_operations = { > * > * A pointer to the shared css_set was automatically copied in > * fork.c by dup_task_struct(). However, we ignore that copy, since > - * it was not made under the protection of RCU or cgroup_mutex, so > + * it was not made under the protection of threadgroup_change_begin(), so I think the original comment still stands, but now threadgroup_change_begin() can also protect the cgroup pointer from becoming invalid. > * might no longer be a valid cgroup pointer. cgroup_attach_task() might > * have already changed current->cgroups, allowing the previously > * referenced cgroup group to be removed and freed. > @@ -4566,10 +4566,14 @@ static const struct file_operations proc_cgroupstats_operations = { > */ > void cgroup_fork(struct task_struct *child) > { > - task_lock(current); > + /* > + * We don't need to task_lock() current because current->cgroups > + * can't be changed concurrently here. The parent obviously hasn't > + * exited and called cgroup_exit(), and we are synchronized against > + * cgroup migration through threadgroup_change_begin(). > + */ > child->cgroups = current->cgroups; > get_css_set(child->cgroups); > - task_unlock(current); > INIT_LIST_HEAD(&child->cg_list); > } > ^ permalink raw reply [flat|nested] 22+ messages in thread
[parent not found: <4EF14176.9040206-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>]
* Re: [PATCH 2/2 v2] cgroup: Drop task_lock(parent) on cgroup_fork() [not found] ` <4EF14176.9040206-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org> @ 2011-12-21 2:48 ` Frederic Weisbecker 0 siblings, 0 replies; 22+ messages in thread From: Frederic Weisbecker @ 2011-12-21 2:48 UTC (permalink / raw) To: Li Zefan Cc: Containers, LKML, Oleg Nesterov, Mandeep Singh Baines, Tejun Heo, Cgroups, Andrew Morton, Paul Menage On Wed, Dec 21, 2011 at 10:16:22AM +0800, Li Zefan wrote: > Frederic Weisbecker wrote: > > We don't need to hold the parent task_lock() on the > > parent in cgroup_fork() because we are already synchronized > > against the two places that may change the parent css_set > > concurrently: > > > > - cgroup_exit(), but the parent obviously can't exit concurrently > > - cgroup migration: we are synchronized against threadgroup_lock() > > > > So we can safely remove the task_lock() there. > > > > Signed-off-by: Frederic Weisbecker <fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > Cc: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> > > Cc: Li Zefan <lizf-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org> > > Cc: Containers <containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org> > > Cc: Cgroups <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> > > Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> > > Cc: Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> > > Cc: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> > > Cc: Paul Menage <paul-inf54ven1CmVyaH7bEyXVA@public.gmane.org> > > Cc: Mandeep Singh Baines <msb-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> > > --- > > kernel/cgroup.c | 10 +++++++--- > > 1 files changed, 7 insertions(+), 3 deletions(-) > > > > diff --git a/kernel/cgroup.c b/kernel/cgroup.c > > index 24f6d6f..1999f60 100644 > > --- a/kernel/cgroup.c > > +++ b/kernel/cgroup.c > > @@ -4556,7 +4556,7 @@ static const struct file_operations proc_cgroupstats_operations = { > > * > > * A pointer to the shared css_set was automatically copied in > > * fork.c by dup_task_struct(). However, we ignore that copy, since > > - * it was not made under the protection of RCU or cgroup_mutex, so > > + * it was not made under the protection of threadgroup_change_begin(), so > > I think the original comment still stands, but now threadgroup_change_begin() > can also protect the cgroup pointer from becoming invalid. Right but I'm not sure it's worth quoting RCU and cgroup_mutex. The reason why we use threadgroup_change_begin() is not only to ensure the pointer validity but also to synchronize the whole cgroup proc logic. This way when we attach a whole proc with cgroup_attach_proc(), we are sure that no thread forked too soon or too late such that it wouldn't be migrated with the rest. RCU or cgroup_mutex on dup_task_struct() (+ a get_css_set()) would have protected the pointer validity but not the whole above described machinery. So I don't think it's even worth quoting those solutions. But if you prefer I can keep the old comment. OTOH what I think is missing in the comment is that explanation on the synchronization against entire proc migration. I can edit that. > > > * might no longer be a valid cgroup pointer. cgroup_attach_task() might > > * have already changed current->cgroups, allowing the previously > > * referenced cgroup group to be removed and freed. > > @@ -4566,10 +4566,14 @@ static const struct file_operations proc_cgroupstats_operations = { > > */ > > void cgroup_fork(struct task_struct *child) > > { > > - task_lock(current); > > + /* > > + * We don't need to task_lock() current because current->cgroups > > + * can't be changed concurrently here. The parent obviously hasn't > > + * exited and called cgroup_exit(), and we are synchronized against > > + * cgroup migration through threadgroup_change_begin(). > > + */ > > child->cgroups = current->cgroups; > > get_css_set(child->cgroups); > > - task_unlock(current); > > INIT_LIST_HEAD(&child->cg_list); > > } > > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2 v2] cgroup: Drop task_lock(parent) on cgroup_fork() [not found] ` <4EF14176.9040206-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org> @ 2011-12-21 2:48 ` Frederic Weisbecker 0 siblings, 0 replies; 22+ messages in thread From: Frederic Weisbecker @ 2011-12-21 2:48 UTC (permalink / raw) To: Li Zefan Cc: Tejun Heo, LKML, Containers, Cgroups, KAMEZAWA Hiroyuki, Oleg Nesterov, Andrew Morton, Paul Menage, Mandeep Singh Baines On Wed, Dec 21, 2011 at 10:16:22AM +0800, Li Zefan wrote: > Frederic Weisbecker wrote: > > We don't need to hold the parent task_lock() on the > > parent in cgroup_fork() because we are already synchronized > > against the two places that may change the parent css_set > > concurrently: > > > > - cgroup_exit(), but the parent obviously can't exit concurrently > > - cgroup migration: we are synchronized against threadgroup_lock() > > > > So we can safely remove the task_lock() there. > > > > Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> > > Cc: Tejun Heo <tj@kernel.org> > > Cc: Li Zefan <lizf@cn.fujitsu.com> > > Cc: Containers <containers@lists.linux-foundation.org> > > Cc: Cgroups <cgroups@vger.kernel.org> > > Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> > > Cc: Oleg Nesterov <oleg@redhat.com> > > Cc: Andrew Morton <akpm@linux-foundation.org> > > Cc: Paul Menage <paul@paulmenage.org> > > Cc: Mandeep Singh Baines <msb@chromium.org> > > --- > > kernel/cgroup.c | 10 +++++++--- > > 1 files changed, 7 insertions(+), 3 deletions(-) > > > > diff --git a/kernel/cgroup.c b/kernel/cgroup.c > > index 24f6d6f..1999f60 100644 > > --- a/kernel/cgroup.c > > +++ b/kernel/cgroup.c > > @@ -4556,7 +4556,7 @@ static const struct file_operations proc_cgroupstats_operations = { > > * > > * A pointer to the shared css_set was automatically copied in > > * fork.c by dup_task_struct(). However, we ignore that copy, since > > - * it was not made under the protection of RCU or cgroup_mutex, so > > + * it was not made under the protection of threadgroup_change_begin(), so > > I think the original comment still stands, but now threadgroup_change_begin() > can also protect the cgroup pointer from becoming invalid. Right but I'm not sure it's worth quoting RCU and cgroup_mutex. The reason why we use threadgroup_change_begin() is not only to ensure the pointer validity but also to synchronize the whole cgroup proc logic. This way when we attach a whole proc with cgroup_attach_proc(), we are sure that no thread forked too soon or too late such that it wouldn't be migrated with the rest. RCU or cgroup_mutex on dup_task_struct() (+ a get_css_set()) would have protected the pointer validity but not the whole above described machinery. So I don't think it's even worth quoting those solutions. But if you prefer I can keep the old comment. OTOH what I think is missing in the comment is that explanation on the synchronization against entire proc migration. I can edit that. > > > * might no longer be a valid cgroup pointer. cgroup_attach_task() might > > * have already changed current->cgroups, allowing the previously > > * referenced cgroup group to be removed and freed. > > @@ -4566,10 +4566,14 @@ static const struct file_operations proc_cgroupstats_operations = { > > */ > > void cgroup_fork(struct task_struct *child) > > { > > - task_lock(current); > > + /* > > + * We don't need to task_lock() current because current->cgroups > > + * can't be changed concurrently here. The parent obviously hasn't > > + * exited and called cgroup_exit(), and we are synchronized against > > + * cgroup migration through threadgroup_change_begin(). > > + */ > > child->cgroups = current->cgroups; > > get_css_set(child->cgroups); > > - task_unlock(current); > > INIT_LIST_HEAD(&child->cg_list); > > } > > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2 v2] cgroup: Drop task_lock(parent) on cgroup_fork() @ 2011-12-21 2:48 ` Frederic Weisbecker 0 siblings, 0 replies; 22+ messages in thread From: Frederic Weisbecker @ 2011-12-21 2:48 UTC (permalink / raw) To: Li Zefan Cc: Tejun Heo, LKML, Containers, Cgroups, KAMEZAWA Hiroyuki, Oleg Nesterov, Andrew Morton, Paul Menage, Mandeep Singh Baines On Wed, Dec 21, 2011 at 10:16:22AM +0800, Li Zefan wrote: > Frederic Weisbecker wrote: > > We don't need to hold the parent task_lock() on the > > parent in cgroup_fork() because we are already synchronized > > against the two places that may change the parent css_set > > concurrently: > > > > - cgroup_exit(), but the parent obviously can't exit concurrently > > - cgroup migration: we are synchronized against threadgroup_lock() > > > > So we can safely remove the task_lock() there. > > > > Signed-off-by: Frederic Weisbecker <fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > > Cc: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> > > Cc: Li Zefan <lizf-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org> > > Cc: Containers <containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org> > > Cc: Cgroups <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> > > Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org> > > Cc: Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> > > Cc: Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> > > Cc: Paul Menage <paul-inf54ven1CmVyaH7bEyXVA@public.gmane.org> > > Cc: Mandeep Singh Baines <msb-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> > > --- > > kernel/cgroup.c | 10 +++++++--- > > 1 files changed, 7 insertions(+), 3 deletions(-) > > > > diff --git a/kernel/cgroup.c b/kernel/cgroup.c > > index 24f6d6f..1999f60 100644 > > --- a/kernel/cgroup.c > > +++ b/kernel/cgroup.c > > @@ -4556,7 +4556,7 @@ static const struct file_operations proc_cgroupstats_operations = { > > * > > * A pointer to the shared css_set was automatically copied in > > * fork.c by dup_task_struct(). However, we ignore that copy, since > > - * it was not made under the protection of RCU or cgroup_mutex, so > > + * it was not made under the protection of threadgroup_change_begin(), so > > I think the original comment still stands, but now threadgroup_change_begin() > can also protect the cgroup pointer from becoming invalid. Right but I'm not sure it's worth quoting RCU and cgroup_mutex. The reason why we use threadgroup_change_begin() is not only to ensure the pointer validity but also to synchronize the whole cgroup proc logic. This way when we attach a whole proc with cgroup_attach_proc(), we are sure that no thread forked too soon or too late such that it wouldn't be migrated with the rest. RCU or cgroup_mutex on dup_task_struct() (+ a get_css_set()) would have protected the pointer validity but not the whole above described machinery. So I don't think it's even worth quoting those solutions. But if you prefer I can keep the old comment. OTOH what I think is missing in the comment is that explanation on the synchronization against entire proc migration. I can edit that. > > > * might no longer be a valid cgroup pointer. cgroup_attach_task() might > > * have already changed current->cgroups, allowing the previously > > * referenced cgroup group to be removed and freed. > > @@ -4566,10 +4566,14 @@ static const struct file_operations proc_cgroupstats_operations = { > > */ > > void cgroup_fork(struct task_struct *child) > > { > > - task_lock(current); > > + /* > > + * We don't need to task_lock() current because current->cgroups > > + * can't be changed concurrently here. The parent obviously hasn't > > + * exited and called cgroup_exit(), and we are synchronized against > > + * cgroup migration through threadgroup_change_begin(). > > + */ > > child->cgroups = current->cgroups; > > get_css_set(child->cgroups); > > - task_unlock(current); > > INIT_LIST_HEAD(&child->cg_list); > > } > > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2 v2] cgroup: Drop task_lock(parent) on cgroup_fork() 2011-12-21 2:48 ` Frederic Weisbecker @ 2011-12-21 3:16 ` Li Zefan -1 siblings, 0 replies; 22+ messages in thread From: Li Zefan @ 2011-12-21 3:16 UTC (permalink / raw) To: Frederic Weisbecker Cc: Containers, LKML, Oleg Nesterov, Mandeep Singh Baines, Tejun Heo, Cgroups, Andrew Morton, Paul Menage >>> @@ -4556,7 +4556,7 @@ static const struct file_operations proc_cgroupstats_operations = { >>> * >>> * A pointer to the shared css_set was automatically copied in >>> * fork.c by dup_task_struct(). However, we ignore that copy, since >>> - * it was not made under the protection of RCU or cgroup_mutex, so >>> + * it was not made under the protection of threadgroup_change_begin(), so >> >> I think the original comment still stands, but now threadgroup_change_begin() >> can also protect the cgroup pointer from becoming invalid. > > Right but I'm not sure it's worth quoting RCU and cgroup_mutex. The reason > why we use threadgroup_change_begin() is not only to ensure the pointer > validity but also to synchronize the whole cgroup proc logic. This way > when we attach a whole proc with cgroup_attach_proc(), we are sure that > no thread forked too soon or too late such that it wouldn't be migrated with > the rest. > > RCU or cgroup_mutex on dup_task_struct() (+ a get_css_set()) would have > protected the pointer validity but not the whole above described machinery. > So I don't think it's even worth quoting those solutions. But if you prefer > I can keep the old comment. > No, I don't have strong opinion here. So I'll ack this patch. > OTOH what I think is missing in the comment is that explanation on the synchronization > against entire proc migration. I can edit that. > I would appreciate this. :) >> >>> * might no longer be a valid cgroup pointer. cgroup_attach_task() might >>> * have already changed current->cgroups, allowing the previously >>> * referenced cgroup group to be removed and freed. >>> @@ -4566,10 +4566,14 @@ static const struct file_operations proc_cgroupstats_operations = { >>> */ >>> void cgroup_fork(struct task_struct *child) >>> { >>> - task_lock(current); >>> + /* >>> + * We don't need to task_lock() current because current->cgroups >>> + * can't be changed concurrently here. The parent obviously hasn't >>> + * exited and called cgroup_exit(), and we are synchronized against >>> + * cgroup migration through threadgroup_change_begin(). >>> + */ >>> child->cgroups = current->cgroups; >>> get_css_set(child->cgroups); >>> - task_unlock(current); >>> INIT_LIST_HEAD(&child->cg_list); >>> } >>> > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2 v2] cgroup: Drop task_lock(parent) on cgroup_fork() @ 2011-12-21 3:16 ` Li Zefan 0 siblings, 0 replies; 22+ messages in thread From: Li Zefan @ 2011-12-21 3:16 UTC (permalink / raw) To: Frederic Weisbecker Cc: Tejun Heo, LKML, Containers, Cgroups, KAMEZAWA Hiroyuki, Oleg Nesterov, Andrew Morton, Paul Menage, Mandeep Singh Baines >>> @@ -4556,7 +4556,7 @@ static const struct file_operations proc_cgroupstats_operations = { >>> * >>> * A pointer to the shared css_set was automatically copied in >>> * fork.c by dup_task_struct(). However, we ignore that copy, since >>> - * it was not made under the protection of RCU or cgroup_mutex, so >>> + * it was not made under the protection of threadgroup_change_begin(), so >> >> I think the original comment still stands, but now threadgroup_change_begin() >> can also protect the cgroup pointer from becoming invalid. > > Right but I'm not sure it's worth quoting RCU and cgroup_mutex. The reason > why we use threadgroup_change_begin() is not only to ensure the pointer > validity but also to synchronize the whole cgroup proc logic. This way > when we attach a whole proc with cgroup_attach_proc(), we are sure that > no thread forked too soon or too late such that it wouldn't be migrated with > the rest. > > RCU or cgroup_mutex on dup_task_struct() (+ a get_css_set()) would have > protected the pointer validity but not the whole above described machinery. > So I don't think it's even worth quoting those solutions. But if you prefer > I can keep the old comment. > No, I don't have strong opinion here. So I'll ack this patch. > OTOH what I think is missing in the comment is that explanation on the synchronization > against entire proc migration. I can edit that. > I would appreciate this. :) >> >>> * might no longer be a valid cgroup pointer. cgroup_attach_task() might >>> * have already changed current->cgroups, allowing the previously >>> * referenced cgroup group to be removed and freed. >>> @@ -4566,10 +4566,14 @@ static const struct file_operations proc_cgroupstats_operations = { >>> */ >>> void cgroup_fork(struct task_struct *child) >>> { >>> - task_lock(current); >>> + /* >>> + * We don't need to task_lock() current because current->cgroups >>> + * can't be changed concurrently here. The parent obviously hasn't >>> + * exited and called cgroup_exit(), and we are synchronized against >>> + * cgroup migration through threadgroup_change_begin(). >>> + */ >>> child->cgroups = current->cgroups; >>> get_css_set(child->cgroups); >>> - task_unlock(current); >>> INIT_LIST_HEAD(&child->cg_list); >>> } >>> > ^ permalink raw reply [flat|nested] 22+ messages in thread
[parent not found: <4EF14F7B.2040507-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>]
* Re: [PATCH 2/2 v2] cgroup: Drop task_lock(parent) on cgroup_fork() 2011-12-21 3:16 ` Li Zefan @ 2011-12-21 17:50 ` Tejun Heo -1 siblings, 0 replies; 22+ messages in thread From: Tejun Heo @ 2011-12-21 17:50 UTC (permalink / raw) To: Li Zefan Cc: Frederic Weisbecker, Containers, Oleg Nesterov, LKML, Mandeep Singh Baines, Cgroups, Andrew Morton, Paul Menage Hello, On Wed, Dec 21, 2011 at 11:16:11AM +0800, Li Zefan wrote: > So I'll ack this patch. Do I have your ack on the first one too? If so, I'll go ahead and apply these two. Thanks. -- tejun ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2 v2] cgroup: Drop task_lock(parent) on cgroup_fork() @ 2011-12-21 17:50 ` Tejun Heo 0 siblings, 0 replies; 22+ messages in thread From: Tejun Heo @ 2011-12-21 17:50 UTC (permalink / raw) To: Li Zefan Cc: Frederic Weisbecker, LKML, Containers, Cgroups, KAMEZAWA Hiroyuki, Oleg Nesterov, Andrew Morton, Paul Menage, Mandeep Singh Baines Hello, On Wed, Dec 21, 2011 at 11:16:11AM +0800, Li Zefan wrote: > So I'll ack this patch. Do I have your ack on the first one too? If so, I'll go ahead and apply these two. Thanks. -- tejun ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2 v2] cgroup: Drop task_lock(parent) on cgroup_fork() [not found] ` <20111221175024.GG9213-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> @ 2011-12-21 17:51 ` Tejun Heo 2011-12-21 17:52 ` Frederic Weisbecker 1 sibling, 0 replies; 22+ messages in thread From: Tejun Heo @ 2011-12-21 17:51 UTC (permalink / raw) To: Li Zefan Cc: Frederic Weisbecker, LKML, Containers, Cgroups, KAMEZAWA Hiroyuki, Oleg Nesterov, Andrew Morton, Paul Menage, Mandeep Singh Baines On Wed, Dec 21, 2011 at 09:50:24AM -0800, Tejun Heo wrote: > Hello, > > On Wed, Dec 21, 2011 at 11:16:11AM +0800, Li Zefan wrote: > > So I'll ack this patch. > > Do I have your ack on the first one too? If so, I'll go ahead and > apply these two. Ooh, you already did in the previous posting. Applying to cgroup/for-3.3. Thanks. -- tejun ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2 v2] cgroup: Drop task_lock(parent) on cgroup_fork() @ 2011-12-21 17:51 ` Tejun Heo 0 siblings, 0 replies; 22+ messages in thread From: Tejun Heo @ 2011-12-21 17:51 UTC (permalink / raw) To: Li Zefan Cc: Frederic Weisbecker, LKML, Containers, Cgroups, KAMEZAWA Hiroyuki, Oleg Nesterov, Andrew Morton, Paul Menage, Mandeep Singh Baines On Wed, Dec 21, 2011 at 09:50:24AM -0800, Tejun Heo wrote: > Hello, > > On Wed, Dec 21, 2011 at 11:16:11AM +0800, Li Zefan wrote: > > So I'll ack this patch. > > Do I have your ack on the first one too? If so, I'll go ahead and > apply these two. Ooh, you already did in the previous posting. Applying to cgroup/for-3.3. Thanks. -- tejun ^ permalink raw reply [flat|nested] 22+ messages in thread
[parent not found: <20111221175024.GG9213-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH 2/2 v2] cgroup: Drop task_lock(parent) on cgroup_fork() [not found] ` <20111221175024.GG9213-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> @ 2011-12-21 17:51 ` Tejun Heo 2011-12-21 17:52 ` Frederic Weisbecker 1 sibling, 0 replies; 22+ messages in thread From: Tejun Heo @ 2011-12-21 17:51 UTC (permalink / raw) To: Li Zefan Cc: Frederic Weisbecker, Containers, Oleg Nesterov, LKML, Mandeep Singh Baines, Cgroups, Andrew Morton, Paul Menage On Wed, Dec 21, 2011 at 09:50:24AM -0800, Tejun Heo wrote: > Hello, > > On Wed, Dec 21, 2011 at 11:16:11AM +0800, Li Zefan wrote: > > So I'll ack this patch. > > Do I have your ack on the first one too? If so, I'll go ahead and > apply these two. Ooh, you already did in the previous posting. Applying to cgroup/for-3.3. Thanks. -- tejun ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2 v2] cgroup: Drop task_lock(parent) on cgroup_fork() [not found] ` <20111221175024.GG9213-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> 2011-12-21 17:51 ` Tejun Heo @ 2011-12-21 17:52 ` Frederic Weisbecker 1 sibling, 0 replies; 22+ messages in thread From: Frederic Weisbecker @ 2011-12-21 17:52 UTC (permalink / raw) To: Tejun Heo Cc: Containers, LKML, Oleg Nesterov, Mandeep Singh Baines, Cgroups, Andrew Morton, Paul Menage On Wed, Dec 21, 2011 at 09:50:24AM -0800, Tejun Heo wrote: > Hello, > > On Wed, Dec 21, 2011 at 11:16:11AM +0800, Li Zefan wrote: > > So I'll ack this patch. > > Do I have your ack on the first one too? If so, I'll go ahead and > apply these two. > > Thanks. Lemme just update the comment on this one before, I'll resend a new version quickly, thanks! ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2 v2] cgroup: Drop task_lock(parent) on cgroup_fork() [not found] ` <20111221175024.GG9213-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> @ 2011-12-21 17:52 ` Frederic Weisbecker 2011-12-21 17:52 ` Frederic Weisbecker 1 sibling, 0 replies; 22+ messages in thread From: Frederic Weisbecker @ 2011-12-21 17:52 UTC (permalink / raw) To: Tejun Heo Cc: Li Zefan, LKML, Containers, Cgroups, KAMEZAWA Hiroyuki, Oleg Nesterov, Andrew Morton, Paul Menage, Mandeep Singh Baines On Wed, Dec 21, 2011 at 09:50:24AM -0800, Tejun Heo wrote: > Hello, > > On Wed, Dec 21, 2011 at 11:16:11AM +0800, Li Zefan wrote: > > So I'll ack this patch. > > Do I have your ack on the first one too? If so, I'll go ahead and > apply these two. > > Thanks. Lemme just update the comment on this one before, I'll resend a new version quickly, thanks! ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2 v2] cgroup: Drop task_lock(parent) on cgroup_fork() @ 2011-12-21 17:52 ` Frederic Weisbecker 0 siblings, 0 replies; 22+ messages in thread From: Frederic Weisbecker @ 2011-12-21 17:52 UTC (permalink / raw) To: Tejun Heo Cc: Li Zefan, LKML, Containers, Cgroups, KAMEZAWA Hiroyuki, Oleg Nesterov, Andrew Morton, Paul Menage, Mandeep Singh Baines On Wed, Dec 21, 2011 at 09:50:24AM -0800, Tejun Heo wrote: > Hello, > > On Wed, Dec 21, 2011 at 11:16:11AM +0800, Li Zefan wrote: > > So I'll ack this patch. > > Do I have your ack on the first one too? If so, I'll go ahead and > apply these two. > > Thanks. Lemme just update the comment on this one before, I'll resend a new version quickly, thanks! ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2011-12-21 17:52 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-12-21 2:02 [PATCH 0/2 v2] cgroup: Remove useless task_lock() Frederic Weisbecker 2011-12-21 2:02 ` Frederic Weisbecker [not found] ` <1324432958-20414-1-git-send-email-fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2011-12-21 2:02 ` [PATCH 1/2 v2] cgroup: Remove unnecessary task_lock before fetching css_set on migration Frederic Weisbecker 2011-12-21 2:02 ` Frederic Weisbecker 2011-12-21 2:02 ` [PATCH 2/2 v2] cgroup: Drop task_lock(parent) on cgroup_fork() Frederic Weisbecker 2011-12-21 2:02 ` Frederic Weisbecker [not found] ` <1324432958-20414-3-git-send-email-fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2011-12-21 2:16 ` Li Zefan 2011-12-21 2:16 ` Li Zefan 2011-12-21 2:16 ` Li Zefan [not found] ` <4EF14176.9040206-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org> 2011-12-21 2:48 ` Frederic Weisbecker 2011-12-21 2:48 ` Frederic Weisbecker 2011-12-21 2:48 ` Frederic Weisbecker 2011-12-21 3:16 ` Li Zefan 2011-12-21 3:16 ` Li Zefan [not found] ` <4EF14F7B.2040507-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org> 2011-12-21 17:50 ` Tejun Heo 2011-12-21 17:50 ` Tejun Heo 2011-12-21 17:51 ` Tejun Heo 2011-12-21 17:51 ` Tejun Heo [not found] ` <20111221175024.GG9213-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> 2011-12-21 17:51 ` Tejun Heo 2011-12-21 17:52 ` Frederic Weisbecker 2011-12-21 17:52 ` Frederic Weisbecker 2011-12-21 17:52 ` Frederic Weisbecker
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.