From: Waiman Long <llong-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Zefan Li <lizefan.x-EC8Uxl6Npydl57MIdRCFDg@public.gmane.org>,
Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>,
Juri Lelli <juri.lelli-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 1/2] cgroup: Fix incorrect warning from cgroup_apply_control_disable()
Date: Mon, 13 Sep 2021 14:43:44 -0400 [thread overview]
Message-ID: <dbb1a221-b3d2-5086-e47b-8a2c764d60ad@redhat.com> (raw)
In-Reply-To: <125c4202-68d1-1a4e-03d6-2b18f0794ba4-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On 9/13/21 2:35 PM, Waiman Long wrote:
> On 9/13/21 2:05 PM, Tejun Heo wrote:
>> Hello,
>>
>> On Thu, Sep 09, 2021 at 10:42:55PM -0400, Waiman Long wrote:
>>> diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
>>> index 881ce1470beb..e31bca9fcd46 100644
>>> --- a/kernel/cgroup/cgroup.c
>>> +++ b/kernel/cgroup/cgroup.c
>>> @@ -3140,7 +3140,16 @@ static void
>>> cgroup_apply_control_disable(struct cgroup *cgrp)
>>> if (!css)
>>> continue;
>>> - WARN_ON_ONCE(percpu_ref_is_dying(&css->refcnt));
>>> + /*
>>> + * A kill_css() might have been called previously, but
>>> + * the css may still linger for a while before being
>>> + * removed. Skip it in this case.
>>> + */
>>> + if (percpu_ref_is_dying(&css->refcnt)) {
>>> + WARN_ON_ONCE(css->parent &&
>>> + cgroup_ss_mask(dsct) & (1 << ss->id));
>>> + continue;
>>> + }
>> This warning did help me catch some gnarly bugs. Any chance we can
>> keep it
>> for normal cases and elide it just for remounting?
>
> The problem with percpu_ref_is_dying() is the fact that it becomes
> true after percpu_ref_exit() is called in css_free_rwork_fn() which
> has an RCU delay. If you want to catch the fact that kill_css() has
> been called, we can check the CSS_DYING flag which is set in
> kill_css() by commit 33c35aa481786 ("cgroup: Prevent kill_css() from
> being called more than once"). Will that be an acceptable alternative?
Something like
diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index 881ce1470beb..851e54800ad8 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -3140,6 +3140,9 @@ static void cgroup_apply_control_disable(struct
cgroup *cg
if (!css)
continue;
+ if (css->flags & CSS_DYING)
+ continue;
+
WARN_ON_ONCE(percpu_ref_is_dying(&css->refcnt));
if (css->parent &&
Cheers,
Longman
WARNING: multiple messages have this Message-ID (diff)
From: Waiman Long <llong@redhat.com>
To: Tejun Heo <tj@kernel.org>
Cc: Zefan Li <lizefan.x@bytedance.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Juri Lelli <juri.lelli@redhat.com>,
cgroups@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] cgroup: Fix incorrect warning from cgroup_apply_control_disable()
Date: Mon, 13 Sep 2021 14:43:44 -0400 [thread overview]
Message-ID: <dbb1a221-b3d2-5086-e47b-8a2c764d60ad@redhat.com> (raw)
In-Reply-To: <125c4202-68d1-1a4e-03d6-2b18f0794ba4@redhat.com>
On 9/13/21 2:35 PM, Waiman Long wrote:
> On 9/13/21 2:05 PM, Tejun Heo wrote:
>> Hello,
>>
>> On Thu, Sep 09, 2021 at 10:42:55PM -0400, Waiman Long wrote:
>>> diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
>>> index 881ce1470beb..e31bca9fcd46 100644
>>> --- a/kernel/cgroup/cgroup.c
>>> +++ b/kernel/cgroup/cgroup.c
>>> @@ -3140,7 +3140,16 @@ static void
>>> cgroup_apply_control_disable(struct cgroup *cgrp)
>>> if (!css)
>>> continue;
>>> - WARN_ON_ONCE(percpu_ref_is_dying(&css->refcnt));
>>> + /*
>>> + * A kill_css() might have been called previously, but
>>> + * the css may still linger for a while before being
>>> + * removed. Skip it in this case.
>>> + */
>>> + if (percpu_ref_is_dying(&css->refcnt)) {
>>> + WARN_ON_ONCE(css->parent &&
>>> + cgroup_ss_mask(dsct) & (1 << ss->id));
>>> + continue;
>>> + }
>> This warning did help me catch some gnarly bugs. Any chance we can
>> keep it
>> for normal cases and elide it just for remounting?
>
> The problem with percpu_ref_is_dying() is the fact that it becomes
> true after percpu_ref_exit() is called in css_free_rwork_fn() which
> has an RCU delay. If you want to catch the fact that kill_css() has
> been called, we can check the CSS_DYING flag which is set in
> kill_css() by commit 33c35aa481786 ("cgroup: Prevent kill_css() from
> being called more than once"). Will that be an acceptable alternative?
Something like
diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index 881ce1470beb..851e54800ad8 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -3140,6 +3140,9 @@ static void cgroup_apply_control_disable(struct
cgroup *cg
if (!css)
continue;
+ if (css->flags & CSS_DYING)
+ continue;
+
WARN_ON_ONCE(percpu_ref_is_dying(&css->refcnt));
if (css->parent &&
Cheers,
Longman
next prev parent reply other threads:[~2021-09-13 18:43 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-10 2:42 [PATCH 1/2] cgroup: Fix incorrect warning from cgroup_apply_control_disable() Waiman Long
2021-09-10 2:42 ` Waiman Long
[not found] ` <20210910024256.7615-1-longman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2021-09-10 2:42 ` [PATCH 2/2] cgroup/cpuset: Change references of cpuset_mutex to cpuset_rwsem Waiman Long
2021-09-10 2:42 ` Waiman Long
2021-09-13 18:06 ` Tejun Heo
2021-09-13 18:05 ` [PATCH 1/2] cgroup: Fix incorrect warning from cgroup_apply_control_disable() Tejun Heo
2021-09-13 18:05 ` Tejun Heo
[not found] ` <YT+TA6ItnF9xM3cR-NiLfg/pYEd1N0TnZuCh8vA@public.gmane.org>
2021-09-13 18:35 ` Waiman Long
2021-09-13 18:35 ` Waiman Long
[not found] ` <125c4202-68d1-1a4e-03d6-2b18f0794ba4-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2021-09-13 18:40 ` Tejun Heo
2021-09-13 18:40 ` Tejun Heo
2021-09-13 18:43 ` Waiman Long [this message]
2021-09-13 18:43 ` Waiman Long
[not found] ` <dbb1a221-b3d2-5086-e47b-8a2c764d60ad-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2021-09-13 18:45 ` Tejun Heo
2021-09-13 18:45 ` Tejun Heo
[not found] ` <YT+cPPyDPimHibSC-NiLfg/pYEd1N0TnZuCh8vA@public.gmane.org>
2021-09-13 18:46 ` Waiman Long
2021-09-13 18:46 ` Waiman Long
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=dbb1a221-b3d2-5086-e47b-8a2c764d60ad@redhat.com \
--to=llong-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org \
--cc=juri.lelli-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=lizefan.x-EC8Uxl6Npydl57MIdRCFDg@public.gmane.org \
--cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
/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: link
Be 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.