Re: [PATCH 06/23] rcu/nocbs: Allow runtime changes in RCU NOCBS cpumask

[sashiko-bot@kernel.org]

Sashiko AI review found 1 potential issue(s):
- [High] Dynamic RCU NOCB update attempts to de-offload online `rcu_nocbs=` CPUs, triggering a WARN_ON_ONCE and leaving isolation state inconsistent.
--

commit a58a92fdc96e43de871fd44a78e4e6da373179d5
Author: Waiman Long <longman@redhat.com>

rcu/nocbs: Allow runtime changes in RCU NOCBS cpumask

This commit enables dynamic runtime updates to the RCU NO-CB CPU offloading
state when isolated CPUs are added or removed. It introduces a new helper,
rcu_nocb_update_cpus(), which is called directly from housekeeping_update()
to synchronize the offloaded CPUs with the HK_TYPE_KERNEL_NOISE cpumask.

> diff --git a/kernel/rcu/tree_nocb.h b/kernel/rcu/tree_nocb.h
> index 2d06dcb61f379..b2daba1e5cb98 100644
> --- a/kernel/rcu/tree_nocb.h
> +++ b/kernel/rcu/tree_nocb.h
[ ... ]
> +void rcu_nocb_update_cpus(struct cpumask *cpumask)
> +{
> +	int cpu, ret;
> +
> +	if (!rcu_state.nocb_is_setup) {
> +		pr_warn_once("Dynamic RCU NOCB cannot be enabled without nohz_full/rcu_nocbs kernel boot parameter!\n");
> +		return;
> +	}
> +
> +	for_each_cpu_andnot(cpu, cpumask, rcu_nocb_mask) {
> +		ret = rcu_nocb_cpu_offload(cpu);
> +		if (WARN_ON_ONCE(ret))
> +			return;
> +	}
> +
> +	for_each_cpu_andnot(cpu, rcu_nocb_mask, cpumask) {
> +		ret = rcu_nocb_cpu_deoffload(cpu);

What happens here if a system booted with explicit rcu_nocbs= CPUs, and
later a user dynamically updates an isolated cpuset?

It looks like this loop assumes the active rcu_nocb_mask should identically
match the new isol_mask. If the boot-time rcu_nocbs= CPUs are not included
in the new isolation mask, this loop will attempt to de-offload them.

Because the cpuset subsystem is unaware of the independent rcu_nocbs= mask,
wouldn't those original CPUs likely remain online?

> +		if (WARN_ON_ONCE(ret))
> +			return;

If rcu_nocb_cpu_deoffload() is called on an online CPU, it returns -EINVAL.
Could this unconditionally trigger this WARN_ON_ONCE and abort the rest of
the update loop?

If the loop aborts early, since housekeeping_update() already committed the
new mask to housekeeping.cpumasks[], does this leave the system in a
desynchronized state where the scheduler assumes CPUs are isolated but
RCU callback offloading is not properly updated?

> +	}
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260421030351.281436-1-longman@redhat.com?part=6