From: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Li Zefan <lizf-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
Cc: "Frederic Weisbecker"
<fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Cgroups <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"Mel Gorman" <mgorman-l3A5Bk7waGM@public.gmane.org>,
"David Rientjes"
<rientjes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
"缪 勰" <miaox-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>,
"Andrew Morton"
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Subject: Re: [RFC][PATCH] cgroup: fix race between fork and cgroup freezing
Date: Mon, 12 Mar 2012 09:10:40 -0700 [thread overview]
Message-ID: <20120312161040.GA23255@google.com> (raw)
In-Reply-To: <4F5DBB8C.6090904-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
Hello,
On Mon, Mar 12, 2012 at 05:02:04PM +0800, Li Zefan wrote:
> - We still need some kind of locking to syncronize fork and the traverser.
> fork side is protected by tasklist_lock, while the traverser takes
> css_set_lock.
Can't we do both after tasklist_lock is released under css_set_lock?
> - After linking the new task to css set list, the task is visible and thus
> can be moved to another cgroup, which makes things more complicated and
> the subsystem callbacks may have to acquire cgroup_mutex.
Hmmm... freezer currently doesn't allow migrating in and out of frozen
cgroup and even when it does callbacks in the migration path should
synchronize against freezer->lock. I *think* that should be enough
and can't see why this will be simpler or more complex depending on
when fork callback is called.
> - The task_counter subsystem wants to get notified before the new task
> is linked, so it's able to abort the fork.
This one maybe but for this cgroup_fork_callbacks() is already too
late, isn't it? We better have pre-fork callbacks instead, no?
Thanks.
--
tejun
WARNING: multiple messages have this Message-ID (diff)
From: Tejun Heo <tj@kernel.org>
To: Li Zefan <lizf@cn.fujitsu.com>
Cc: "Frederic Weisbecker" <fweisbec@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
Cgroups <cgroups@vger.kernel.org>, "Mel Gorman" <mgorman@suse.de>,
"David Rientjes" <rientjes@google.com>,
"缪 勰" <miaox@cn.fujitsu.com>,
"Andrew Morton" <akpm@linux-foundation.org>
Subject: Re: [RFC][PATCH] cgroup: fix race between fork and cgroup freezing
Date: Mon, 12 Mar 2012 09:10:40 -0700 [thread overview]
Message-ID: <20120312161040.GA23255@google.com> (raw)
In-Reply-To: <4F5DBB8C.6090904@cn.fujitsu.com>
Hello,
On Mon, Mar 12, 2012 at 05:02:04PM +0800, Li Zefan wrote:
> - We still need some kind of locking to syncronize fork and the traverser.
> fork side is protected by tasklist_lock, while the traverser takes
> css_set_lock.
Can't we do both after tasklist_lock is released under css_set_lock?
> - After linking the new task to css set list, the task is visible and thus
> can be moved to another cgroup, which makes things more complicated and
> the subsystem callbacks may have to acquire cgroup_mutex.
Hmmm... freezer currently doesn't allow migrating in and out of frozen
cgroup and even when it does callbacks in the migration path should
synchronize against freezer->lock. I *think* that should be enough
and can't see why this will be simpler or more complex depending on
when fork callback is called.
> - The task_counter subsystem wants to get notified before the new task
> is linked, so it's able to abort the fork.
This one maybe but for this cgroup_fork_callbacks() is already too
late, isn't it? We better have pre-fork callbacks instead, no?
Thanks.
--
tejun
next prev parent reply other threads:[~2012-03-12 16:10 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-08 8:45 [RFC][PATCH] cgroup: fix race between fork and cgroup freezing Li Zefan
2012-03-08 8:45 ` Li Zefan
[not found] ` <4F587199.6050404-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
2012-03-08 18:26 ` Tejun Heo
2012-03-08 18:26 ` Tejun Heo
[not found] ` <20120308182622.GC25508-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2012-03-09 6:26 ` Li Zefan
2012-03-09 6:26 ` Li Zefan
[not found] ` <4F59A27D.9080705-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
2012-03-09 16:53 ` Tejun Heo
2012-03-09 16:53 ` Tejun Heo
2012-03-12 9:02 ` Li Zefan
[not found] ` <4F5DBB8C.6090904-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
2012-03-12 16:10 ` Tejun Heo [this message]
2012-03-12 16:10 ` Tejun Heo
[not found] ` <20120312161040.GA23255-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2012-03-19 13:44 ` Frederic Weisbecker
2012-03-19 13:44 ` Frederic Weisbecker
2012-03-19 15:05 ` Frederic Weisbecker
2012-03-19 15:05 ` 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=20120312161040.GA23255@google.com \
--to=tj-dgejt+ai2ygdnm+yrofe0a@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=lizf-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org \
--cc=mgorman-l3A5Bk7waGM@public.gmane.org \
--cc=miaox-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org \
--cc=rientjes-hpIqsD4AKlfQT0dZR+AlfA@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.