From: Junnan Zhang <zhangjn_dev@163.com>
To: tj@kernel.org, hannes@cmpxchg.org, mkoutny@suse.com
Cc: cgroups@vger.kernel.org, linux-kernel@vger.kernel.org,
zhangjn_dev@163.com, Junnan Zhang <zhangjn11@chinatelecom.cn>,
Shouxin Sun <sunshx@chinatelecom.cn>
Subject: [PATCH] cgroup: avoid flushing global workqueue in cgroup1_pidlist_destroy_all
Date: Fri, 14 Aug 2026 16:40:16 +0800 [thread overview]
Message-ID: <20260814084016.123741-1-zhangjn_dev@163.com> (raw)
From: Junnan Zhang <zhangjn11@chinatelecom.cn>
cgroup1_pidlist_destroy_all() flushes the global
cgroup_pidlist_destroy_wq while destroying a cgroup. Because all cgroup
v1 pidlist destruction work items are queued on the same shared workqueue,
a single slow or stuck work item (e.g. waiting for pidlist_mutex held by a
user-space reader) blocks every concurrent cgroup destruction path.
This can lead to kworker tasks stuck in flush_workqueue() for over
hung_task_timeout seconds, as observed on busy systems running Docker or
Kubernetes workloads.
INFO: task kworker/0:1:1438499 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kworker/0:1 D 0 1438499 2 0x80000080
Workqueue: cgroup_destroy css_free_rwork_fn
? __schedule+0x296/0x900
schedule+0x28/0x80
schedule_timeout+0x1ee/0x3a0
? kvm_sched_clock_read+0xd/0x20
wait_for_completion+0x12c/0x190
? wake_up_q+0x70/0x70
flush_workqueue+0x132/0x430
? cgroup1_pidlist_destroy_all+0x7c/0xa0
cgroup1_pidlist_destroy_all+0x7c/0xa0
css_free_rwork_fn+0xb5/0x390
process_one_work+0x195/0x3e0
worker_thread+0x30/0x390
? process_one_work+0x3e0/0x3e0
kthread+0x113/0x130
? kthread_create_worker_on_cpu+0x70/0x70
ret_from_fork+0x1f/0x40
Fix it by moving the cgroup's pidlists to a local orphan list under
pidlist_mutex, clearing their ->owner pointer, and then cancelling each
pidlist's delayed work outside the lock. The destroy work function now
checks ->owner and skips freeing orphaned pidlists, so
cgroup1_pidlist_destroy_all() can free them safely without flushing the
whole shared workqueue.
Signed-off-by: Junnan Zhang <zhangjn11@chinatelecom.cn>
Signed-off-by: Shouxin Sun <sunshx@chinatelecom.cn>
---
kernel/cgroup/cgroup-v1.c | 53 ++++++++++++++++++++++++++++-----------
1 file changed, 38 insertions(+), 15 deletions(-)
diff --git a/kernel/cgroup/cgroup-v1.c b/kernel/cgroup/cgroup-v1.c
index a4337c9b5287..874fe4dc6ffd 100644
--- a/kernel/cgroup/cgroup-v1.c
+++ b/kernel/cgroup/cgroup-v1.c
@@ -206,13 +206,31 @@ struct cgroup_pidlist {
void cgroup1_pidlist_destroy_all(struct cgroup *cgrp)
{
struct cgroup_pidlist *l, *tmp_l;
+ LIST_HEAD(orphan);
+
+ /*
+ * Move pidlists to a local orphan list and mark them as owner-less.
+ * The destroy work function will see ->owner == NULL and skip freeing.
+ * We then cancel and free them outside pidlist_mutex to avoid
+ * flush_workqueue() blocking on the shared workqueue.
+ */
mutex_lock(&cgrp->pidlist_mutex);
- list_for_each_entry_safe(l, tmp_l, &cgrp->pidlists, links)
- mod_delayed_work(cgroup_pidlist_destroy_wq, &l->destroy_dwork, 0);
+ list_for_each_entry_safe(l, tmp_l, &cgrp->pidlists, links) {
+ list_del(&l->links);
+ l->owner = NULL;
+ list_add(&l->links, &orphan);
+ }
mutex_unlock(&cgrp->pidlist_mutex);
- flush_workqueue(cgroup_pidlist_destroy_wq);
+ list_for_each_entry_safe(l, tmp_l, &orphan, links) {
+ list_del(&l->links);
+ cancel_delayed_work_sync(&l->destroy_dwork);
+ kvfree(l->list);
+ put_pid_ns(l->key.ns);
+ kfree(l);
+ }
+
BUG_ON(!list_empty(&cgrp->pidlists));
}
@@ -222,21 +240,26 @@ static void cgroup_pidlist_destroy_work_fn(struct work_struct *work)
struct cgroup_pidlist *l = container_of(dwork, struct cgroup_pidlist,
destroy_dwork);
struct cgroup_pidlist *tofree = NULL;
+ struct cgroup *owner;
- mutex_lock(&l->owner->pidlist_mutex);
+ owner = l->owner;
+ if (owner) {
+ mutex_lock(&owner->pidlist_mutex);
- /*
- * Destroy iff we didn't get queued again. The state won't change
- * as destroy_dwork can only be queued while locked.
- */
- if (!delayed_work_pending(dwork)) {
- list_del(&l->links);
- kvfree(l->list);
- put_pid_ns(l->key.ns);
- tofree = l;
- }
+ /*
+ * Destroy iff we didn't get queued again and we're still
+ * owned by the cgroup. If ->owner was cleared by
+ * cgroup1_pidlist_destroy_all(), it will free us.
+ */
+ if (l->owner == owner && !delayed_work_pending(dwork)) {
+ list_del(&l->links);
+ kvfree(l->list);
+ put_pid_ns(l->key.ns);
+ tofree = l;
+ }
- mutex_unlock(&l->owner->pidlist_mutex);
+ mutex_unlock(&l->owner->pidlist_mutex);
+ }
kfree(tofree);
}
--
2.43.0
next reply other threads:[~2026-08-14 8:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-14 8:40 Junnan Zhang [this message]
2026-08-14 9:45 ` [PATCH v2] cgroup: avoid flushing global workqueue in cgroup1_pidlist_destroy_all Junnan Zhang
2026-08-14 10:20 ` [PATCH v3] " Junnan Zhang
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=20260814084016.123741-1-zhangjn_dev@163.com \
--to=zhangjn_dev@163.com \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mkoutny@suse.com \
--cc=sunshx@chinatelecom.cn \
--cc=tj@kernel.org \
--cc=zhangjn11@chinatelecom.cn \
/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.