From: "Michal Koutný" <mkoutny-IBi9RG/b67k@public.gmane.org>
To: cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Zefan Li <lizefan.x-EC8Uxl6Npydl57MIdRCFDg@public.gmane.org>,
Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>,
Bui Quang Minh
<minhquangbui99-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Tadeusz Struk
<tadeusz.struk-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Subject: [PATCH 1/2] cgroup: Wait for cgroup_subsys_state offlining on unmount
Date: Wed, 25 May 2022 17:15:16 +0200 [thread overview]
Message-ID: <20220525151517.8430-2-mkoutny@suse.com> (raw)
In-Reply-To: <20220525151517.8430-1-mkoutny-IBi9RG/b67k@public.gmane.org>
The reported problem here occurs when cgroup hierarchy is unmounted
quickly after last cgroup removal. The last cgroup prevents the root
cgroup css->refcnt from being killed. The respective cgroup root thus
remains permanently in existence.
This is actually intended behavior for memory controller whose state is
long-lived and there is no better option to attach it later (see also
commit 3c606d35fe97 ("cgroup: prevent mount hang due to memory
controller lifetime")).
We can make the situation better by checking children list only after
any cgroups in the middle of removal are gone, detected via
cgroup_destroy_wq.
Reported-by: Bui Quang Minh <minhquangbui99-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Link: https://lore.kernel.org/r/20220404142535.145975-1-minhquangbui99-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Signed-off-by: Michal Koutn√Ω <mkoutny-IBi9RG/b67k@public.gmane.org>
---
kernel/cgroup/cgroup.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index adb820e98f24..a5b0d5d54fbc 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -2205,11 +2205,14 @@ static void cgroup_kill_sb(struct super_block *sb)
struct cgroup_root *root = cgroup_root_from_kf(kf_root);
/*
- * If @root doesn't have any children, start killing it.
+ * If @root doesn't have any children held by residual state (e.g.
+ * memory controller), start killing it, flush workqueue to filter out
+ * transiently offlined children.
* This prevents new mounts by disabling percpu_ref_tryget_live().
*
* And don't kill the default root.
*/
+ flush_workqueue(cgroup_destroy_wq);
if (list_empty(&root->cgrp.self.children) && root != &cgrp_dfl_root &&
!percpu_ref_is_dying(&root->cgrp.self.refcnt)) {
cgroup_bpf_offline(&root->cgrp);
--
2.35.3
next prev parent reply other threads:[~2022-05-25 15:15 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-25 15:15 [PATCH 0/2] cgroup_subsys_state lifecycle fixups Michal Koutný
[not found] ` <20220525151517.8430-1-mkoutny-IBi9RG/b67k@public.gmane.org>
2022-05-25 15:15 ` Michal Koutný [this message]
2022-05-25 15:15 ` [PATCH 2/2] cgroup: Use separate work structs on css release path Michal Koutný
[not found] ` <20220525151517.8430-3-mkoutny-IBi9RG/b67k@public.gmane.org>
2022-05-25 16:14 ` Michal Koutný
[not found] ` <20220525161455.GA16134-9OudH3eul5jcvrawFnH+a6VXKuFTiq87@public.gmane.org>
2022-05-26 9:56 ` Michal Koutný
2022-05-26 18:15 ` Tejun Heo
[not found] ` <Yo/DtjEU/kYr190u-NiLfg/pYEd1N0TnZuCh8vA@public.gmane.org>
2022-05-27 16:39 ` Tadeusz Struk
[not found] ` <904ef8af-13a5-e566-b760-74519f70fa62-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2022-05-27 16:54 ` Michal Koutný
[not found] ` <20220527165429.GJ11007-9OudH3eul5jcvrawFnH+a6VXKuFTiq87@public.gmane.org>
2022-05-27 17:23 ` Tejun Heo
2022-06-01 23:13 ` Tadeusz Struk
[not found] ` <0babd7df-bdef-9edc-3682-1144bc0c2d2b-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2022-06-01 23:20 ` Tejun Heo
[not found] ` <Ypf0VnKUMiuRgZqT-NiLfg/pYEd1N0TnZuCh8vA@public.gmane.org>
2022-06-01 23:37 ` Tadeusz Struk
[not found] ` <1fb4d8d7-ccc0-b020-715e-38c2dfd94c23-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2022-06-01 23:43 ` Tejun Heo
[not found] ` <Ypf5jpI7dSmpi4W0-NiLfg/pYEd1N0TnZuCh8vA@public.gmane.org>
2022-06-02 0:00 ` Tadeusz Struk
[not found] ` <c3bd8e63-7204-f86d-8efa-254db71185fc-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2022-06-02 0:07 ` Tejun Heo
[not found] ` <Ypf/MpwzByOrSp6A-NiLfg/pYEd1N0TnZuCh8vA@public.gmane.org>
2022-06-02 0:26 ` Tadeusz Struk
[not found] ` <416dc60a-f0e5-7d05-1613-3cd0ca415768-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2022-06-02 0:29 ` Tejun Heo
[not found] ` <YpgEY/lJbLidLOhc-NiLfg/pYEd1N0TnZuCh8vA@public.gmane.org>
2022-06-02 0:40 ` Tadeusz Struk
[not found] ` <0fd1c3fd-fa86-dbed-f3f0-74c91b1efa11-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2022-06-02 11:47 ` Michal Koutný
[not found] ` <20220602114705.GB21320-9OudH3eul5jcvrawFnH+a6VXKuFTiq87@public.gmane.org>
2022-06-02 14:28 ` Tadeusz Struk
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=20220525151517.8430-2-mkoutny@suse.com \
--to=mkoutny-ibi9rg/b67k@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=lizefan.x-EC8Uxl6Npydl57MIdRCFDg@public.gmane.org \
--cc=minhquangbui99-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=tadeusz.struk-QSEj5FYQhm4dnm+yROfE0A@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox