CVE-2026-64250: LoongArch: Report dying CPU to RCU in stop_this_cpu()

In the Linux kernel, the following vulnerability has been resolved:

LoongArch: Report dying CPU to RCU in stopthiscpu()

This is a port of MIPS commit 9f3f3bdc6d9dac1 ("MIPS: smp: report dying CPU to RCU in stopthiscpu()"). smpsendstop() parks all secondary CPUs in stopthiscpu(). And the function marks the CPU offline for the scheduler via setcpuonline(false) but never informs RCU, so RCU keeps expecting a quiescent state from CPUs that are now spinning forever with interrupts disabled.

As long as nothing waits for an RCU grace period after smpsendstop() this is harmless, which is why it went unnoticed. However, since commit 91840be8f710370 ("irqwork: Fix use-after-free in irqworksingle() on PREEMPTRT"), irqworksync() calls synchronizercu() on architectures without an irqwork self-IPI, i.e. where archirqworkhasinterrupt() returns false. Any irqworksync() issued in the reboot/shutdown/halt path after smpsendstop() then blocks on a grace period that can never complete, hanging the reboot:

WARNING: CPU: 0 PID: 15 at kernel/irqwork.c:144 irqworkqueueon ... rcu: INFO: rcusched detected stalls on CPUs/tasks: rcu: Offline CPU 1 blocking current GP. rcu: Offline CPU 2 blocking current GP. rcu: Offline CPU 3 blocking current GP.

This issue needs some hacks to reproduce, and it was not noticed on LoongArch because archirqworkhasinterrupt() usually returns true.

Call rcutreereportcpudead() once interrupts are disabled, mirroring the generic CPU-hotplug offline path, so RCU stops waiting on the parked CPUs and grace periods can still complete. LoongArch shuts down all CPUs here without going through the CPU-hotplug mechanism, so this report is not otherwise issued.