* [RFC 0/1] sched/rt: Avoid RTO push to stopped CPUs during shutdown
@ 2026-10-13 3:01 wangqk1
2026-10-13 3:01 ` [RFC 1/1] " wangqk1
0 siblings, 1 reply; 3+ messages in thread
From: wangqk1 @ 2026-10-13 3:01 UTC (permalink / raw)
To: linux-kernel
Cc: xiedl3, mingo, peterz, juri.lelli, vincent.guittot, bigeasy,
clrkwllms, rostedt, linux-rt-devel
Hi,
I am sending this RFC to discuss an rto push irq_work submission to a
CPU that has already been stopped during system shutdown.
On an SMP PREEMPT_RT arm64 system, machine_power_off() eventually calls
smp_send_stop(). The IPI_CPU_STOP handler parks the target CPU directly
without running normal CPU hotplug teardown.
In particular, rq_offline_rt() is not reached, so an overloaded RT
runqueue can retain a stale rto_mask bit after its CPU is no longer online.
Another CPU can still run rto_push_irq_work_func() and select that entry.
The observed path is:
irq_work_queue_on()
rto_push_irq_work_func()
irq_work_single()
__flush_smp_call_function_queue()
generic_smp_call_function_single_interrupt()
ipi_handler()
Normal CPU hotplug clears RT overload state and flushes pending
call-function and irq_work callbacks before a CPU is parked.
smp_send_stop() intentionally bypasses that protocol because it is also
used by panic and crash paths.
The patch stops rto forwarding after terminal system states begin and
skips rto_mask entries that are already offline.
This is a workaround, not a complete synchronization solution. It does
not make cpu_online() and irq_work_queue_on() atomic, and it does not
cover panic or crash-kexec paths.
I would appreciate feedback on whether this consumer-side hardening is
acceptable, or whether rto push needs an explicit quiesce protocol before
smp_send_stop() stops secondary CPUs.
Testing:
- Built kernel/sched/rt.o with x86_64 defconfig.
- checkpatch.pl reports no errors or warnings.
- Runtime reproduction against mainline has not yet been performed.
Thanks,
wangqk1
wangqk1 (1):
sched/rt: Avoid RTO push to stopped CPUs during shutdown
kernel/sched/rt.c | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
--
2.43.0
^ permalink raw reply [flat|nested] 3+ messages in thread
* [RFC 1/1] sched/rt: Avoid RTO push to stopped CPUs during shutdown
2026-10-13 3:01 [RFC 0/1] sched/rt: Avoid RTO push to stopped CPUs during shutdown wangqk1
@ 2026-10-13 3:01 ` wangqk1
2026-10-13 12:03 ` Peter Zijlstra
0 siblings, 1 reply; 3+ messages in thread
From: wangqk1 @ 2026-10-13 3:01 UTC (permalink / raw)
To: linux-kernel
Cc: xiedl3, mingo, peterz, juri.lelli, vincent.guittot, bigeasy,
clrkwllms, rostedt, linux-rt-devel
During system poweroff, machine_power_off() invokes smp_send_stop(). A
CPU receiving IPI_CPU_STOP parks without running the CPU hotplug teardown.
Its RT overload state can therefore retain a stale rto_mask bit.
A CPU still executing the RTO irq_work iterator can select that stale bit
and queue work to the stopped CPU.
Observed call trace:
irq_work_queue_on()
rto_push_irq_work_func()
irq_work_single()
__flush_smp_call_function_queue()
generic_smp_call_function_single_interrupt()
ipi_handler()
Stop RTO forwarding after terminal system states begin and skip rto_mask
candidates that are already offline.
This is a workaround, not a complete synchronization protocol. The
cpu_online() test is not atomic with irq_work_queue_on(), and panic or
crash-kexec paths do not set a terminal system_state before stopping CPUs.
Signed-off-by: wangqk1 <wangqk1@xiaopeng.com>
---
kernel/sched/rt.c | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index 85303add726d..716ac30c5afb 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -2084,6 +2084,14 @@ static void push_rt_tasks(struct rq *rq)
#ifdef HAVE_RT_PUSH_IPI
+static inline bool rto_push_allowed(void)
+{
+ enum system_states state = READ_ONCE(system_state);
+
+ return state != SYSTEM_HALT && state != SYSTEM_POWER_OFF &&
+ state != SYSTEM_RESTART;
+}
+
/*
* When a high priority task schedules out from a CPU and a lower priority
* task is scheduled in, a check is made to see if there's any RT tasks
@@ -2131,6 +2139,11 @@ static int rto_next_cpu(struct root_domain *rd)
int next;
int cpu;
+ if (unlikely(!rto_push_allowed())) {
+ rd->rto_cpu = -1;
+ return -1;
+ }
+
/*
* When starting the IPI RT pushing, the rto_cpu is set to -1,
* rt_next_cpu() will simply return the first CPU found in
@@ -2155,8 +2168,13 @@ static int rto_next_cpu(struct root_domain *rd)
if (cpu == this_cpu)
continue;
- if (cpu < nr_cpu_ids)
+ if (cpu < nr_cpu_ids) {
+ /* smp_send_stop() does not clear stale rto_mask bits. */
+ if (!cpu_online(cpu))
+ continue;
+
return cpu;
+ }
rd->rto_cpu = -1;
--
2.43.0
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [RFC 1/1] sched/rt: Avoid RTO push to stopped CPUs during shutdown
2026-10-13 3:01 ` [RFC 1/1] " wangqk1
@ 2026-10-13 12:03 ` Peter Zijlstra
0 siblings, 0 replies; 3+ messages in thread
From: Peter Zijlstra @ 2026-10-13 12:03 UTC (permalink / raw)
To: wangqk1
Cc: linux-kernel, xiedl3, mingo, juri.lelli, vincent.guittot,
bigeasy, clrkwllms, rostedt, linux-rt-devel
On Tue, Oct 13, 2026 at 11:01:40AM +0800, wangqk1 wrote:
> During system poweroff, machine_power_off() invokes smp_send_stop(). A
> CPU receiving IPI_CPU_STOP parks without running the CPU hotplug teardown.
> Its RT overload state can therefore retain a stale rto_mask bit.
>
> A CPU still executing the RTO irq_work iterator can select that stale bit
> and queue work to the stopped CPU.
>
> Observed call trace:
> irq_work_queue_on()
> rto_push_irq_work_func()
> irq_work_single()
> __flush_smp_call_function_queue()
> generic_smp_call_function_single_interrupt()
> ipi_handler()
>
> Stop RTO forwarding after terminal system states begin and skip rto_mask
> candidates that are already offline.
>
> This is a workaround, not a complete synchronization protocol. The
> cpu_online() test is not atomic with irq_work_queue_on(), and panic or
> crash-kexec paths do not set a terminal system_state before stopping CPUs.
>
> Signed-off-by: wangqk1 <wangqk1@xiaopeng.com>
> ---
> kernel/sched/rt.c | 20 +++++++++++++++++++-
> 1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
> index 85303add726d..716ac30c5afb 100644
> --- a/kernel/sched/rt.c
> +++ b/kernel/sched/rt.c
> @@ -2084,6 +2084,14 @@ static void push_rt_tasks(struct rq *rq)
>
> #ifdef HAVE_RT_PUSH_IPI
>
> +static inline bool rto_push_allowed(void)
> +{
> + enum system_states state = READ_ONCE(system_state);
> +
> + return state != SYSTEM_HALT && state != SYSTEM_POWER_OFF &&
> + state != SYSTEM_RESTART;
> +}
> +
> /*
> * When a high priority task schedules out from a CPU and a lower priority
> * task is scheduled in, a check is made to see if there's any RT tasks
> @@ -2131,6 +2139,11 @@ static int rto_next_cpu(struct root_domain *rd)
> int next;
> int cpu;
>
> + if (unlikely(!rto_push_allowed())) {
> + rd->rto_cpu = -1;
> + return -1;
> + }
> +
> /*
> * When starting the IPI RT pushing, the rto_cpu is set to -1,
> * rt_next_cpu() will simply return the first CPU found in
> @@ -2155,8 +2168,13 @@ static int rto_next_cpu(struct root_domain *rd)
> if (cpu == this_cpu)
> continue;
>
> - if (cpu < nr_cpu_ids)
> + if (cpu < nr_cpu_ids) {
> + /* smp_send_stop() does not clear stale rto_mask bits. */
> + if (!cpu_online(cpu))
> + continue;
> +
> return cpu;
> + }
>
> rd->rto_cpu = -1;
This is horrific; lets not do this. The bug really is at the place where
you randomly and without warning take CPUs down. We're not adding random
hacks for things like that.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-10-13 12:03 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-10-13 3:01 [RFC 0/1] sched/rt: Avoid RTO push to stopped CPUs during shutdown wangqk1
2026-10-13 3:01 ` [RFC 1/1] " wangqk1
2026-10-13 12:03 ` Peter Zijlstra
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®