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. -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html