On 05/11/25 18:46, Frederic Weisbecker wrote: > Le Wed, Nov 05, 2025 at 05:24:29PM +0100, Valentin Schneider a écrit : >> On 29/10/25 18:15, Frederic Weisbecker wrote: >> > Le Wed, Oct 29, 2025 at 11:32:58AM +0100, Valentin Schneider a écrit : >> >> I need to have a think about that one; one pain point I see is the context >> >> tracking work has to be NMI safe since e.g. an NMI can take us out of >> >> userspace. Another is that NOHZ-full CPUs need to be special cased in the >> >> stop machine queueing / completion. >> >> >> >> /me goes fetch a new notebook >> > >> > Something like the below (untested) ? >> > >> >> Some minor nits below but otherwise that looks promising. >> >> One problem I'm having however is reasoning about the danger zone; what >> forbidden actions could a NO_HZ_FULL CPU take when entering the kernel >> while take_cpu_down() is happening? >> >> I'm actually not familiar with why we actually use stop_machine() for CPU >> hotplug; I see things like CPUHP_AP_SMPCFD_DYING::smpcfd_dying_cpu() or >> CPUHP_AP_TICK_DYING::tick_cpu_dying() expect other CPUs to be patiently >> spinning in multi_cpu_stop(), and I *think* nothing in the entry code up to >> context_tracking entry would disrupt that, but it's not a small thing to >> reason about. >> >> AFAICT we need to reason about every .teardown callback from >> CPUHP_TEARDOWN_CPU to CPUHP_AP_OFFLINE and their explicit & implicit >> dependencies on other CPUs being STOP'd. > > You're raising a very interesting question. The initial point of > stop_machine() > is to synchronize this: > > set_cpu_online(cpu, 0) > migrate timers; > migrate hrtimers; > flush IPIs; > etc... > > against this pattern: > > preempt_disable() > if (cpu_online(cpu)) > queue something; // could be timer, IPI, etc... > preempt_enable() > > There have been attempts: > > > https://lore.kernel.org/all/[email protected]/ > > And really it should be fine to just do: > > set_cpu_online(cpu, 0) > synchronize_rcu() > migrate / flush stuff >
That's what I was thinking as well, at the very least for the cpu_online_mask bit. > Probably we should try that instead of the busy loop I proposed > which only papers over the problem. > > Of course there are other assumptions. For example the tick > timekeeper is migrated easily knowing that all online CPUs are > not idle (cf: tick_cpu_dying()). So I expect a few traps, with RCU > for example and indeed all these hotplug callbacks must be audited > one by one. > > I'm not entirely unfamiliar with many of them. Let me see what I can do... > Here be dragons :-)
