From: kernel test robot <lkp@intel.com>
To: Aaron Tomlin <atomlin@atomlin.com>
Cc: llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev,
0day robot <lkp@intel.com>
Subject: kernel/cgroup/cpuset.c:3032:9: error: use of undeclared label 'out_unlock_reset'
Date: Thu, 14 May 2026 02:46:49 +0200 [thread overview]
Message-ID: <202605140212.cspkpyDl-lkp@intel.com> (raw)
tree: https://github.com/intel-lab-lkp/linux/commits/Aaron-Tomlin/cgroup-cpuset-Fix-deadline-bandwidth-leak-in-cpuset_can_attach/20260513-233840
head: 6b7a0366d38d3efa80d721b02d588f3f519aa8b3
commit: 6c37dfa9b4198303c230c525e0796e883dde1624 cgroup/cpuset: Fix deadline bandwidth leak in cpuset_can_attach()
date: 9 hours ago
config: x86_64-kexec (https://download.01.org/0day-ci/archive/20260514/202605140212.cspkpyDl-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260514/202605140212.cspkpyDl-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/202605140212.cspkpyDl-lkp@intel.com/
All errors (new ones prefixed by >>):
>> kernel/cgroup/cpuset.c:3032:9: error: use of undeclared label 'out_unlock_reset'
3032 | goto out_unlock_reset;
| ^
kernel/cgroup/cpuset.c:3604:1: warning: unused label 'out_unlock_reset' [-Wunused-label]
3604 | out_unlock_reset:
| ^~~~~~~~~~~~~~~~~
1 warning and 1 error generated.
vim +/out_unlock_reset +3032 kernel/cgroup/cpuset.c
2988
2989 /* Called by cgroups to determine if a cpuset is usable; cpuset_mutex held */
2990 static int cpuset_can_attach(struct cgroup_taskset *tset)
2991 {
2992 struct cgroup_subsys_state *css;
2993 struct cpuset *cs, *oldcs;
2994 struct task_struct *task;
2995 bool setsched_check;
2996 int cpu, ret;
2997
2998 /* used later by cpuset_attach() */
2999 cpuset_attach_old_cs = task_cs(cgroup_taskset_first(tset, &css));
3000 oldcs = cpuset_attach_old_cs;
3001 cs = css_cs(css);
3002
3003 mutex_lock(&cpuset_mutex);
3004
3005 /* Check to see if task is allowed in the cpuset */
3006 ret = cpuset_can_attach_check(cs);
3007 if (ret)
3008 goto out_unlock;
3009
3010 /*
3011 * Skip rights over task setsched check in v2 when nothing changes,
3012 * migration permission derives from hierarchy ownership in
3013 * cgroup_procs_write_permission()).
3014 */
3015 setsched_check = !cpuset_v2() ||
3016 !cpumask_equal(cs->effective_cpus, oldcs->effective_cpus) ||
3017 !nodes_equal(cs->effective_mems, oldcs->effective_mems);
3018
3019 /*
3020 * A v1 cpuset with tasks will have no CPU left only when CPU hotplug
3021 * brings the last online CPU offline as users are not allowed to empty
3022 * cpuset.cpus when there are active tasks inside. When that happens,
3023 * we should allow tasks to migrate out without security check to make
3024 * sure they will be able to run after migration.
3025 */
3026 if (!is_in_v2_mode() && cpumask_empty(oldcs->effective_cpus))
3027 setsched_check = false;
3028
3029 cgroup_taskset_for_each(task, css, tset) {
3030 ret = task_can_attach(task);
3031 if (ret)
> 3032 goto out_unlock_reset;
3033
3034 if (setsched_check) {
3035 ret = security_task_setscheduler(task);
3036 if (ret)
3037 goto out_unlock_reset;
3038 }
3039
3040 if (dl_task(task)) {
3041 /*
3042 * Count all migrating DL tasks for cpuset task accounting.
3043 * Only tasks that need a root-domain bandwidth move
3044 * contribute to sum_migrate_dl_bw.
3045 */
3046 cs->nr_migrate_dl_tasks++;
3047 if (dl_task_needs_bw_move(task, cs->effective_cpus))
3048 cs->sum_migrate_dl_bw += task->dl.dl_bw;
3049 }
3050 }
3051
3052 if (!cs->sum_migrate_dl_bw)
3053 goto out_success;
3054
3055 cpu = cpumask_any_and(cpu_active_mask, cs->effective_cpus);
3056 if (unlikely(cpu >= nr_cpu_ids)) {
3057 ret = -EINVAL;
3058 goto out_unlock;
3059 }
3060
3061 ret = dl_bw_alloc(cpu, cs->sum_migrate_dl_bw);
3062 if (ret)
3063 goto out_unlock;
3064
3065 cs->dl_bw_cpu = cpu;
3066
3067 out_success:
3068 /*
3069 * Mark attach is in progress. This makes validate_change() fail
3070 * changes which zero cpus/mems_allowed.
3071 */
3072 cs->attach_in_progress++;
3073
3074 out_unlock:
3075 if (ret)
3076 reset_migrate_dl_data(cs);
3077 mutex_unlock(&cpuset_mutex);
3078 return ret;
3079 }
3080
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
reply other threads:[~2026-05-14 0:47 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=202605140212.cspkpyDl-lkp@intel.com \
--to=lkp@intel.com \
--cc=atomlin@atomlin.com \
--cc=llvm@lists.linux.dev \
--cc=oe-kbuild-all@lists.linux.dev \
/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