[RFC 0/1] sched/rt: Avoid RTO push to stopped CPUs during shutdown

From: wangqk1

Date: Mon Oct 12 2026 - 23:04:32 EST


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