diff options
author | Thomas Gleixner <tglx@linutronix.de> | 2023-11-07 15:57:13 +0100 |
---|---|---|
committer | Thomas Gleixner <tglx@linutronix.de> | 2023-11-11 18:06:42 +0100 |
commit | 5c0930ccaad5a74d74e8b18b648c5eb21ed2fe94 (patch) | |
tree | 005e4da3715f5fa8861ceffcd6216d9b37cfca37 /samples/acrn | |
parent | ffc253263a1375a65fa6c9f62a893e9767fbebfa (diff) | |
download | linux-5c0930ccaad5a74d74e8b18b648c5eb21ed2fe94.tar.gz linux-5c0930ccaad5a74d74e8b18b648c5eb21ed2fe94.tar.bz2 linux-5c0930ccaad5a74d74e8b18b648c5eb21ed2fe94.zip |
hrtimers: Push pending hrtimers away from outgoing CPU earlier
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
Diffstat (limited to 'samples/acrn')
0 files changed, 0 insertions, 0 deletions