From fea3d0b1787fbd8214cbce011f3c49dccafead5a Mon Sep 17 00:00:00 2001 From: Yu Liao Date: Tue, 30 Jul 2024 10:52:47 +0800 Subject: [PATCH 1/2] Revert "tick/broadcast-hrtimer: Prevent the timer device on broadcast duty CPU from being disabled" hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAGE3Q CVE: NA -------------------------------- As this patch is already in upstream, use the upstream commit instead. This reverts commit 1dd6f09786556b35ed64839165d05730c929c89b. Signed-off-by: Yu Liao --- kernel/time/tick-broadcast-hrtimer.c | 13 ------------- 1 file changed, 13 deletions(-) diff --git a/kernel/time/tick-broadcast-hrtimer.c b/kernel/time/tick-broadcast-hrtimer.c index 0dc78744fce6..e28f9210f8a1 100644 --- a/kernel/time/tick-broadcast-hrtimer.c +++ b/kernel/time/tick-broadcast-hrtimer.c @@ -42,19 +42,6 @@ static int bc_shutdown(struct clock_event_device *evt) */ static int bc_set_next(ktime_t expires, struct clock_event_device *bc) { - struct clock_event_device *dev = __this_cpu_read(tick_cpu_device.evtdev); - - /* - * This can be called from CPU offline operation to move broadcast - * assignment. If tick_broadcast_force_mask is set, the CPU local - * timer device may be disabled. And hrtimer_reprogram() will not - * called if the timer is not the first expiring timer. Reprogram - * the cpu local timer device to ensure we can take over the - * broadcast duty. - */ - if (tick_check_broadcast_expired() && expires >= dev->next_event) - clockevents_program_event(dev, dev->next_event, 1); - /* * This is called either from enter/exit idle code or from the * broadcast handler. In all cases tick_broadcast_lock is held. -- Gitee From 5a76b5c0de98f20a8687a279523349e691cb3509 Mon Sep 17 00:00:00 2001 From: Yu Liao Date: Tue, 30 Jul 2024 10:52:48 +0800 Subject: [PATCH 2/2] tick/broadcast: Make takeover of broadcast hrtimer reliable mainline inclusion from mainline-v6.11-rc1 commit f7d43dd206e7e18c182f200e67a8db8c209907fa category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAGE3Q CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f7d43dd206e7e18c182f200e67a8db8c209907fa -------------------------------- Running the LTP hotplug stress test on a aarch64 machine results in rcu_sched stall warnings when the broadcast hrtimer was owned by the un-plugged CPU. The issue is the following: CPU1 (owns the broadcast hrtimer) CPU2 tick_broadcast_enter() // shutdown local timer device broadcast_shutdown_local() ... tick_broadcast_exit() clockevents_switch_state(dev, CLOCK_EVT_STATE_ONESHOT) // timer device is not programmed cpumask_set_cpu(cpu, tick_broadcast_force_mask) initiates offlining of CPU1 take_cpu_down() /* * CPU1 shuts down and does not * send broadcast IPI anymore */ takedown_cpu() hotplug_cpu__broadcast_tick_pull() // move broadcast hrtimer to this CPU clockevents_program_event() bc_set_next() hrtimer_start() /* * timer device is not programmed * because only the first expiring * timer will trigger clockevent * device reprogramming */ What happens is that CPU2 exits broadcast mode with force bit set, then the local timer device is not reprogrammed and CPU2 expects to receive the expired event by the broadcast IPI. But this does not happen because CPU1 is offlined by CPU2. CPU switches the clockevent device to ONESHOT state, but does not reprogram the device. The subsequent reprogramming of the hrtimer broadcast device does not program the clockevent device of CPU2 either because the pending expiry time is already in the past and the CPU expects the event to be delivered. As a consequence all CPUs which wait for a broadcast event to be delivered are stuck forever. Fix this issue by reprogramming the local timer device if the broadcast force bit of the CPU is set so that the broadcast hrtimer is delivered. [ tglx: Massage comment and change log. Add Fixes tag ] Fixes: 989dcb645ca7 ("tick: Handle broadcast wakeup of multiple cpus") Signed-off-by: Yu Liao Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240711124843.64167-1-liaoyu15@huawei.com Signed-off-by: Yu Liao --- kernel/time/tick-broadcast.c | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c index 771d1e040303..b4843099a8da 100644 --- a/kernel/time/tick-broadcast.c +++ b/kernel/time/tick-broadcast.c @@ -1141,6 +1141,7 @@ void tick_broadcast_switch_to_oneshot(void) #ifdef CONFIG_HOTPLUG_CPU void hotplug_cpu__broadcast_tick_pull(int deadcpu) { + struct tick_device *td = this_cpu_ptr(&tick_cpu_device); struct clock_event_device *bc; unsigned long flags; @@ -1148,6 +1149,28 @@ void hotplug_cpu__broadcast_tick_pull(int deadcpu) bc = tick_broadcast_device.evtdev; if (bc && broadcast_needs_cpu(bc, deadcpu)) { + /* + * If the broadcast force bit of the current CPU is set, + * then the current CPU has not yet reprogrammed the local + * timer device to avoid a ping-pong race. See + * ___tick_broadcast_oneshot_control(). + * + * If the broadcast device is hrtimer based then + * programming the broadcast event below does not have any + * effect because the local clockevent device is not + * running and not programmed because the broadcast event + * is not earlier than the pending event of the local clock + * event device. As a consequence all CPUs waiting for a + * broadcast event are stuck forever. + * + * Detect this condition and reprogram the cpu local timer + * device to avoid the starvation. + */ + if (tick_check_broadcast_expired()) { + cpumask_clear_cpu(smp_processor_id(), tick_broadcast_force_mask); + tick_program_event(td->evtdev->next_event, 1); + } + /* This moves the broadcast assignment to this CPU: */ clockevents_program_event(bc, bc->next_event, 1); } -- Gitee