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

[wangqk1 <wangqk1@xiaopeng.com>]

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