linux-kernel - Re: [PATCH next] cpuset: fix warning when attaching tasks with offline CPUs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <090bd627-95dc-49ef-a4f6-d78d8f6d6cec@huaweicloud.com>
Date: Mon, 14 Jul 2025 19:30:39 +0800
From: Chen Ridong <chenridong@...weicloud.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: longman@...hat.com, tj@...nel.org, hannes@...xchg.org, mkoutny@...e.com,
 cgroups@...r.kernel.org, linux-kernel@...r.kernel.org, lujialin4@...wei.com,
 chenridong@...wei.com
Subject: Re: [PATCH next] cpuset: fix warning when attaching tasks with
 offline CPUs



On 2025/7/14 16:41, Peter Zijlstra wrote:
> On Mon, Jul 14, 2025 at 03:23:11AM +0000, Chen Ridong wrote:
>> From: Chen Ridong <chenridong@...wei.com>
>>
>> A kernel warning was observed in the cpuset migration path:
>>
>>     WARNING: CPU: 3 PID: 123 at kernel/cgroup/cpuset.c:3130
>>     cgroup_migrate_execute+0x8df/0xf30
>>     Call Trace:
>>      cgroup_transfer_tasks+0x2f3/0x3b0
>>      cpuset_migrate_tasks_workfn+0x146/0x3b0
>>      process_one_work+0x5ba/0xda0
>>      worker_thread+0x788/0x1220
>>
>> The issue can be reliably reproduced with:
>>
>>     # Setup test cpuset
>>     mkdir /sys/fs/cgroup/cpuset/test
>>     echo 2-3 > /sys/fs/cgroup/cpuset/test/cpuset.cpus
>>     echo 0 > /sys/fs/cgroup/cpuset/test/cpuset.mems
>>
>>     # Start test process
>>     sleep 100 &
>>     pid=$!
>>     echo $pid > /sys/fs/cgroup/cpuset/test/cgroup.procs
>>     taskset -p 0xC $pid  # Bind to CPUs 2-3
>>
>>     # Take CPUs offline
>>     echo 0 > /sys/devices/system/cpu/cpu3/online
>>     echo 0 > /sys/devices/system/cpu/cpu2/online
>>
>> Root cause analysis:
>> When tasks are migrated to top_cpuset due to CPUs going offline,
>> cpuset_attach_task() sets the CPU affinity using cpus_attach which
>> is initialized from cpu_possible_mask. This mask may include offline
>> CPUs. When __set_cpus_allowed_ptr() computes the intersection between:
>> 1. cpus_attach (possible CPUs, may include offline)
>> 2. p->user_cpus_ptr (original user-set mask)
>> The resulting new_mask may contain only offline CPUs, causing the
>> operation to fail.
>>
>> The fix changes cpus_attach initialization to use cpu_active_mask
>> instead of cpu_possible_mask, ensuring we only consider online CPUs
>> when setting the new affinity. This prevents the scenario where
>> the intersection would result in an invalid CPU set.
>>
>> Fixes: da019032819a ("sched: Enforce user requested affinity")
>> Reported-by: Yang Lijin <yanglijin@...wei.com>
>> Signed-off-by: Chen Ridong <chenridong@...wei.com>
>> ---
>>  kernel/cgroup/cpuset.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
>> index f74d04429a29..5401adbdffa6 100644
>> --- a/kernel/cgroup/cpuset.c
>> +++ b/kernel/cgroup/cpuset.c
>> @@ -3121,7 +3121,7 @@ static void cpuset_attach_task(struct cpuset *cs, struct task_struct *task)
>>  	if (cs != &top_cpuset)
>>  		guarantee_active_cpus(task, cpus_attach);
>>  	else
>> -		cpumask_andnot(cpus_attach, task_cpu_possible_mask(task),
>> +		cpumask_andnot(cpus_attach, cpu_active_mask,
>>  			       subpartitions_cpus);
> 
> This breaks things. Any task mask must be a subset of
> task_cpu_possible_mask() at all times. It might not be able to run
> outside of that mask.

Hi Peter,

Thanks for your feedback. I'm afraid I don't fully understand what you mean by "breaks things".
Could you please explain in more detail?

To clarify my current understanding: this patch simply changes the cpus_attach initialization from
task_cpu_possible_mask(task) to cpu_active_mask. The intention is that when CPUs are offlined and
tasks get migrated to root cpuset, we shouldn't try to migrate tasks to offline CPUs. And since
cpu_active_mask is a subset of cpu_possible_mask, I thought this would be safe. Did I miss anything?

Best regards
Ridong