From: Frederic Weisbecker <fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Li Zefan <lizf-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
Cc: Containers
<containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
Mandeep Singh Baines
<msb-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Cgroups <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
Paul Menage <paul-inf54ven1CmVyaH7bEyXVA@public.gmane.org>
Subject: Re: [RFC PATCH] cgroup: Remove task_lock() from cgroup_post_fork()
Date: Thu, 22 Dec 2011 10:33:54 +0100 [thread overview]
Message-ID: <20111222093351.GN17668@somewhere> (raw)
In-Reply-To: <4EF2F095.90207-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
On Thu, Dec 22, 2011 at 04:55:49PM +0800, Li Zefan wrote:
> Frederic Weisbecker wrote:
> > cgroup_post_fork() is protected between threadgroup_change_begin()
> > and threadgroup_change_end() against concurrent changes of the
> > child's css_set in cgroup_task_migrate(). Also the child can't
> > exit and call cgroup_exit() at this stage, this means it's css_set
> > can't be changed with init_css_set concurrently.
> >
> > For these reasons, we don't need to hold task_lock() on the child
> > because it's css_set can only remain stable in this place.
> >
> > Let's remove the lock there.
> >
> > NOTE: We could do something else: move threadgroup_change_end()
> > before cgroup_post_fork() and keep the task_lock() which, combined
> > with the css_set_lock, would be enough to synchronize against
> > cgroup_task_migrate()'s change on child->cgroup and its cglist.
> > Because outside that, the threadgroup lock doesn't appear to be
> > needed on cgroup_post_fork().
> >
>
> To narrow the scope of the threadgroup lock? I think it's preferable to keep
> cgroup_post_fork() inside the lock, to make things simpler and we have
> the same lock rule for both cgroup_fork() and cgroup_post_fork().
Ok!
> > Let's debate!
> >
> > Signed-off-by: Frederic Weisbecker <fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Cc: 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>
> > Cc: Mandeep Singh Baines <msb-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> > ---
> > kernel/cgroup.c | 11 ++++++++---
> > 1 files changed, 8 insertions(+), 3 deletions(-)
> >
> > diff --git a/kernel/cgroup.c b/kernel/cgroup.c
> > index 4936d88..d0dbf72 100644
> > --- a/kernel/cgroup.c
> > +++ b/kernel/cgroup.c
> > @@ -4622,10 +4622,15 @@ void cgroup_post_fork(struct task_struct *child)
> > {
> > if (use_task_css_set_links) {
> > write_lock(&css_set_lock);
> > - task_lock(child);
> > - if (list_empty(&child->cg_list))
> > + 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 explain why it won't race with cgroup_exit()? You were not quite confident
> about that before Oleg's explanation. ;)
hehe indeed :)
Will update, thanks!
> > list_add(&child->cg_list, &child->cgroups->tasks);
> > - task_unlock(child);
> > + }
> > write_unlock(&css_set_lock);
> > }
> > }
WARNING: multiple messages have this Message-ID (diff)
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Li Zefan <lizf@cn.fujitsu.com>
Cc: Tejun Heo <tj@kernel.org>, LKML <linux-kernel@vger.kernel.org>,
Containers <containers@lists.linux-foundation.org>,
Cgroups <cgroups@vger.kernel.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Oleg Nesterov <oleg@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Paul Menage <paul@paulmenage.org>,
Mandeep Singh Baines <msb@chromium.org>
Subject: Re: [RFC PATCH] cgroup: Remove task_lock() from cgroup_post_fork()
Date: Thu, 22 Dec 2011 10:33:54 +0100 [thread overview]
Message-ID: <20111222093351.GN17668@somewhere> (raw)
In-Reply-To: <4EF2F095.90207@cn.fujitsu.com>
On Thu, Dec 22, 2011 at 04:55:49PM +0800, Li Zefan wrote:
> Frederic Weisbecker wrote:
> > cgroup_post_fork() is protected between threadgroup_change_begin()
> > and threadgroup_change_end() against concurrent changes of the
> > child's css_set in cgroup_task_migrate(). Also the child can't
> > exit and call cgroup_exit() at this stage, this means it's css_set
> > can't be changed with init_css_set concurrently.
> >
> > For these reasons, we don't need to hold task_lock() on the child
> > because it's css_set can only remain stable in this place.
> >
> > Let's remove the lock there.
> >
> > NOTE: We could do something else: move threadgroup_change_end()
> > before cgroup_post_fork() and keep the task_lock() which, combined
> > with the css_set_lock, would be enough to synchronize against
> > cgroup_task_migrate()'s change on child->cgroup and its cglist.
> > Because outside that, the threadgroup lock doesn't appear to be
> > needed on cgroup_post_fork().
> >
>
> To narrow the scope of the threadgroup lock? I think it's preferable to keep
> cgroup_post_fork() inside the lock, to make things simpler and we have
> the same lock rule for both cgroup_fork() and cgroup_post_fork().
Ok!
> > Let's debate!
> >
> > Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
> > Cc: 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>
> > Cc: Mandeep Singh Baines <msb@chromium.org>
> > ---
> > kernel/cgroup.c | 11 ++++++++---
> > 1 files changed, 8 insertions(+), 3 deletions(-)
> >
> > diff --git a/kernel/cgroup.c b/kernel/cgroup.c
> > index 4936d88..d0dbf72 100644
> > --- a/kernel/cgroup.c
> > +++ b/kernel/cgroup.c
> > @@ -4622,10 +4622,15 @@ void cgroup_post_fork(struct task_struct *child)
> > {
> > if (use_task_css_set_links) {
> > write_lock(&css_set_lock);
> > - task_lock(child);
> > - if (list_empty(&child->cg_list))
> > + 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 explain why it won't race with cgroup_exit()? You were not quite confident
> about that before Oleg's explanation. ;)
hehe indeed :)
Will update, thanks!
> > list_add(&child->cg_list, &child->cgroups->tasks);
> > - task_unlock(child);
> > + }
> > write_unlock(&css_set_lock);
> > }
> > }
next prev parent reply other threads:[~2011-12-22 9:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-22 1:18 [RFC PATCH] cgroup: Remove task_lock() from cgroup_post_fork() Frederic Weisbecker
2011-12-22 1:18 ` Frederic Weisbecker
[not found] ` <1324516711-26913-1-git-send-email-fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2011-12-22 8:55 ` Li Zefan
2011-12-22 8:55 ` Li Zefan
2011-12-22 8:55 ` Li Zefan
[not found] ` <4EF2F095.90207-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
2011-12-22 9:33 ` Frederic Weisbecker [this message]
2011-12-22 9:33 ` Frederic Weisbecker
-- strict thread matches above, loose matches on Subject: below --
2011-12-22 1:18 Frederic Weisbecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20111222093351.GN17668@somewhere \
--to=fweisbec-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=lizf-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org \
--cc=msb-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=paul-inf54ven1CmVyaH7bEyXVA@public.gmane.org \
--cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.