From: kernel test robot <lkp@intel.com>
To: Tejun Heo <tj@kernel.org>, Martin Pitt <martin@piware.de>
Cc: oe-kbuild-all@lists.linux.dev, regressions@lists.linux.dev,
cgroups@vger.kernel.org, lizefan.x@bytedance.com,
hannes@cmpxchg.org,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
linux-kernel@vger.kernel.org, Tejun Heo <tj@kernel.org>
Subject: Re: [PATCH] cgroup: Defer css percpu_ref kill on rmdir until cgroup is depopulated
Date: Mon, 4 May 2026 04:15:33 +0800 [thread overview]
Message-ID: <202605040408.yt7xcKug-lkp@intel.com> (raw)
In-Reply-To: <20260501022943.3714461-1-tj@kernel.org>
Hi Tejun,
kernel test robot noticed the following build warnings:
[auto build test WARNING on tj-cgroup/for-next]
[also build test WARNING on linus/master next-20260430]
[cannot apply to v7.1-rc1]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Tejun-Heo/cgroup-Defer-css-percpu_ref-kill-on-rmdir-until-cgroup-is-depopulated/20260503-165802
base: https://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git for-next
patch link: https://lore.kernel.org/r/20260501022943.3714461-1-tj%40kernel.org
patch subject: [PATCH] cgroup: Defer css percpu_ref kill on rmdir until cgroup is depopulated
config: powerpc-randconfig-r071-20260504 (https://download.01.org/0day-ci/archive/20260504/202605040408.yt7xcKug-lkp@intel.com/config)
compiler: powerpc-linux-gcc (GCC) 8.5.0
smatch: v0.5.0-9065-ge9cc34fd
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260504/202605040408.yt7xcKug-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202605040408.yt7xcKug-lkp@intel.com/
All warnings (new ones prefixed by >>):
kernel/cgroup/cgroup.c: In function 'cgroup_apply_control_disable':
kernel/cgroup/cgroup.c:3391:5: error: implicit declaration of function 'kill_css_sync'; did you mean 'kill_fasync'? [-Werror=implicit-function-declaration]
kill_css_sync(css);
^~~~~~~~~~~~~
kill_fasync
kernel/cgroup/cgroup.c:3392:5: error: implicit declaration of function 'kill_css_finish'; did you mean 'kill_cad_pid'? [-Werror=implicit-function-declaration]
kill_css_finish(css);
^~~~~~~~~~~~~~~
kill_cad_pid
kernel/cgroup/cgroup.c: At top level:
>> kernel/cgroup/cgroup.c:6047:13: warning: conflicting types for 'kill_css_sync'
static void kill_css_sync(struct cgroup_subsys_state *css)
^~~~~~~~~~~~~
kernel/cgroup/cgroup.c:6047:13: error: static declaration of 'kill_css_sync' follows non-static declaration
kernel/cgroup/cgroup.c:3391:5: note: previous implicit declaration of 'kill_css_sync' was here
kill_css_sync(css);
^~~~~~~~~~~~~
>> kernel/cgroup/cgroup.c:6087:13: warning: conflicting types for 'kill_css_finish'
static void kill_css_finish(struct cgroup_subsys_state *css)
^~~~~~~~~~~~~~~
kernel/cgroup/cgroup.c:6087:13: error: static declaration of 'kill_css_finish' follows non-static declaration
kernel/cgroup/cgroup.c:3392:5: note: previous implicit declaration of 'kill_css_finish' was here
kill_css_finish(css);
^~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/kill_css_sync +6047 kernel/cgroup/cgroup.c
6040
6041 /**
6042 * kill_css_sync - synchronous half of css teardown
6043 * @css: css being killed
6044 *
6045 * See cgroup_destroy_locked().
6046 */
> 6047 static void kill_css_sync(struct cgroup_subsys_state *css)
6048 {
6049 struct cgroup_subsys *ss = css->ss;
6050
6051 lockdep_assert_held(&cgroup_mutex);
6052
6053 if (css->flags & CSS_DYING)
6054 return;
6055
6056 /*
6057 * Call css_killed(), if defined, before setting the CSS_DYING flag
6058 */
6059 if (css->ss->css_killed)
6060 css->ss->css_killed(css);
6061
6062 css->flags |= CSS_DYING;
6063
6064 /*
6065 * This must happen before css is disassociated with its cgroup.
6066 * See seq_css() for details.
6067 */
6068 css_clear_dir(css);
6069
6070 css->cgroup->nr_dying_subsys[ss->id]++;
6071 /*
6072 * Parent css and cgroup cannot be freed until after the freeing
6073 * of child css, see css_free_rwork_fn().
6074 */
6075 while ((css = css->parent)) {
6076 css->nr_descendants--;
6077 css->cgroup->nr_dying_subsys[ss->id]++;
6078 }
6079 }
6080
6081 /**
6082 * kill_css_finish - deferred half of css teardown
6083 * @css: css being killed
6084 *
6085 * See cgroup_destroy_locked().
6086 */
> 6087 static void kill_css_finish(struct cgroup_subsys_state *css)
6088 {
6089 lockdep_assert_held(&cgroup_mutex);
6090
6091 /*
6092 * Skip on re-entry: cgroup_apply_control_disable() may have killed @css
6093 * earlier. cgroup_destroy_locked() can still walk it because
6094 * offline_css() (which NULLs cgrp->subsys[ssid]) runs async.
6095 */
6096 if (percpu_ref_is_dying(&css->refcnt))
6097 return;
6098
6099 /*
6100 * Killing would put the base ref, but we need to keep it alive until
6101 * after ->css_offline().
6102 */
6103 css_get(css);
6104
6105 /*
6106 * cgroup core guarantees that, by the time ->css_offline() is invoked,
6107 * no new css reference will be given out via css_tryget_online(). We
6108 * can't simply call percpu_ref_kill() and proceed to offlining css's
6109 * because percpu_ref_kill() doesn't guarantee that the ref is seen as
6110 * killed on all CPUs on return.
6111 *
6112 * Use percpu_ref_kill_and_confirm() to get notifications as each css is
6113 * confirmed to be seen as killed on all CPUs.
6114 */
6115 percpu_ref_kill_and_confirm(&css->refcnt, css_killed_ref_fn);
6116 }
6117
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
next prev parent reply other threads:[~2026-05-03 20:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-29 9:21 [REGRESSION] 6.9.11: systemd hangs in cgroup_drain_dying during cleanup after podman operations Martin Pitt
2026-04-29 16:21 ` Tejun Heo
2026-04-29 21:15 ` Tejun Heo
2026-04-30 6:15 ` Martin Pitt
2026-05-01 2:29 ` [PATCH] cgroup: Defer css percpu_ref kill on rmdir until cgroup is depopulated Tejun Heo
2026-05-03 19:30 ` kernel test robot
2026-05-03 20:15 ` kernel test robot [this message]
2026-05-03 22:45 ` kernel test robot
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=202605040408.yt7xcKug-lkp@intel.com \
--to=lkp@intel.com \
--cc=bigeasy@linutronix.de \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan.x@bytedance.com \
--cc=martin@piware.de \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=regressions@lists.linux.dev \
--cc=tj@kernel.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.