在 2026/10/11 06:19, Waiman Long 写道:
> When prstate_housekeeping_conflict() is called to perform housekeeping
> check with cpumask changes, the exclusive CPUs owned by child partitions
> are excluded. If the current cpuset is an isolated partition with root
> partition children. It is possible the cpumask change will still leave
> active housekeeping CPUs but then no housekeeping CPUs will be left when
> the child partitions are disabled or invalidated.
>
> To protect against this possibility, all the exclusive CPUs of the
> cpuset should be considered to be owned by the current cpuset when doing
> housekeeping check. Do that by calling prstate_housekeeping_conflict()
> in partition_cpus_change() and passing in the add_cpus and del_cpus
> parameters as if the cpuset owns all the exclusive CPUs.
>
> With this change, the prstate_housekeeping_conflict() call in
> update_parent_effective_cpumask() with partcmd_update and newmask
> is now duplicative and can be removed. The housekeeping check in
> remote_cpus_update(), however, will still be useful as this function can
> be called directly from update_cpumasks_hier() without going through
> partition_cpus_change(). The update_parent_effective_cpumask() call
> from update_cpumasks_hier() is partcmd_update with no cpumask which
> still have the housekeeping check and so is covered.
>
> In the case of partition state switch from isolated to root and vice
> versa, the set of exclusive CPUs are recomputed to include those
> transferred to child paritions as well.
>
> Fixes: 4a74e418881f ("cgroup/cpuset: Check partition conflict with
> housekeeping setup")
> Signed-off-by: Waiman Long <[email protected]>
> ---
> kernel/cgroup/cpuset.c | 26 +++++++++++++++++---------
> 1 file changed, 17 insertions(+), 9 deletions(-)
>
> diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c
> index f3cebb277a68..1c0441fa3bea 100644
> --- a/kernel/cgroup/cpuset.c
> +++ b/kernel/cgroup/cpuset.c
> @@ -1907,14 +1907,6 @@ static int update_parent_effective_cpumask(struct
> cpuset *cs, int cmd,
> parent->effective_xcpus);
> }
>
> - /*
> - * Check for housekeeping conflicts
> - */
> - if (is_partition_valid(cs) &&
> - prstate_housekeeping_conflict(old_prs, parent_prs,
> - tmp->delmask, tmp->addmask))
> - part_error = PERR_HKEEPING;
> -
> /*
> * The new CPUs to be removed from parent's effective CPUs
> * must be present.
> @@ -2398,6 +2390,21 @@ static void partition_cpus_change(struct cpuset *cs,
> struct cpuset *trialcs,
> return;
>
> prs_err = validate_partition(cs, trialcs);
> + if (!prs_err) {
> + int parent_prs = is_remote_partition(cs)
> + ? PRS_ROOT : parent_cs(cs)->partition_root_state;
> + /*
> + * Check for housekeeping CPUs conflict assuming that all the
> + * exclusive CPUs belong to the current cpuset.
> + */
> + compute_excpus(trialcs, tmp->new_cpus);
> + cpumask_andnot(tmp->addmask, tmp->new_cpus,
> cs->effective_xcpus);
> + cpumask_andnot(tmp->delmask, cs->effective_xcpus,
> tmp->new_cpus);
I ran a few local tests on v2 and still found the following gaps in the
housekeeping checks.
With CPUs 0-15 online and nohz_full=2-15:
# cd /sys/fs/cgroup
# echo +cpuset > cgroup.subtree_control
# mkdir A
# echo 1 > A/cpuset.cpus
# echo isolated > A/cpuset.cpus.partition
# echo 0-1 > A/cpuset.cpus
# cat A/cpuset.cpus.partition
isolated
# cat A/cpuset.cpus.exclusive.effective
0-1
# cat cpuset.cpus.isolated
0-1
The check computes delmask={1}, although CPU 1 is still isolated after the
update. That lets it isolate CPU 0, the last remaining housekeeping CPU.
On a fresh boot with the same nohz_full setting:
# cd /sys/fs/cgroup
# echo +cpuset > cgroup.subtree_control
# mkdir A B
# echo 1 > A/cpuset.cpus
# echo 1 > A/cpuset.cpus.exclusive
# echo isolated > A/cpuset.cpus.partition
# echo +cpuset > A/cgroup.subtree_control
# mkdir A/C
# echo 1 > A/C/cpuset.cpus
# echo root > A/C/cpuset.cpus.partition
# echo 0 > B/cpuset.cpus
# echo isolated > B/cpuset.cpus.partition
# echo 1-2 > A/cpuset.cpus
# echo 1-2 > A/cpuset.cpus.exclusive
# cat cpuset.cpus.isolated
0,2
# echo member > A/C/cpuset.cpus.partition
# cat A/cpuset.cpus.partition
isolated
# cat cpuset.cpus.isolated
0-2
CPU 1 is present in both masks and cancels out of addmask while the root
child owns it. With nohz_full=2-15 and B isolating CPU 0, CPU 1 was the last
remaining housekeeping CPU; disabling the child leaves none.
This also reproduces before the series, so it is an existing issue.
> + if (prstate_housekeeping_conflict(cs->partition_root_state,
> + parent_prs, tmp->addmask,
> + tmp->delmask))
> + prs_err = PERR_HKEEPING;
> + }
An invalid root with an explicit exclusive mask can retain effective_xcpus
without owning those CPUs. Subtracting this mask skips checking them when
the partition becomes valid again.
With CPUs 0-15 online and isolcpus=domain,10-11, on a fresh boot:
# cd /sys/fs/cgroup
# echo +cpuset > cgroup.subtree_control
# mkdir A
# echo 10 > A/cpuset.cpus
# echo 10 > A/cpuset.cpus.exclusive
# echo root > A/cpuset.cpus.partition
# cat A/cpuset.cpus.partition
root invalid (partition config conflicts with housekeeping setup)
# cat A/cpuset.cpus.exclusive.effective
10
# echo 10,12 > A/cpuset.cpus
# cat A/cpuset.cpus.partition
root
# cat A/cpuset.cpus.effective
10
# cat cpuset.cpus.effective
0-9,11-15
addmask is empty here, so boot-isolated CPU 10 is allocated to the now-valid
root without being checked.
Should an invalid partition be checked against the full mask it will
acquire, rather than these deltas?
Thanks,
Guopeng
> if (prs_err) {
> WRITE_ONCE(cs->prs_err, prs_err);
> trialcs->prs_err = prs_err;
> @@ -2897,8 +2904,9 @@ static int update_prstate(struct cpuset *cs, int
> new_prs)
> * A change in load balance state only, no change in cpumasks.
> * Need to update isolated_cpus.
> */
> + compute_excpus(cs, tmpmask.new_cpus);
> if (prstate_housekeeping_conflict(new_prs, parent_prs,
> - cs->effective_xcpus, NULL))
> + tmpmask.new_cpus, NULL))
> err = PERR_HKEEPING;
> else
> isolcpus_updated = true;
