All of lore.kernel.org
 help / color / mirror / Atom feed
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 03:30:48 +0800	[thread overview]
Message-ID: <202605040315.QbFTzfWy-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: m68k-allmodconfig (https://download.01.org/0day-ci/archive/20260504/202605040315.QbFTzfWy-lkp@intel.com/config)
compiler: m68k-linux-gcc (GCC) 15.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260504/202605040315.QbFTzfWy-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/202605040315.QbFTzfWy-lkp@intel.com/

All warnings (new ones prefixed by >>):

   kernel/cgroup/cgroup.c: In function 'cgroup_apply_control_disable':
   kernel/cgroup/cgroup.c:3391:33: error: implicit declaration of function 'kill_css_sync'; did you mean 'kill_fasync'? [-Wimplicit-function-declaration]
    3391 |                                 kill_css_sync(css);
         |                                 ^~~~~~~~~~~~~
         |                                 kill_fasync
   kernel/cgroup/cgroup.c:3392:33: error: implicit declaration of function 'kill_css_finish' [-Wimplicit-function-declaration]
    3392 |                                 kill_css_finish(css);
         |                                 ^~~~~~~~~~~~~~~
   kernel/cgroup/cgroup.c: At top level:
>> kernel/cgroup/cgroup.c:6047:13: warning: conflicting types for 'kill_css_sync'; have 'void(struct cgroup_subsys_state *)'
    6047 | 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:33: note: previous implicit declaration of 'kill_css_sync' with type 'void(struct cgroup_subsys_state *)'
    3391 |                                 kill_css_sync(css);
         |                                 ^~~~~~~~~~~~~
>> kernel/cgroup/cgroup.c:6087:13: warning: conflicting types for 'kill_css_finish'; have 'void(struct cgroup_subsys_state *)'
    6087 | 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:33: note: previous implicit declaration of 'kill_css_finish' with type 'void(struct cgroup_subsys_state *)'
    3392 |                                 kill_css_finish(css);
         |                                 ^~~~~~~~~~~~~~~


vim +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

  reply	other threads:[~2026-05-03 19:32 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 [this message]
2026-05-03 20:15   ` kernel test robot
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=202605040315.QbFTzfWy-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.