Re: [PATCH 00/17] cgroup/cpuset: Fix partition CPU ownership and isolation accounting

在 2026/8/21 10:48, Ridong Chen 写道:
> 
> 
> On 8/20/2026 8:41 PM, Guopeng Zhang wrote:
>> From: Guopeng Zhang <[email protected]>
>>
>> update_prstate() uses effective_xcpus for isolation accounting and
>> housekeeping checks when switching a partition between root and
>> isolated. The mask also includes CPUs granted to valid child partitions.
>> Such a type change can alter isolation accounting for child-owned CPUs
>> or fail a housekeeping check because of a CPU the parent does not own.
>>
>> A rejected type change can leave CPUs assigned to the invalidated
>> partition instead of returning them to the partition that owns the
>> invalidated subtree. When cpuset.cpus changes, child validation can use
>> the old parent mask, and a remote update can observe stale cpus_allowed
>> when it revisits a cpuset. Direct and propagated invalidation can leave
>> isolated_cpus reflecting the released partition's type instead of the
>> type of the partition receiving its CPUs. Releasing an isolated
>> partition can clear boot-isolated CPUs from isolated_cpus.
>>
>> Limit type-change checks and accounting to CPUs owned directly by the
>> partition. Preserve boot-isolated CPUs when a partition is released,
>> return CPUs after rejected type changes, validate children against the
>> new parent mask, and publish cpus_allowed before a partition update can
>> revisit the cpuset. Fix isolation accounting during direct and
>> propagated invalidation.
>>
>> Patch 1 removes an invalid selftest comparison that makes
>> test_cpuset_prs.sh fail when boot-time domain isolation is configured.
>> Each kernel fix is followed by a focused selftest update.
>>
>> Guopeng Zhang (17):
>>    selftests/cgroup: Drop invalid boot isolation comparison
>>    cgroup/cpuset: Preserve boot-isolated CPUs on partition release
>>    selftests/cgroup: Test boot-isolated CPU partition release
>>    cgroup/cpuset: Limit type-change accounting to owned CPUs
>>    selftests/cgroup: Test isolated CPU accounting on type changes
>>    cgroup/cpuset: Validate type changes against owned CPUs
>>    selftests/cgroup: Test type-change validation with child-owned CPUs
>>    cgroup/cpuset: Release CPUs when a type change is rejected
>>    selftests/cgroup: Test rejected partition type changes
>>    cgroup/cpuset: Fix isolated accounting on direct child invalidation
>>    selftests/cgroup: Test isolation accounting on direct child
>>      invalidation
>>    cgroup/cpuset: Invalidate children outside the new CPU mask
>>    selftests/cgroup: Test child invalidation after shrinking cpuset.cpus
>>    cgroup/cpuset: Publish cpus_allowed before partition updates
>>    selftests/cgroup: Test shrinking cpuset.cpus in a remote partition
>>    cgroup/cpuset: Fix isolated accounting on propagated invalidation
>>    selftests/cgroup: Test isolation accounting on propagated invalidation
>>
>>   kernel/cgroup/cpuset.c                        | 162 ++++++++++--
>>   .../selftests/cgroup/test_cpuset_prs.sh       | 231 +++++++++++++++++-
>>   2 files changed, 361 insertions(+), 32 deletions(-)
>>
>>
>> base-commit: 6a746cd265aed59107ebdaa9ce039bb832922969
> 
> Hi Guopeng,
> 
> This is a fairly large series, which may make the review process challenging. I would suggest splitting it into smaller, more focused patches. It would also be very helpful if you could provide a reproducer for each bug you are trying to fix, so that we can verify the issue and the fix more effectively.
> 

Hi Ridong,

Thanks for the suggestion. The current series is indeed fairly large, which makes the individual issues harder to review.

I initially kept these patches in one series because some of the later fixes depend on changes introduced by earlier patches. However, while preserving the necessary dependencies, I can group the fixes by issue, split them into several smaller, more focused series, and submit them separately.

I will also add a reproducer to the changelog of each relevant patch, together with the actual behavior before the fix and the expected behavior.

Sashiko has raised a few additional points that I am still reviewing. I will go through those first, and then reorganize and split the series for the next submission.

Thanks,
Guopeng