From: Li Zefan <lizefan@huawei.com> To: Tejun Heo <tj@kernel.org> Cc: "Toralf Förster" <toralf.foerster@gmx.de>, LKML <linux-kernel@vger.kernel.org>, cgroups <cgroups@vger.kernel.org> Subject: Re: [PATCH 1/2] cgroup: Delay the clearing of cgrp->kn->priv Date: Thu, 4 Sep 2014 11:35:30 +0800 [thread overview] Message-ID: <5407DE02.8090805@huawei.com> (raw) In-Reply-To: <20140902153301.GA17424@htj.dyndns.org> 于 2014/9/2 23:33, Tejun Heo 写道: > Hello, Li. > > On Tue, Sep 02, 2014 at 06:56:58PM +0800, Li Zefan wrote: >> for ((; ;)) >> { >> echo $$ > /cgroup/sub/cgroup.procs >> ech $$ > /cgce 6f2e0c38c2108a74 ]--- > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > copy & paste error? > ... oops >> Reported-by: Toralf Förster <toralf.foerster@gmx.de> >> Signed-off-by: Li Zefan <lizefan@huawei.com> >> --- >> >> Toralf, Thanks for reporting the bug. I'm not able to repy to your email, >> because I was kicked out of the cgroup mailing list so didn't receive >> emails from mailing list for a week. >> >> --- >> kernel/cgroup.c | 19 +++++++++---------- >> 1 file changed, 9 insertions(+), 10 deletions(-) >> >> diff --git a/kernel/cgroup.c b/kernel/cgroup.c >> index 1c56924..e03fc62 100644 >> --- a/kernel/cgroup.c >> +++ b/kernel/cgroup.c >> @@ -4185,6 +4185,15 @@ static void css_release_work_fn(struct work_struct *work) >> >> mutex_unlock(&cgroup_mutex); >> >> + /* >> + * There are two control paths which try to determine cgroup from >> + * dentry without going through kernfs - cgroupstats_build() and >> + * css_tryget_online_from_dir(). Those are supported by RCU >> + * protecting clearing of cgrp->kn->priv backpointer. >> + */ >> + if (!ss && cgroup_parent(cgrp)) >> + RCU_INIT_POINTER(*(void __rcu __force **)&cgrp->kn->priv, NULL); > > Can we move the above into the preceding else block? I don't think > holding cgroup_mutex or not makes any difference here. > Also, why do > we need the cgroup_parent() check? Do we deref root's kn->priv in the > destruction path? If so, can you please note that in the comment? > I think the check is not necessary. I was trying to make smaller difference than the original code, and RCU_INIT_POINTER() is in cgroup_rmdir() which won't be called on root cgroup.
WARNING: multiple messages have this Message-ID (diff)
From: Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> To: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> Cc: "Toralf Förster" <toralf.foerster-Mmb7MZpHnFY@public.gmane.org>, LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, cgroups <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> Subject: Re: [PATCH 1/2] cgroup: Delay the clearing of cgrp->kn->priv Date: Thu, 4 Sep 2014 11:35:30 +0800 [thread overview] Message-ID: <5407DE02.8090805@huawei.com> (raw) In-Reply-To: <20140902153301.GA17424-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org> 于 2014/9/2 23:33, Tejun Heo 写道: > Hello, Li. > > On Tue, Sep 02, 2014 at 06:56:58PM +0800, Li Zefan wrote: >> for ((; ;)) >> { >> echo $$ > /cgroup/sub/cgroup.procs >> ech $$ > /cgce 6f2e0c38c2108a74 ]--- > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > copy & paste error? > ... oops >> Reported-by: Toralf Förster <toralf.foerster-Mmb7MZpHnFY@public.gmane.org> >> Signed-off-by: Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> >> --- >> >> Toralf, Thanks for reporting the bug. I'm not able to repy to your email, >> because I was kicked out of the cgroup mailing list so didn't receive >> emails from mailing list for a week. >> >> --- >> kernel/cgroup.c | 19 +++++++++---------- >> 1 file changed, 9 insertions(+), 10 deletions(-) >> >> diff --git a/kernel/cgroup.c b/kernel/cgroup.c >> index 1c56924..e03fc62 100644 >> --- a/kernel/cgroup.c >> +++ b/kernel/cgroup.c >> @@ -4185,6 +4185,15 @@ static void css_release_work_fn(struct work_struct *work) >> >> mutex_unlock(&cgroup_mutex); >> >> + /* >> + * There are two control paths which try to determine cgroup from >> + * dentry without going through kernfs - cgroupstats_build() and >> + * css_tryget_online_from_dir(). Those are supported by RCU >> + * protecting clearing of cgrp->kn->priv backpointer. >> + */ >> + if (!ss && cgroup_parent(cgrp)) >> + RCU_INIT_POINTER(*(void __rcu __force **)&cgrp->kn->priv, NULL); > > Can we move the above into the preceding else block? I don't think > holding cgroup_mutex or not makes any difference here. > Also, why do > we need the cgroup_parent() check? Do we deref root's kn->priv in the > destruction path? If so, can you please note that in the comment? > I think the check is not necessary. I was trying to make smaller difference than the original code, and RCU_INIT_POINTER() is in cgroup_rmdir() which won't be called on root cgroup.
next prev parent reply other threads:[~2014-09-04 3:35 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-09-02 10:56 [PATCH 1/2] cgroup: Delay the clearing of cgrp->kn->priv Li Zefan 2014-09-02 10:56 ` Li Zefan 2014-09-02 10:57 ` [PATCH 2/2] cgroup: check cgroup liveliness before unbreaking kernfs protection Li Zefan 2014-09-02 10:57 ` Li Zefan 2014-09-02 15:51 ` Tejun Heo 2014-09-02 15:51 ` Tejun Heo 2014-09-02 15:33 ` [PATCH 1/2] cgroup: Delay the clearing of cgrp->kn->priv Tejun Heo 2014-09-02 15:33 ` Tejun Heo 2014-09-04 3:35 ` Li Zefan [this message] 2014-09-04 3:35 ` Li Zefan
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=5407DE02.8090805@huawei.com \ --to=lizefan@huawei.com \ --cc=cgroups@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=tj@kernel.org \ --cc=toralf.foerster@gmx.de \ /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: linkBe 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.