>>>> with CONFIG_PROVE_RCU, a warning can be triggered when we >>>> resume from suspend: >>>> >>>> ... >>>> include/linux/cgroup.h:533 invoked rcu_dereference_check() without protection! >>>> ... >>>> >>>> task_freezer() calls task_subsys_state(), which needs to be >>>> protected by rcu_read_lock or cgroup_mutex. >>>> >>>> Signed-off-by: Li Zefan <lizf@xxxxxxxxxxxxxx> >>>> --- >>>> kernel/cgroup_freezer.c | 2 ++ >>>> 1 files changed, 2 insertions(+), 0 deletions(-) >>>> >>>> diff --git a/kernel/cgroup_freezer.c b/kernel/cgroup_freezer.c >>>> index 5038f4c..ac76983 100644 >>>> --- a/kernel/cgroup_freezer.c >>>> +++ b/kernel/cgroup_freezer.c >>>> @@ -53,6 +53,7 @@ int cgroup_freezing_or_frozen(struct task_struct *task) >>>> struct freezer *freezer; >>>> enum freezer_state state; >>>> >>>> + rcu_read_lock(); >>>> task_lock(task); >>>> freezer = task_freezer(task); >>>> if (!freezer->css.cgroup->parent) >>>> @@ -60,6 +61,7 @@ int cgroup_freezing_or_frozen(struct task_struct *task) >>>> else >>>> state = freezer->state; >>>> task_unlock(task); >>>> + rcu_read_unlock(); >>>> >>>> return (state == CGROUP_FREEZING) || (state == CGROUP_FROZEN); >>>> } >>> Hmm cgroup_attach_task() does hold task_lock() over setting >>> tsk->cgroups, so doesn't that also pin the task to the cgroup and thus >>> the cgroup itself? >> So you are advocating for the rcu_dereference check including the >> task lock, correct? > > I think that might be correct yes, although I would prefer confirmation > from someone who actually knows kernel/cgroup.c ;-) > You are right in that taking task_lock() is sufficient (I forgot this lock rule), but it's not true that whatever locks are held in the ->attach method can pin a task's cgroup. So the right fix is including task_lock in rcu_deref check in task_subsys_state(). I'll send a new fix. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
