Re: [PATCH 6.1.y] hrtimers: Force migrate away hrtimers queued after CPUHP_AP_HRTIMERS_DYING

[Greg KH <gregkh@linuxfoundation.org>]

On Tue, May 13, 2025 at 02:04:30PM +0800, Zhaoyang Li wrote:
> From: Frederic Weisbecker <frederic@kernel.org>
> 
> [ Upstream commit 53dac345395c0d2493cbc2f4c85fe38aef5b63f5 ]
> 
> hrtimers are migrated away from the dying CPU to any online target at
> the CPUHP_AP_HRTIMERS_DYING stage in order not to delay bandwidth timers
> handling tasks involved in the CPU hotplug forward progress.
> 
> However wakeups can still be performed by the outgoing CPU after
> CPUHP_AP_HRTIMERS_DYING. Those can result again in bandwidth timers being
> armed. Depending on several considerations (crystal ball power management
> based election, earliest timer already enqueued, timer migration enabled or
> not), the target may eventually be the current CPU even if offline. If that
> happens, the timer is eventually ignored.
> 
> The most notable example is RCU which had to deal with each and every of
> those wake-ups by deferring them to an online CPU, along with related
> workarounds:
> 
> _ e787644caf76 (rcu: Defer RCU kthreads wakeup when CPU is dying)
> _ 9139f93209d1 (rcu/nocb: Fix RT throttling hrtimer armed from offline CPU)
> _ f7345ccc62a4 (rcu/nocb: Fix rcuog wake-up from offline softirq)
> 
> The problem isn't confined to RCU though as the stop machine kthread
> (which runs CPUHP_AP_HRTIMERS_DYING) reports its completion at the end
> of its work through cpu_stop_signal_done() and performs a wake up that
> eventually arms the deadline server timer:
> 
>    WARNING: CPU: 94 PID: 588 at kernel/time/hrtimer.c:1086 hrtimer_start_range_ns+0x289/0x2d0
>    CPU: 94 UID: 0 PID: 588 Comm: migration/94 Not tainted
>    Stopper: multi_cpu_stop+0x0/0x120 <- stop_machine_cpuslocked+0x66/0xc0
>    RIP: 0010:hrtimer_start_range_ns+0x289/0x2d0
>    Call Trace:
>    <TASK>
>      start_dl_timer
>      enqueue_dl_entity
>      dl_server_start
>      enqueue_task_fair
>      enqueue_task
>      ttwu_do_activate
>      try_to_wake_up
>      complete
>      cpu_stopper_thread
> 
> Instead of providing yet another bandaid to work around the situation, fix
> it in the hrtimers infrastructure instead: always migrate away a timer to
> an online target whenever it is enqueued from an offline CPU.
> 
> This will also allow to revert all the above RCU disgraceful hacks.
> 
> Fixes: 5c0930ccaad5 ("hrtimers: Push pending hrtimers away from outgoing CPU earlier")
> Reported-by: Vlad Poenaru <vlad.wing@gmail.com>
> Reported-by: Usama Arif <usamaarif642@gmail.com>
> Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Cc: stable@vger.kernel.org
> Tested-by: Paul E. McKenney <paulmck@kernel.org>
> Link: https://lore.kernel.org/all/20250117232433.24027-1-frederic@kernel.org
> Closes: 20241213203739.1519801-1-usamaarif642@gmail.com
> 
> Signed-off-by: Zhaoyang Li <lizy04@hust.edu.cn>
> ---

You forgot to send a 6.6.y version as well :(

Now dropped from my queue, please resend both.

thanks,

greg k-h