[openeuler:openEuler-1.0-LTS 1941/1941] kernel/cgroup/cgroup.c:2240: warning: Excess function parameter 'lock_threadgroup' description in 'cgroup_attach_lock'

[kernel test robot <lkp@intel.com>]

Hi Tejun,

FYI, the error/warning still remains.

tree:   https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS
head:   5a399b91821faeec2466751db2d714b24f8eb17c
commit: 4924308a1ca9cc2f791398836a8744c22078ffbd [1941/1941] cgroup: Fix threadgroup_rwsem <-> cpus_read_lock() deadlock
config: arm64-allnoconfig-bpf (https://download.01.org/0day-ci/archive/20251213/202512132306.9jtRj6o7-lkp@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 15.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251213/202512132306.9jtRj6o7-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/202512132306.9jtRj6o7-lkp@intel.com/

All warnings (new ones prefixed by >>):

>> kernel/cgroup/cgroup.c:2240: warning: Excess function parameter 'lock_threadgroup' description in 'cgroup_attach_lock'
>> kernel/cgroup/cgroup.c:2250: warning: Excess function parameter 'lock_threadgroup' description in 'cgroup_attach_unlock'


vim +2240 kernel/cgroup/cgroup.c

  2215	
  2216	/**
  2217	 * cgroup_attach_lock - Lock for ->attach()
  2218	 * @lock_threadgroup: whether to down_write cgroup_threadgroup_rwsem
  2219	 *
  2220	 * cgroup migration sometimes needs to stabilize threadgroups against forks and
  2221	 * exits by write-locking cgroup_threadgroup_rwsem. However, some ->attach()
  2222	 * implementations (e.g. cpuset), also need to disable CPU hotplug.
  2223	 * Unfortunately, letting ->attach() operations acquire cpus_read_lock() can
  2224	 * lead to deadlocks.
  2225	 *
  2226	 * Bringing up a CPU may involve creating and destroying tasks which requires
  2227	 * read-locking threadgroup_rwsem, so threadgroup_rwsem nests inside
  2228	 * cpus_read_lock(). If we call an ->attach() which acquires the cpus lock while
  2229	 * write-locking threadgroup_rwsem, the locking order is reversed and we end up
  2230	 * waiting for an on-going CPU hotplug operation which in turn is waiting for
  2231	 * the threadgroup_rwsem to be released to create new tasks. For more details:
  2232	 *
  2233	 *   http://lkml.kernel.org/r/20220711174629.uehfmqegcwn2lqzu@wubuntu
  2234	 *
  2235	 * Resolve the situation by always acquiring cpus_read_lock() before optionally
  2236	 * write-locking cgroup_threadgroup_rwsem. This allows ->attach() to assume that
  2237	 * CPU hotplug is disabled on entry.
  2238	 */
  2239	static void cgroup_attach_lock(void)
> 2240	{
  2241		cpus_read_lock();
  2242		percpu_down_write(&cgroup_threadgroup_rwsem);
  2243	}
  2244	
  2245	/**
  2246	 * cgroup_attach_unlock - Undo cgroup_attach_lock()
  2247	 * @lock_threadgroup: whether to up_write cgroup_threadgroup_rwsem
  2248	 */
  2249	static void cgroup_attach_unlock(void)
> 2250	{
  2251		percpu_up_write(&cgroup_threadgroup_rwsem);
  2252		cpus_read_unlock();
  2253	}
  2254	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki