Re: [RFC][PATCH] cgroup: fix race between fork and cgroup freezing

[Frederic Weisbecker <fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On Mon, Mar 12, 2012 at 09:10:40AM -0700, Tejun Heo wrote:
> 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?

Nope, cgroup_fork_callbacks() is called soon enough to be able
to cancel a fork. The task counter subsystem cancels from that point.