* [Bug report] A variant deadlock issue of CPU hot-unplug operation vs. the CFS bandwidth timer
@ 2023-11-07 13:26 Yu Liao
2023-11-07 14:57 ` Thomas Gleixner
0 siblings, 1 reply; 4+ messages in thread
From: Yu Liao @ 2023-11-07 13:26 UTC (permalink / raw)
To: Thomas Gleixner, Vincent Guittot, Ingo Molnar
Cc: linux-kernel@vger.kernel.org, liwei (GF), xiafukun, liutie4,
Peter Zijlstra, Dietmar Eggemann, Phil Auld, vschneid, vdonnefort,
Xiongfeng Wang
The patch [1] from tglx solved the deadlock issue reported by Xiongfeng [2],
but recently we discovered a variant of the deadlock issue.
[1] https://lore.kernel.org/all/87h6oqdq0i.ffs@tglx/
[2] https://lore.kernel.org/all/8e785777-03aa-99e1-d20e-e956f5685be6@huawei.com/
(The following description is partially borrowed from the commit log of tglx)
CPU1 CPU2 CPU3
T1 sets cfs_quota
starts hrtimer cfs_bandwidth 'period_timer'
T1 is migrated to CPU3
T2(worker thread) initiates
offlining of CPU1
Hotplug operation starts
...
'period_timer' expires and is
re-enqueued on CPU1
...
take_cpu_down()
CPU1 shuts down and does not handle timers
anymore. They have to be migrated in the
post dead hotplug steps by the control task.
T2(worker thread) runs the
post dead offline operation
T1 holds lockA
T1 is scheduled out
//throttled by CFS bandwidth control
T1 waits for 'period_timer' to expire
T2(worker thread) waits for lockA
T1 waits there forever if it is scheduled out before it can execute the
hrtimer offline callback hrtimers_dead_cpu().
Thus T2 waits for lockA forever.
We discovered several different 'lockA'. This is a real example that occurs on
kernel 5.10, where 'lockA' is 'kernfs_mutex'.
T1
PID: 743234 TASK: ffff0000c7182880 CPU: 0 COMMAND: "tree"
#0 [ffffa00105fd7430] __switch_to at ffffa0010001bbb4
#1 [ffffa00105fd7460] __schedule at ffffa001013e11f4
#2 [ffffa00105fd7580] __cond_resched at ffffa001013e2278
#3 [ffffa00105fd75a0] kmem_cache_alloc at ffffa00100589168
#4 [ffffa00105fd75f0] security_inode_alloc at ffffa001007c9a64
#5 [ffffa00105fd7620] inode_init_always at ffffa001006538fc
#6 [ffffa00105fd7670] alloc_inode at ffffa001006566e4
#7 [ffffa00105fd76a0] iget_locked at ffffa00100658378
#8 [ffffa00105fd7770] kernfs_get_inode at ffffa0010075a244
#9 [ffffa00105fd7790] kernfs_iop_lookup at ffffa0010075c530
#10 [ffffa00105fd77d0] __lookup_slow at ffffa0010062de68
#11 [ffffa00105fd78c0] walk_component at ffffa0010063595c
#12 [ffffa00105fd7990] path_lookupat at ffffa001006360fc
#13 [ffffa00105fd79f0] filename_lookup at ffffa00100638b60
#14 [ffffa00105fd7ba0] user_path_at_empty at ffffa00100638e40
#15 [ffffa00105fd7bd0] vfs_statx at ffffa00100621974
#16 [ffffa00105fd7cb0] __se_sys_newfstatat at ffffa001006223b4
#17 [ffffa00105fd7df0] __arm64_sys_newfstatat at ffffa00100622468
#18 [ffffa00105fd7e20] el0_svc_common.constprop.0 at ffffa00100036144
#19 [ffffa00105fd7e60] do_el0_svc at ffffa00100036368
#20 [ffffa00105fd7e80] el0_svc at ffffa001013d6cfc
#21 [ffffa00105fd7ea0] el0_sync_handler at ffffa001013d75fc
#22 [ffffa00105fd7fe0] el0_sync at ffffa0010001255c
T2
PID: 240180 TASK: ffff0000f25ba880 CPU: 0 COMMAND: "kworker/0:7"
#0 [ffffa00105e37710] __switch_to at ffffa0010001bbb4
#1 [ffffa00105e37740] __schedule at ffffa001013e11f4
#2 [ffffa00105e37860] schedule at ffffa001013e1a3c
#3 [ffffa00105e37890] schedule_preempt_disabled at ffffa001013e2384
#4 [ffffa00105e378a0] __mutex_lock.constprop.0 at ffffa001013e418c
#5 [ffffa00105e379d0] __mutex_lock_slowpath at ffffa001013e4d48
#6 [ffffa00105e379e0] mutex_lock at ffffa001013e4ec0
#7 [ffffa00105e37a90] kernfs_find_and_get_ns at ffffa0010075c168
#8 [ffffa00105e37ac0] sysfs_remove_group at ffffa00100764698
#9 [ffffa00105e37af0] topology_remove_dev at ffffa00100d8f0a0
#10 [ffffa00105e37b00] cpuhp_invoke_callback at ffffa00100102fc4
#11 [ffffa00105e37ba0] _cpu_down at ffffa001013d89b8
#12 [ffffa00105e37c10] alloc_insn_page at ffffa0010006df98
#13 [ffffa00105e37c30] work_for_cpu_fn at ffffa00100139014
#14 [ffffa00105e37c50] process_one_work at ffffa00100141318
#15 [ffffa00105e37d50] worker_thread at ffffa00100141b7c
#16 [ffffa00105e37e50] kthread at ffffa0010014e5c8
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Bug report] A variant deadlock issue of CPU hot-unplug operation vs. the CFS bandwidth timer
2023-11-07 13:26 [Bug report] A variant deadlock issue of CPU hot-unplug operation vs. the CFS bandwidth timer Yu Liao
@ 2023-11-07 14:57 ` Thomas Gleixner
2023-11-09 12:20 ` liutie (A)
2023-11-11 17:15 ` [tip: timers/urgent] hrtimers: Push pending hrtimers away from outgoing CPU earlier tip-bot2 for Thomas Gleixner
0 siblings, 2 replies; 4+ messages in thread
From: Thomas Gleixner @ 2023-11-07 14:57 UTC (permalink / raw)
To: Yu Liao, Vincent Guittot, Ingo Molnar
Cc: linux-kernel@vger.kernel.org, liwei (GF), xiafukun, liutie4,
Peter Zijlstra, Dietmar Eggemann, Phil Auld, vschneid, vdonnefort,
Xiongfeng Wang
On Tue, Nov 07 2023 at 21:26, Yu Liao wrote:
> The patch [1] from tglx solved the deadlock issue reported by Xiongfeng [2],
> but recently we discovered a variant of the deadlock issue.
>
> [1] https://lore.kernel.org/all/87h6oqdq0i.ffs@tglx/
> [2] https://lore.kernel.org/all/8e785777-03aa-99e1-d20e-e956f5685be6@huawei.com/
>
> (The following description is partially borrowed from the commit log of tglx)
> CPU1 CPU2 CPU3
>
> T1 sets cfs_quota
> starts hrtimer cfs_bandwidth 'period_timer'
> T1 is migrated to CPU3
> T2(worker thread) initiates
> offlining of CPU1
> Hotplug operation starts
> ...
> 'period_timer' expires and is
> re-enqueued on CPU1
> ...
> take_cpu_down()
> CPU1 shuts down and does not handle timers
> anymore. They have to be migrated in the
> post dead hotplug steps by the control task.
>
> T2(worker thread) runs the
> post dead offline operation
> T1 holds lockA
> T1 is scheduled out
> //throttled by CFS bandwidth control
> T1 waits for 'period_timer' to expire
> T2(worker thread) waits for lockA
>
> T1 waits there forever if it is scheduled out before it can execute the
> hrtimer offline callback hrtimers_dead_cpu().
> Thus T2 waits for lockA forever.
>
> We discovered several different 'lockA'. This is a real example that occurs on
> kernel 5.10, where 'lockA' is 'kernfs_mutex'.
Bah.
So we can actually migrate the hrtimers away from the outgoing CPU in
the dying callbacks. That's safe as nothing can queue an hrtimer remote
on the outgoing CPU because all other CPUs are spinwaiting with
interrupts disabled in stomp_machine() until the CPU marked itself
offline.
Survived a quick test, but needs some scrunity and probably a sanity
check in the post dead stage.
Thanks,
tglx
---
--- a/include/linux/cpuhotplug.h
+++ b/include/linux/cpuhotplug.h
@@ -195,6 +195,7 @@ enum cpuhp_state {
CPUHP_AP_ARM_CORESIGHT_CTI_STARTING,
CPUHP_AP_ARM64_ISNDEP_STARTING,
CPUHP_AP_SMPCFD_DYING,
+ CPUHP_AP_HRTIMERS_DYING,
CPUHP_AP_X86_TBOOT_DYING,
CPUHP_AP_ARM_CACHE_B15_RAC_DYING,
CPUHP_AP_ONLINE,
--- a/include/linux/hrtimer.h
+++ b/include/linux/hrtimer.h
@@ -531,9 +531,9 @@ extern void sysrq_timer_list_show(void);
int hrtimers_prepare_cpu(unsigned int cpu);
#ifdef CONFIG_HOTPLUG_CPU
-int hrtimers_dead_cpu(unsigned int cpu);
+int hrtimers_cpu_dying(unsigned int cpu);
#else
-#define hrtimers_dead_cpu NULL
+#define hrtimers_cpu_dying NULL
#endif
#endif
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -2116,7 +2116,7 @@ static struct cpuhp_step cpuhp_hp_states
[CPUHP_HRTIMERS_PREPARE] = {
.name = "hrtimers:prepare",
.startup.single = hrtimers_prepare_cpu,
- .teardown.single = hrtimers_dead_cpu,
+ .teardown.single = NULL,
},
[CPUHP_SMPCFD_PREPARE] = {
.name = "smpcfd:prepare",
@@ -2208,6 +2208,12 @@ static struct cpuhp_step cpuhp_hp_states
.startup.single = NULL,
.teardown.single = smpcfd_dying_cpu,
},
+ [CPUHP_AP_HRTIMERS_DYING] = {
+ .name = "hrtimers:dying",
+ .startup.single = NULL,
+ .teardown.single = hrtimers_cpu_dying,
+ },
+
/* Entry state on starting. Interrupts enabled from here on. Transient
* state for synchronsization */
[CPUHP_AP_ONLINE] = {
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -2219,29 +2219,22 @@ static void migrate_hrtimer_list(struct
}
}
-int hrtimers_dead_cpu(unsigned int scpu)
+int hrtimers_cpu_dying(unsigned int dying_cpu)
{
struct hrtimer_cpu_base *old_base, *new_base;
- int i;
+ int i, ncpu = cpumask_first(cpu_active_mask);
- BUG_ON(cpu_online(scpu));
- tick_cancel_sched_timer(scpu);
+ tick_cancel_sched_timer(dying_cpu);
+
+ old_base = this_cpu_ptr(&hrtimer_bases);
+ new_base = &per_cpu(hrtimer_bases, ncpu);
- /*
- * this BH disable ensures that raise_softirq_irqoff() does
- * not wakeup ksoftirqd (and acquire the pi-lock) while
- * holding the cpu_base lock
- */
- local_bh_disable();
- local_irq_disable();
- old_base = &per_cpu(hrtimer_bases, scpu);
- new_base = this_cpu_ptr(&hrtimer_bases);
/*
* The caller is globally serialized and nobody else
* takes two locks at once, deadlock is not possible.
*/
- raw_spin_lock(&new_base->lock);
- raw_spin_lock_nested(&old_base->lock, SINGLE_DEPTH_NESTING);
+ raw_spin_lock(&old_base->lock);
+ raw_spin_lock_nested(&new_base->lock, SINGLE_DEPTH_NESTING);
for (i = 0; i < HRTIMER_MAX_CLOCK_BASES; i++) {
migrate_hrtimer_list(&old_base->clock_base[i],
@@ -2252,15 +2245,13 @@ int hrtimers_dead_cpu(unsigned int scpu)
* The migration might have changed the first expiring softirq
* timer on this CPU. Update it.
*/
- hrtimer_update_softirq_timer(new_base, false);
+ __hrtimer_get_next_event(new_base, HRTIMER_ACTIVE_SOFT);
+ /* Tell the other CPU to retrigger the next event */
+ smp_call_function_single(ncpu, retrigger_next_event, NULL, 0);
- raw_spin_unlock(&old_base->lock);
raw_spin_unlock(&new_base->lock);
+ raw_spin_unlock(&old_base->lock);
- /* Check, if we got expired work to do */
- __hrtimer_peek_ahead_timers();
- local_irq_enable();
- local_bh_enable();
return 0;
}
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Bug report] A variant deadlock issue of CPU hot-unplug operation vs. the CFS bandwidth timer
2023-11-07 14:57 ` Thomas Gleixner
@ 2023-11-09 12:20 ` liutie (A)
2023-11-11 17:15 ` [tip: timers/urgent] hrtimers: Push pending hrtimers away from outgoing CPU earlier tip-bot2 for Thomas Gleixner
1 sibling, 0 replies; 4+ messages in thread
From: liutie (A) @ 2023-11-09 12:20 UTC (permalink / raw)
To: Thomas Gleixner, Yu Liao, Vincent Guittot, Ingo Molnar
Cc: linux-kernel@vger.kernel.org, liwei (GF), xiafukun,
Peter Zijlstra, Dietmar Eggemann, Phil Auld, vschneid, vdonnefort,
Xiongfeng Wang, liuchao173
On 2023/11/7 22:57, Thomas Gleixner wrote:
>
> Bah.
>
> So we can actually migrate the hrtimers away from the outgoing CPU in
> the dying callbacks. That's safe as nothing can queue an hrtimer remote
> on the outgoing CPU because all other CPUs are spinwaiting with
> interrupts disabled in stomp_machine() until the CPU marked itself
> offline.
>
> Survived a quick test, but needs some scrunity and probably a sanity
> check in the post dead stage.
>
> Thanks,
>
> tglx
> ---
> --- a/include/linux/cpuhotplug.h
> +++ b/include/linux/cpuhotplug.h
> @@ -195,6 +195,7 @@ enum cpuhp_state {
> CPUHP_AP_ARM_CORESIGHT_CTI_STARTING,
> CPUHP_AP_ARM64_ISNDEP_STARTING,
> CPUHP_AP_SMPCFD_DYING,
> + CPUHP_AP_HRTIMERS_DYING,
> CPUHP_AP_X86_TBOOT_DYING,
> CPUHP_AP_ARM_CACHE_B15_RAC_DYING,
> CPUHP_AP_ONLINE,
> --- a/include/linux/hrtimer.h
> +++ b/include/linux/hrtimer.h
> @@ -531,9 +531,9 @@ extern void sysrq_timer_list_show(void);
>
> int hrtimers_prepare_cpu(unsigned int cpu);
> #ifdef CONFIG_HOTPLUG_CPU
> -int hrtimers_dead_cpu(unsigned int cpu);
> +int hrtimers_cpu_dying(unsigned int cpu);
> #else
> -#define hrtimers_dead_cpu NULL
> +#define hrtimers_cpu_dying NULL
> #endif
>
> #endif
> --- a/kernel/cpu.c
> +++ b/kernel/cpu.c
> @@ -2116,7 +2116,7 @@ static struct cpuhp_step cpuhp_hp_states
> [CPUHP_HRTIMERS_PREPARE] = {
> .name = "hrtimers:prepare",
> .startup.single = hrtimers_prepare_cpu,
> - .teardown.single = hrtimers_dead_cpu,
> + .teardown.single = NULL,
> },
> [CPUHP_SMPCFD_PREPARE] = {
> .name = "smpcfd:prepare",
> @@ -2208,6 +2208,12 @@ static struct cpuhp_step cpuhp_hp_states
> .startup.single = NULL,
> .teardown.single = smpcfd_dying_cpu,
> },
> + [CPUHP_AP_HRTIMERS_DYING] = {
> + .name = "hrtimers:dying",
> + .startup.single = NULL,
> + .teardown.single = hrtimers_cpu_dying,
> + },
> +
> /* Entry state on starting. Interrupts enabled from here on. Transient
> * state for synchronsization */
> [CPUHP_AP_ONLINE] = {
> --- a/kernel/time/hrtimer.c
> +++ b/kernel/time/hrtimer.c
> @@ -2219,29 +2219,22 @@ static void migrate_hrtimer_list(struct
> }
> }
>
> -int hrtimers_dead_cpu(unsigned int scpu)
> +int hrtimers_cpu_dying(unsigned int dying_cpu)
> {
> struct hrtimer_cpu_base *old_base, *new_base;
> - int i;
> + int i, ncpu = cpumask_first(cpu_active_mask);
>
> - BUG_ON(cpu_online(scpu));
> - tick_cancel_sched_timer(scpu);
> + tick_cancel_sched_timer(dying_cpu);
> +
> + old_base = this_cpu_ptr(&hrtimer_bases);
> + new_base = &per_cpu(hrtimer_bases, ncpu);
>
> - /*
> - * this BH disable ensures that raise_softirq_irqoff() does
> - * not wakeup ksoftirqd (and acquire the pi-lock) while
> - * holding the cpu_base lock
> - */
> - local_bh_disable();
> - local_irq_disable();
> - old_base = &per_cpu(hrtimer_bases, scpu);
> - new_base = this_cpu_ptr(&hrtimer_bases);
> /*
> * The caller is globally serialized and nobody else
> * takes two locks at once, deadlock is not possible.
> */
> - raw_spin_lock(&new_base->lock);
> - raw_spin_lock_nested(&old_base->lock, SINGLE_DEPTH_NESTING);
> + raw_spin_lock(&old_base->lock);
> + raw_spin_lock_nested(&new_base->lock, SINGLE_DEPTH_NESTING);
>
> for (i = 0; i < HRTIMER_MAX_CLOCK_BASES; i++) {
> migrate_hrtimer_list(&old_base->clock_base[i],
> @@ -2252,15 +2245,13 @@ int hrtimers_dead_cpu(unsigned int scpu)
> * The migration might have changed the first expiring softirq
> * timer on this CPU. Update it.
> */
> - hrtimer_update_softirq_timer(new_base, false);
> + __hrtimer_get_next_event(new_base, HRTIMER_ACTIVE_SOFT);
> + /* Tell the other CPU to retrigger the next event */
> + smp_call_function_single(ncpu, retrigger_next_event, NULL, 0);
>
> - raw_spin_unlock(&old_base->lock);
> raw_spin_unlock(&new_base->lock);
> + raw_spin_unlock(&old_base->lock);
>
> - /* Check, if we got expired work to do */
> - __hrtimer_peek_ahead_timers();
> - local_irq_enable();
> - local_bh_enable();
> return 0;
> }
>
Thanks for the patch. Tested in v6.6 and this patch works.
Tested-by: Liu Tie <liutie4@huawei.com>
Best regards,
Tie
^ permalink raw reply [flat|nested] 4+ messages in thread
* [tip: timers/urgent] hrtimers: Push pending hrtimers away from outgoing CPU earlier
2023-11-07 14:57 ` Thomas Gleixner
2023-11-09 12:20 ` liutie (A)
@ 2023-11-11 17:15 ` tip-bot2 for Thomas Gleixner
1 sibling, 0 replies; 4+ messages in thread
From: tip-bot2 for Thomas Gleixner @ 2023-11-11 17:15 UTC (permalink / raw)
To: linux-tip-commits; +Cc: Yu Liao, Thomas Gleixner, Liu Tie, x86, linux-kernel
The following commit has been merged into the timers/urgent branch of tip:
Commit-ID: 5c0930ccaad5a74d74e8b18b648c5eb21ed2fe94
Gitweb: https://git.kernel.org/tip/5c0930ccaad5a74d74e8b18b648c5eb21ed2fe94
Author: Thomas Gleixner <tglx@linutronix.de>
AuthorDate: Tue, 07 Nov 2023 15:57:13 +01:00
Committer: Thomas Gleixner <tglx@linutronix.de>
CommitterDate: Sat, 11 Nov 2023 18:06:42 +01:00
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
---
include/linux/cpuhotplug.h | 1 +
include/linux/hrtimer.h | 4 ++--
kernel/cpu.c | 8 +++++++-
kernel/time/hrtimer.c | 33 ++++++++++++---------------------
4 files changed, 22 insertions(+), 24 deletions(-)
diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
index 068f773..448f5f9 100644
--- a/include/linux/cpuhotplug.h
+++ b/include/linux/cpuhotplug.h
@@ -193,6 +193,7 @@ enum cpuhp_state {
CPUHP_AP_ARM_CORESIGHT_CTI_STARTING,
CPUHP_AP_ARM64_ISNDEP_STARTING,
CPUHP_AP_SMPCFD_DYING,
+ CPUHP_AP_HRTIMERS_DYING,
CPUHP_AP_X86_TBOOT_DYING,
CPUHP_AP_ARM_CACHE_B15_RAC_DYING,
CPUHP_AP_ONLINE,
diff --git a/include/linux/hrtimer.h b/include/linux/hrtimer.h
index 0ee1401..f2044d5 100644
--- a/include/linux/hrtimer.h
+++ b/include/linux/hrtimer.h
@@ -531,9 +531,9 @@ extern void sysrq_timer_list_show(void);
int hrtimers_prepare_cpu(unsigned int cpu);
#ifdef CONFIG_HOTPLUG_CPU
-int hrtimers_dead_cpu(unsigned int cpu);
+int hrtimers_cpu_dying(unsigned int cpu);
#else
-#define hrtimers_dead_cpu NULL
+#define hrtimers_cpu_dying NULL
#endif
#endif
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 6de7c6b..2e69a1d 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -2098,7 +2098,7 @@ static struct cpuhp_step cpuhp_hp_states[] = {
[CPUHP_HRTIMERS_PREPARE] = {
.name = "hrtimers:prepare",
.startup.single = hrtimers_prepare_cpu,
- .teardown.single = hrtimers_dead_cpu,
+ .teardown.single = NULL,
},
[CPUHP_SMPCFD_PREPARE] = {
.name = "smpcfd:prepare",
@@ -2190,6 +2190,12 @@ static struct cpuhp_step cpuhp_hp_states[] = {
.startup.single = NULL,
.teardown.single = smpcfd_dying_cpu,
},
+ [CPUHP_AP_HRTIMERS_DYING] = {
+ .name = "hrtimers:dying",
+ .startup.single = NULL,
+ .teardown.single = hrtimers_cpu_dying,
+ },
+
/* Entry state on starting. Interrupts enabled from here on. Transient
* state for synchronsization */
[CPUHP_AP_ONLINE] = {
diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index 238262e..7607939 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -2219,29 +2219,22 @@ static void migrate_hrtimer_list(struct hrtimer_clock_base *old_base,
}
}
-int hrtimers_dead_cpu(unsigned int scpu)
+int hrtimers_cpu_dying(unsigned int dying_cpu)
{
struct hrtimer_cpu_base *old_base, *new_base;
- int i;
+ int i, ncpu = cpumask_first(cpu_active_mask);
- BUG_ON(cpu_online(scpu));
- tick_cancel_sched_timer(scpu);
+ tick_cancel_sched_timer(dying_cpu);
+
+ old_base = this_cpu_ptr(&hrtimer_bases);
+ new_base = &per_cpu(hrtimer_bases, ncpu);
- /*
- * this BH disable ensures that raise_softirq_irqoff() does
- * not wakeup ksoftirqd (and acquire the pi-lock) while
- * holding the cpu_base lock
- */
- local_bh_disable();
- local_irq_disable();
- old_base = &per_cpu(hrtimer_bases, scpu);
- new_base = this_cpu_ptr(&hrtimer_bases);
/*
* The caller is globally serialized and nobody else
* takes two locks at once, deadlock is not possible.
*/
- raw_spin_lock(&new_base->lock);
- raw_spin_lock_nested(&old_base->lock, SINGLE_DEPTH_NESTING);
+ raw_spin_lock(&old_base->lock);
+ raw_spin_lock_nested(&new_base->lock, SINGLE_DEPTH_NESTING);
for (i = 0; i < HRTIMER_MAX_CLOCK_BASES; i++) {
migrate_hrtimer_list(&old_base->clock_base[i],
@@ -2252,15 +2245,13 @@ int hrtimers_dead_cpu(unsigned int scpu)
* The migration might have changed the first expiring softirq
* timer on this CPU. Update it.
*/
- hrtimer_update_softirq_timer(new_base, false);
+ __hrtimer_get_next_event(new_base, HRTIMER_ACTIVE_SOFT);
+ /* Tell the other CPU to retrigger the next event */
+ smp_call_function_single(ncpu, retrigger_next_event, NULL, 0);
- raw_spin_unlock(&old_base->lock);
raw_spin_unlock(&new_base->lock);
+ raw_spin_unlock(&old_base->lock);
- /* Check, if we got expired work to do */
- __hrtimer_peek_ahead_timers();
- local_irq_enable();
- local_bh_enable();
return 0;
}
^ permalink raw reply related [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-11-11 17:16 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-11-07 13:26 [Bug report] A variant deadlock issue of CPU hot-unplug operation vs. the CFS bandwidth timer Yu Liao
2023-11-07 14:57 ` Thomas Gleixner
2023-11-09 12:20 ` liutie (A)
2023-11-11 17:15 ` [tip: timers/urgent] hrtimers: Push pending hrtimers away from outgoing CPU earlier tip-bot2 for Thomas Gleixner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox