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: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <afHNg2VX2jy9bW7y@piware.de>
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox