[PATCH 0/2] cgroup/cpuset: Fix partition updates using stale CPU masks

[PATCH 0/2] cgroup/cpuset: Fix partition updates using stale CPU masks

[Guopeng Zhang]

From: Guopeng Zhang <zhangguopeng@kylinos.cn>

These patches fix two cases where partition updates read stale configured
CPU masks:

1. Shrinking cpuset.cpus of a remote partition can leave a removed CPU
   unavailable to the top cpuset.
2. Updating cpuset.cpus.exclusive can leave an invalid local partition
   unable to recover after the mask becomes valid.

Move each configured mask update before partition_cpus_change().

Guopeng Zhang (2):
  cgroup/cpuset: Fix cpuset.cpus update in a remote partition
  cgroup/cpuset: Fix invalid local partition recovery

 kernel/cgroup/cpuset.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

-- 
2.43.0

[PATCH 1/2] cgroup/cpuset: Fix cpuset.cpus update in a remote partition

[Guopeng Zhang]

From: Guopeng Zhang <zhangguopeng@kylinos.cn>

When the CPU list of a remote partition is reduced, a removed CPU may
remain unavailable to the top cpuset.

This can be reproduced on a cgroup v2 system with CPUs 0-7 online:

    cd /sys/fs/cgroup
    echo +cpuset > cgroup.subtree_control
    mkdir A
    echo 1-7 > A/cpuset.cpus
    echo 1-7 > A/cpuset.cpus.exclusive
    echo +cpuset > A/cgroup.subtree_control
    mkdir A/B
    echo 1-4 > A/B/cpuset.cpus
    echo root > A/B/cpuset.cpus.partition
    echo 1-3 > A/B/cpuset.cpus
    cat cpuset.cpus.effective

The last command should show 0,4-7, but CPU 4 is missing.

update_cpumask() calls partition_cpus_change() while cs->cpus_allowed
still contains the old mask. remote_cpus_update() first releases CPU 4,
but the hierarchy update revisits B and compute_excpus() still sees the
old mask, so CPU 4 is removed from the top cpuset again.

Move the cpus_allowed update before partition_cpus_change() so that
the hierarchy update sees the new mask when it revisits the cpuset.

Fixes: f62a5d39368e ("cgroup/cpuset: Remove remote_partition_check() & make update_cpumasks_hier() handle remote partition")
Signed-off-by: Guopeng Zhang <zhangguopeng@kylinos.cn>
---
 kernel/cgroup/cpuset.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
index 0ebba2d646c3..de7553459adc 100644
--- a/kernel/cgroup/cpuset.c
+++ b/kernel/cgroup/cpuset.c
@@ -2478,10 +2478,13 @@ static int update_cpumask(struct cpuset *cs, struct cpuset *trialcs,
 	 */
 	force = !cpumask_equal(cs->effective_xcpus, trialcs->effective_xcpus);
 
+	spin_lock_irq(&callback_lock);
+	cpumask_copy(cs->cpus_allowed, trialcs->cpus_allowed);
+	spin_unlock_irq(&callback_lock);
+
 	partition_cpus_change(cs, trialcs, &tmp);
 
 	spin_lock_irq(&callback_lock);
-	cpumask_copy(cs->cpus_allowed, trialcs->cpus_allowed);
 	cpumask_copy(cs->effective_xcpus, trialcs->effective_xcpus);
 	if ((old_prs > 0) && !is_partition_valid(cs))
 		reset_partition_data(cs);
-- 
2.43.0

[PATCH 2/2] cgroup/cpuset: Fix invalid local partition recovery

[Guopeng Zhang]

From: Guopeng Zhang <zhangguopeng@kylinos.cn>

An invalid local partition may fail to recover after its exclusive CPU
list is changed to a valid one.

This can be reproduced on a cgroup v2 system with CPUs 0-7 online:

    cd /sys/fs/cgroup
    echo +cpuset > cgroup.subtree_control
    mkdir A
    echo 0-7 > A/cpuset.cpus
    echo 0-7 > A/cpuset.cpus.exclusive
    echo root > A/cpuset.cpus.partition
    cat A/cpuset.cpus.partition
    echo 1 > A/cpuset.cpus.exclusive
    cat A/cpuset.cpus.partition

The first read reports root invalid because all CPUs were requested.
After the mask is changed to CPU 1, the partition should become valid,
but it remains invalid with PERR_NOCPUS.

update_exclusive_cpumask() calls partition_cpus_change() before updating
cs->exclusive_cpus. update_parent_effective_cpumask() then gets the
old 0-7 mask from user_xcpus() and sets PERR_NOCPUS even though the new
mask leaves CPUs for the parent.

Move the exclusive_cpus update before partition_cpus_change() so that
the partition update sees the new mask.

Fixes: 46c521bac592 ("cgroup/cpuset: Enable invalid to valid local partition transition")
Signed-off-by: Guopeng Zhang <zhangguopeng@kylinos.cn>
---
 kernel/cgroup/cpuset.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
index de7553459adc..e96bc66ffa07 100644
--- a/kernel/cgroup/cpuset.c
+++ b/kernel/cgroup/cpuset.c
@@ -2546,10 +2546,14 @@ static int update_exclusive_cpumask(struct cpuset *cs, struct cpuset *trialcs,
 		return -ENOMEM;
 
 	trialcs->prs_err = PERR_NONE;
-	partition_cpus_change(cs, trialcs, &tmp);
 
 	spin_lock_irq(&callback_lock);
 	cpumask_copy(cs->exclusive_cpus, trialcs->exclusive_cpus);
+	spin_unlock_irq(&callback_lock);
+
+	partition_cpus_change(cs, trialcs, &tmp);
+
+	spin_lock_irq(&callback_lock);
 	cpumask_copy(cs->effective_xcpus, trialcs->effective_xcpus);
 	if ((old_prs > 0) && !is_partition_valid(cs))
 		reset_partition_data(cs);
-- 
2.43.0

Re: [PATCH 0/2] cgroup/cpuset: Fix partition updates using stale CPU masks

[Guopeng Zhang]

Hello,Longman

Could you take a look at this patch series when you have a chance?

Thanks,
Guopeng

在 2026/10/10 15:59, Guopeng Zhang 写道:
> From: Guopeng Zhang <zhangguopeng@kylinos.cn>
> 
> These patches fix two cases where partition updates read stale configured
> CPU masks:
> 
> 1. Shrinking cpuset.cpus of a remote partition can leave a removed CPU
>    unavailable to the top cpuset.
> 2. Updating cpuset.cpus.exclusive can leave an invalid local partition
>    unable to recover after the mask becomes valid.
> 
> Move each configured mask update before partition_cpus_change().
> 
> Guopeng Zhang (2):
>   cgroup/cpuset: Fix cpuset.cpus update in a remote partition
>   cgroup/cpuset: Fix invalid local partition recovery
> 
>  kernel/cgroup/cpuset.c | 11 +++++++++--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 

Re: [PATCH 1/2] cgroup/cpuset: Fix cpuset.cpus update in a remote partition

[Waiman Long]

On 10/10/26 3:59 AM, Guopeng Zhang wrote:
> From: Guopeng Zhang <zhangguopeng@kylinos.cn>
>
> When the CPU list of a remote partition is reduced, a removed CPU may
> remain unavailable to the top cpuset.
>
> This can be reproduced on a cgroup v2 system with CPUs 0-7 online:
>
>      cd /sys/fs/cgroup
>      echo +cpuset > cgroup.subtree_control
>      mkdir A
>      echo 1-7 > A/cpuset.cpus
>      echo 1-7 > A/cpuset.cpus.exclusive
>      echo +cpuset > A/cgroup.subtree_control
>      mkdir A/B
>      echo 1-4 > A/B/cpuset.cpus
>      echo root > A/B/cpuset.cpus.partition
>      echo 1-3 > A/B/cpuset.cpus
>      cat cpuset.cpus.effective
>
> The last command should show 0,4-7, but CPU 4 is missing.
>
> update_cpumask() calls partition_cpus_change() while cs->cpus_allowed
> still contains the old mask. remote_cpus_update() first releases CPU 4,
> but the hierarchy update revisits B and compute_excpus() still sees the
> old mask, so CPU 4 is removed from the top cpuset again.
>
> Move the cpus_allowed update before partition_cpus_change() so that
> the hierarchy update sees the new mask when it revisits the cpuset.
>
> Fixes: f62a5d39368e ("cgroup/cpuset: Remove remote_partition_check() & make update_cpumasks_hier() handle remote partition")
> Signed-off-by: Guopeng Zhang <zhangguopeng@kylinos.cn>
> ---
>   kernel/cgroup/cpuset.c | 5 ++++-
>   1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
> index 0ebba2d646c3..de7553459adc 100644
> --- a/kernel/cgroup/cpuset.c
> +++ b/kernel/cgroup/cpuset.c
> @@ -2478,10 +2478,13 @@ static int update_cpumask(struct cpuset *cs, struct cpuset *trialcs,
>   	 */
>   	force = !cpumask_equal(cs->effective_xcpus, trialcs->effective_xcpus);
>   
> +	spin_lock_irq(&callback_lock);
> +	cpumask_copy(cs->cpus_allowed, trialcs->cpus_allowed);
> +	spin_unlock_irq(&callback_lock);
> +
>   	partition_cpus_change(cs, trialcs, &tmp);
>   
>   	spin_lock_irq(&callback_lock);
> -	cpumask_copy(cs->cpus_allowed, trialcs->cpus_allowed);
>   	cpumask_copy(cs->effective_xcpus, trialcs->effective_xcpus);
>   	if ((old_prs > 0) && !is_partition_valid(cs))
>   		reset_partition_data(cs);

Sorry for the late reply.

Thanks for reporting this problem. I suspect similar problem may exist 
with change to cpuset.cpus.exclusive as well. The root cause of this 
problem is the recursive call to remote_cpus_update() with the second 
call missing information leading to the revert of the first call. I have 
posted another patch to address this recursive call problem. Please take 
a look to see if you agree with that or not.

Thanks,
Longman

Re: [PATCH 2/2] cgroup/cpuset: Fix invalid local partition recovery

[Waiman Long]

On 10/10/26 3:59 AM, Guopeng Zhang wrote:
> From: Guopeng Zhang <zhangguopeng@kylinos.cn>
>
> An invalid local partition may fail to recover after its exclusive CPU
> list is changed to a valid one.
>
> This can be reproduced on a cgroup v2 system with CPUs 0-7 online:
>
>      cd /sys/fs/cgroup
>      echo +cpuset > cgroup.subtree_control
>      mkdir A
>      echo 0-7 > A/cpuset.cpus
>      echo 0-7 > A/cpuset.cpus.exclusive
>      echo root > A/cpuset.cpus.partition
>      cat A/cpuset.cpus.partition
>      echo 1 > A/cpuset.cpus.exclusive
>      cat A/cpuset.cpus.partition
>
> The first read reports root invalid because all CPUs were requested.
> After the mask is changed to CPU 1, the partition should become valid,
> but it remains invalid with PERR_NOCPUS.
>
> update_exclusive_cpumask() calls partition_cpus_change() before updating
> cs->exclusive_cpus. update_parent_effective_cpumask() then gets the
> old 0-7 mask from user_xcpus() and sets PERR_NOCPUS even though the new
> mask leaves CPUs for the parent.
>
> Move the exclusive_cpus update before partition_cpus_change() so that
> the partition update sees the new mask.
>
> Fixes: 46c521bac592 ("cgroup/cpuset: Enable invalid to valid local partition transition")
> Signed-off-by: Guopeng Zhang <zhangguopeng@kylinos.cn>
> ---
>   kernel/cgroup/cpuset.c | 6 +++++-
>   1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
> index de7553459adc..e96bc66ffa07 100644
> --- a/kernel/cgroup/cpuset.c
> +++ b/kernel/cgroup/cpuset.c
> @@ -2546,10 +2546,14 @@ static int update_exclusive_cpumask(struct cpuset *cs, struct cpuset *trialcs,
>   		return -ENOMEM;
>   
>   	trialcs->prs_err = PERR_NONE;
> -	partition_cpus_change(cs, trialcs, &tmp);
>   
>   	spin_lock_irq(&callback_lock);
>   	cpumask_copy(cs->exclusive_cpus, trialcs->exclusive_cpus);
> +	spin_unlock_irq(&callback_lock);
> +
> +	partition_cpus_change(cs, trialcs, &tmp);
> +
> +	spin_lock_irq(&callback_lock);
>   	cpumask_copy(cs->effective_xcpus, trialcs->effective_xcpus);
>   	if ((old_prs > 0) && !is_partition_valid(cs))
>   		reset_partition_data(cs);

With the patch series that I have just sent out, I can't reproduce this 
problem. My patch 2 of the series change 
update_parent_effective_cpumask() to not use user_xcpus() anymore. So 
that should fix the problem.

Cheers, Longman

Re: [PATCH 1/2] cgroup/cpuset: Fix cpuset.cpus update in a remote partition

[Guopeng Zhang]

在 2026/10/22 11:23, Waiman Long 写道:
> On 10/10/26 3:59 AM, Guopeng Zhang wrote:
>> From: Guopeng Zhang <zhangguopeng@kylinos.cn>
>>
>> When the CPU list of a remote partition is reduced, a removed CPU may
>> remain unavailable to the top cpuset.
>>
>> This can be reproduced on a cgroup v2 system with CPUs 0-7 online:
>>
>>      cd /sys/fs/cgroup
>>      echo +cpuset > cgroup.subtree_control
>>      mkdir A
>>      echo 1-7 > A/cpuset.cpus
>>      echo 1-7 > A/cpuset.cpus.exclusive
>>      echo +cpuset > A/cgroup.subtree_control
>>      mkdir A/B
>>      echo 1-4 > A/B/cpuset.cpus
>>      echo root > A/B/cpuset.cpus.partition
>>      echo 1-3 > A/B/cpuset.cpus
>>      cat cpuset.cpus.effective
>>
>> The last command should show 0,4-7, but CPU 4 is missing.
>>
>> update_cpumask() calls partition_cpus_change() while cs->cpus_allowed
>> still contains the old mask. remote_cpus_update() first releases CPU 4,
>> but the hierarchy update revisits B and compute_excpus() still sees the
>> old mask, so CPU 4 is removed from the top cpuset again.
>>
>> Move the cpus_allowed update before partition_cpus_change() so that
>> the hierarchy update sees the new mask when it revisits the cpuset.
>>
>> Fixes: f62a5d39368e ("cgroup/cpuset: Remove remote_partition_check() & make update_cpumasks_hier() handle remote partition")
>> Signed-off-by: Guopeng Zhang <zhangguopeng@kylinos.cn>
>> ---
>>   kernel/cgroup/cpuset.c | 5 ++++-
>>   1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
>> index 0ebba2d646c3..de7553459adc 100644
>> --- a/kernel/cgroup/cpuset.c
>> +++ b/kernel/cgroup/cpuset.c
>> @@ -2478,10 +2478,13 @@ static int update_cpumask(struct cpuset *cs, struct cpuset *trialcs,
>>        */
>>       force = !cpumask_equal(cs->effective_xcpus, trialcs->effective_xcpus);
>>   +    spin_lock_irq(&callback_lock);
>> +    cpumask_copy(cs->cpus_allowed, trialcs->cpus_allowed);
>> +    spin_unlock_irq(&callback_lock);
>> +
>>       partition_cpus_change(cs, trialcs, &tmp);
>>         spin_lock_irq(&callback_lock);
>> -    cpumask_copy(cs->cpus_allowed, trialcs->cpus_allowed);
>>       cpumask_copy(cs->effective_xcpus, trialcs->effective_xcpus);
>>       if ((old_prs > 0) && !is_partition_valid(cs))
>>           reset_partition_data(cs);
> 
> Sorry for the late reply.
> 
> Thanks for reporting this problem. I suspect similar problem may exist with change to cpuset.cpus.exclusive as well. The root cause of this problem is the recursive call to remote_cpus_update() with the second call missing information leading to the revert of the first call. I have posted another patch to address this recursive call problem. Please take a look to see if you agree with that or not.
> 
Thanks for the explanation and for looking further into the root cause.

I'll take a look at your patch and run some local tests once I've taken care of some urgent work.

Thanks,
Guopeng

Re: [PATCH 2/2] cgroup/cpuset: Fix invalid local partition recovery

[Guopeng Zhang]

在 2026/10/22 11:28, Waiman Long 写道:
> On 10/10/26 3:59 AM, Guopeng Zhang wrote:
>> From: Guopeng Zhang <zhangguopeng@kylinos.cn>
>>
>> An invalid local partition may fail to recover after its exclusive CPU
>> list is changed to a valid one.
>>
>> This can be reproduced on a cgroup v2 system with CPUs 0-7 online:
>>
>>      cd /sys/fs/cgroup
>>      echo +cpuset > cgroup.subtree_control
>>      mkdir A
>>      echo 0-7 > A/cpuset.cpus
>>      echo 0-7 > A/cpuset.cpus.exclusive
>>      echo root > A/cpuset.cpus.partition
>>      cat A/cpuset.cpus.partition
>>      echo 1 > A/cpuset.cpus.exclusive
>>      cat A/cpuset.cpus.partition
>>
>> The first read reports root invalid because all CPUs were requested.
>> After the mask is changed to CPU 1, the partition should become valid,
>> but it remains invalid with PERR_NOCPUS.
>>
>> update_exclusive_cpumask() calls partition_cpus_change() before updating
>> cs->exclusive_cpus. update_parent_effective_cpumask() then gets the
>> old 0-7 mask from user_xcpus() and sets PERR_NOCPUS even though the new
>> mask leaves CPUs for the parent.
>>
>> Move the exclusive_cpus update before partition_cpus_change() so that
>> the partition update sees the new mask.
>>
>> Fixes: 46c521bac592 ("cgroup/cpuset: Enable invalid to valid local partition transition")
>> Signed-off-by: Guopeng Zhang <zhangguopeng@kylinos.cn>
>> ---
>>   kernel/cgroup/cpuset.c | 6 +++++-
>>   1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
>> index de7553459adc..e96bc66ffa07 100644
>> --- a/kernel/cgroup/cpuset.c
>> +++ b/kernel/cgroup/cpuset.c
>> @@ -2546,10 +2546,14 @@ static int update_exclusive_cpumask(struct cpuset *cs, struct cpuset *trialcs,
>>           return -ENOMEM;
>>         trialcs->prs_err = PERR_NONE;
>> -    partition_cpus_change(cs, trialcs, &tmp);
>>         spin_lock_irq(&callback_lock);
>>       cpumask_copy(cs->exclusive_cpus, trialcs->exclusive_cpus);
>> +    spin_unlock_irq(&callback_lock);
>> +
>> +    partition_cpus_change(cs, trialcs, &tmp);
>> +
>> +    spin_lock_irq(&callback_lock);
>>       cpumask_copy(cs->effective_xcpus, trialcs->effective_xcpus);
>>       if ((old_prs > 0) && !is_partition_valid(cs))
>>           reset_partition_data(cs);
> 
> With the patch series that I have just sent out, I can't reproduce this problem. My patch 2 of the series change update_parent_effective_cpumask() to not use user_xcpus() anymore. So that should fix the problem.
> 

Thanks for checking this issue. I'll also test some other scenarios
with your new patch series applied.

Thanks,
Guopeng