hrtimers: Push pending hrtimers away from outgoing CPU earlier
authorThomas Gleixner <tglx@linutronix.de>
Tue, 7 Nov 2023 14:57:13 +0000 (15:57 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 13 Dec 2023 17:44:56 +0000 (18:44 +0100)
commit53f408cad05bb987af860af22f4151e5a18e6ee8
treeda3932fa69192a9b9fab35f368b74aa8bf0cfaef
parentc94c44685d801334b64bd7623bc7db0917304dd9
hrtimers: Push pending hrtimers away from outgoing CPU earlier

[ Upstream commit 5c0930ccaad5a74d74e8b18b648c5eb21ed2fe94 ]

2b8272ff4a70 ("cpu/hotplug: Prevent self deadlock on CPU hot-unplug")
solved the straight forward CPU hotplug deadlock vs. the scheduler
bandwidth timer. Yu discovered a more involved variant where a task which
has a bandwidth timer started on the outgoing CPU holds a lock and then
gets throttled. If the lock required by one of the CPU hotplug callbacks
the hotplug operation deadlocks because the unthrottling timer event is not
handled on the dying CPU and can only be recovered once the control CPU
reaches the hotplug state which pulls the pending hrtimers from the dead
CPU.

Solve this by pushing the hrtimers away from the dying CPU in the dying
callbacks. Nothing can queue a hrtimer on the dying CPU at that point because
all other CPUs spin in stop_machine() with interrupts disabled and once the
operation is finished the CPU is marked offline.

Reported-by: Yu Liao <liaoyu15@huawei.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Liu Tie <liutie4@huawei.com>
Link: https://lore.kernel.org/r/87a5rphara.ffs@tglx
Signed-off-by: Sasha Levin <sashal@kernel.org>
include/linux/cpuhotplug.h
include/linux/hrtimer.h
kernel/cpu.c
kernel/time/hrtimer.c