[PATCH 1/7] cgroup: cgroup_subsys->fork() should be called after the task is added to css_set
lizefan at huawei.com
Thu Oct 18 01:25:21 UTC 2012
于 2012/10/17 16:28, Li Zefan 写道:
> On 2012/10/17 6:28, Tejun Heo wrote:
>> cgroup core has a bug which violates a basic rule about event
>> notifications - when a new entity needs to be added, you add that to
>> the notification list first and then make the new entity conform to
>> the current state. If done in the reverse order, an event happening
>> inbetween will be lost.
>> cgroup_subsys->fork() is invoked way before the new task is added to
>> the css_set. Currently, cgroup_freezer is the only user of ->fork()
>> and uses it to make new tasks conform to the current state of the
>> freezer. If FROZEN state is requested while fork is in progress
>> between cgroup_fork_callbacks() and cgroup_post_fork(), the child
>> could escape freezing - the cgroup isn't frozen when ->fork() is
>> called and the freezer couldn't see the new task on the css_set.
>> This patch moves cgroup_subsys->fork() invocation to
>> cgroup_post_fork() after the new task is added to the css_set.
>> cgroup_fork_callbacks() is removed.
>> Because now a task may be migrated during cgroup_subsys->fork(),
>> freezer_fork() is updated so that it adheres to the usual RCU locking
>> and the rather pointless comment on why locking can be different there
>> is removed (if it doesn't make anything simpler, why even bother?).
> I don't think rcu read section is sufficient. It guarantees the data you're
> accessing is valid, but the data can be new or can be old.
> So a case below is possible:
> in freezer_fork():
> freezer = task_freezer(task);
> move task from freezer to freezer2
> which is in FREEZING/FROZEN state
> freezer is in THAWED state,
> nothing to do.
forget about it. The task will be correctly frozen when moving to
another cgroup, so nothing unexpected will happen.
for this patch:
Acked-by: Li Zefan <lizefan at huawei.com>
More information about the Containers