Re: [PATCH-next] cgroup/cpuset: Fix incorrect CPU accounting with parent's effective_xcpus expansion

[Waiman Long <longman@redhat.com>]

On 10/29/26 5:42 AM, Guopeng Zhang wrote:
>
> 在 2026/10/28 23:26, Waiman Long 写道:
>> Commit ec0254b9eb49 ("cgroup/cpuset: Release invalid isolated CPUs with
>> a shrunk root partition parent") fixes incorrect isolated_cpus accounting
>> when contraction of a parent's effective_xcpus can cause a child partition
>> to lose isolated CPUs. Expansion of parent's effective_cpus can also allow
>> a child partition to gain more effective_xcpus. However, the current code
>> doesn't handle this case correctly leading to incorrect effective_cpus
>> and isolated_cpus accounting. Fix that by looking for this possible
>> expansion of effective_xcpus and perform the proper accounting action.
>>
>> New test cases are added to test this effective_xcpus expansion scenarios.
>>
>> Reported-by: Guopeng Zhang <guopeng.zhang@linux.dev>
>> Link: https://lore.kernel.org/lkml/20261027123837.100909-1-guopeng.zhang@linux.dev
>> Signed-off-by: Waiman Long <longman@redhat.com>
> I have tested this patch. In the scenarios I tested, the double grant
> and the isolated_cpus accounting after the expansion are now correct.
>
>> ---
>>   kernel/cgroup/cpuset.c                            | 12 ++++++++++++
>>   tools/testing/selftests/cgroup/test_cpuset_prs.sh | 15 +++++++++++++++
>>   2 files changed, 27 insertions(+)
>>
>> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
>> index 3219f927c35e..39c81a0a8ab9 100644
>> --- a/kernel/cgroup/cpuset.c
>> +++ b/kernel/cgroup/cpuset.c
>> @@ -2097,6 +2097,7 @@ static int update_parent_effective_cpumask(struct cpuset *cs, int cmd,
>>   							     parent->effective_xcpus);
>>   			if (!cpumask_empty(tmp->addmask))
>>   				isolated_cpus_release(cs, tmp->addmask);
>> +			/* Expansion of parent's effective_xcpus is handled below */
>>   		}
>>   		if (nocpu) {
>>   			part_error = PERR_NOCPUS;
>> @@ -2106,11 +2107,22 @@ static int update_parent_effective_cpumask(struct cpuset *cs, int cmd,
>>   						     parent->effective_xcpus);
>>   		} else if ((parent_prs == PRS_ISOLATED) &&
>>   			   ((old_prs == PRS_ROOT) || (old_prs == -PRS_ROOT))) {
>> +			/* Parent partition state changed to PRS_ISOLATED */
>>   			part_error = PERR_ISOPARENT;
>>   			if (old_prs == PRS_ROOT) {
>>   				cpumask_copy(tmp->addmask, cs->effective_xcpus);
>>   				adding = true;
>>   			}
>> +		} else if (is_partition_valid(cs) &&
>> +			   !cpumask_equal(tmp->delmask, cs->effective_xcpus)) {
> The branch is also entered when the freshly computed effective xcpus
> shrink, e.g. after a parent contraction. The cpumask_andnot() then
> computes an empty delta and it doesn't seem to cause any harm. Do we
> need to tighten the condition?

I intentionally made it simpler. For the shrink case, deleting will be 
false and nothing will be done.

>
>> +			/*
>> +			 * If there is an expansion of parent's effective_xcpus,
>> +			 * we may take more xcpus from parent. The parent's
>> +			 * effective_cpus should still have active CPUs or nocpu
>> +			 * should have been set.
>> +			 */
>> +			deleting = cpumask_andnot(tmp->delmask, tmp->delmask,
>> +						  cs->effective_xcpus);
>>   		} else if (is_partition_invalid(cs)) {
>>   			struct cgroup_subsys_state *css;
>>   			struct cpuset *child;
>> diff --git a/tools/testing/selftests/cgroup/test_cpuset_prs.sh b/tools/testing/selftests/cgroup/test_cpuset_prs.sh
>> index 83ef6c781af3..844efdf029cd 100755
>> --- a/tools/testing/selftests/cgroup/test_cpuset_prs.sh
>> +++ b/tools/testing/selftests/cgroup/test_cpuset_prs.sh
>> @@ -531,6 +531,21 @@ TEST_MATRIX=(
>>   	" C1-4:P1 C3-4:P2   .      .    T:C4-6   .      .      .     0 A1:5-6|A2:4 A1:P1|A2:P2 4"
>>   	" C1-4:P1 C1-2:P2   .      .    T:C4-6   .      .      .     0 A1:4-6|A2:4-6 A1:P1|A2:P-2 ."
>>   
>> +	# The extra CPUs gained by a child partition when its parent expands the
>> +	# exclusive CPUs have to be taken away from the parent.
>> +	" C2-6:X2-5:P1 CX3-6:P1 \
>> +	                    .      .    X2-6     .      .      .     0 A1:2|A2:3-6|XA2:3-6 A1:P1|A2:P1 ."
>> +	" C2-6:X2-5:P1 CX3-6:P2 \
>> +	                    .      .    X2-6     .      .      .     0 A1:2|A2:3-6|XA2:3-6 A1:P1|A2:P2 3-6"
>> +
>> +	# Both expansion and contraction of parent's effective_xcpus will be
>> +	# correctly handled in child partition and the child can be invalidated
>> +	# if a populated parent could lose all its effective_cpus.
>> +	" C2-6:X2-5:P1 CX3,5-6:P2 \
>> +	                    .      .    X4-6     .      .      .     0 A1:4|A2:5-6|XA2:5-6 A1:P1|A2:P2 5-6"
>> +	" C2-6:X2-5:P1 CX3-6:P2 \
>> +	                    .      .   T:X4-6    .      .      .     0 A1:4-6|A2:4-6 A1:P1|A2:P-2 ."
>> +
>>   	#
>>   	#  old-A1 old-A2 old-A3 old-B1 new-A1 new-A2 new-A3 new-B1 fail ECPUs Pstate ISOLCPUS
>>   	#  ------ ------ ------ ------ ------ ------ ------ ------ ---- ----- ------ --------
> BTW, about the housekeeping check issue from my previous email.
> I verified it with the session below on a nohz_full=8-31 boot where
> CPUs 0-7 are the housekeeping CPUs:
>
>    # cat /sys/devices/system/cpu/nohz_full
>    8-31
>    # cd /sys/fs/cgroup
>    # echo +cpuset > cgroup.subtree_control
>    # mkdir -p A/B
>    # echo 0-7 > A/cpuset.cpus
>    # echo 1-7 > A/cpuset.cpus.exclusive
>    # echo root > A/cpuset.cpus.partition
>    # echo +cpuset > A/cgroup.subtree_control
>    # echo 0-7 > A/B/cpuset.cpus
>    # echo 0-7 > A/B/cpuset.cpus.exclusive
>    # echo isolated > A/B/cpuset.cpus.partition
>    # cat /sys/fs/cgroup/cpuset.cpus.isolated
>    1-7
>    # cat A/B/cpuset.cpus.exclusive.effective
>    1-7
>    # echo 0-7 > A/cpuset.cpus.exclusive
>    # cat A/B/cpuset.cpus.partition
>    isolated
>    # cat /sys/fs/cgroup/cpuset.cpus.isolated
>    0-7
>
> B stays a valid isolated partition holding all the housekeeping CPUs
> and there is no warning at all.
>
> If the housekeeping issue is going to be addressed in this series, is
> a test case like the one below worth adding?
>
> +	# An isolated child partition cannot grow to take over the last
> +	# housekeeping CPU when its parent expands the exclusive CPUs.
> +	" C0-7:X1-7:P1 C0-7:X0-7:P2 .      .      X0-7     .      .      .     0 A1:0-7 A1:P1|A2:P-2 ."
>
>
I will fix that with another patch.

Cheers,
Longman