On 3/3/26 5:48 PM, Frederic Weisbecker wrote:
Le Tue, Mar 03, 2026 at 11:00:54AM -0500, Waiman Long a écrit :
On 2/26/26 11:06 AM, Frederic Weisbecker wrote:
If you look at the work function, it will make a copy of HK_TYPE_DOMAIN
cpumask while holding rcu_read_lock().
Where?
So the current hotplug operation must
have finished at that point.
I'm confused. This is called from sched_cpu_deactivate(), right?
So the work is scheduled at that point. But the work does cpuset_full_lock()
which includes cpu hotplug read lock, so the sched domain rebuild can only
happen at the end of cpu_down().
This means that between CPUHP_TEARDOWN_CPU and CPUHP_OFFLINE, the offline
CPU still appears in the scheduler topology because the scheduler domains
haven't been rebuilt.
And even if the work wouldn't cpu hotplug read lock, what guarantees that
it executes before reaching CPUHP_TEARDOWN_CPU?
Of course, if there is another hot-add/remove
operation right after the rcu_read_lock is released, the cpumask passed down
to housekeeping_update() may not be the latest one. In this case, another
work will be scheduled to call housekeeping_update() with the new cpumask
again.
I'm not so much worried about housekeeping_update() (yet). I'm worried about
topology rebuild to happen before CPUHP_TEARDOWN_CPU. Offline CPUs shouldn't
exist in the topology.
Yes, I am aware that this could be a problem. I am working on a fix
patch that will always do a rebuild_sched_domains_cpuslocked() call
directly in the hotplug path if needed as shown in the patch that I sent
to Jon. I want to get a confirmation first before I send it out. There
will be other minor code/comment adjustments as well.
Cheers,
Longman
