Re: [PATCH v3] riscv: disable local interrupts and stop other CPUs before reboot/shutdown
"Troy Mitchell" <[email protected]> Wed, 29 Jul 2026 19:40:19 -0700
| Newsgroups | dev.linux.lists.spacemit,org.infradead.lists.linux-riscv,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
--554137b98fdb9fb3d0fba56055422f9db991cf28966e80a0180e40cc316f Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 On Mon Mar 30, 2026 at 2:58 AM PDT, Troy Mitchell wrote: > From: Troy Mitchell <[email protected]> > > Currently, the RISC-V implementation of machine_restart(), machine_halt()= , > and machine_power_off() invokes the kernel teardown chains (e.g., > do_kernel_restart()) with local interrupts enabled and other CPUs still > running. > > This implementation fails to provide a deterministic execution environmen= t > for registered handlers in the restart or power-off notifier chains. Thes= e > chains are intended to be executed in a strict atomic and single-threaded > context. > > Specifically, under CONFIG_PREEMPT_RCU, rcu_read_lock() does not incremen= t > the preempt_count. If local interrupts remain enabled, the environment > is not guaranteed to be atomic. This can lead to a context misidentificat= ion > within generic kernel teardown code, causing it to incorrectly enter > non-atomic paths (such as attempting to acquire sleeping locks), which > results in fatal "scheduling while atomic" splats or system hangs. > > Additionally, stopping other CPUs ensures the primary CPU has exclusive > access to the hardware state during the final teardown phase, preventing > unpredictable interference from other active cores. > > Align RISC-V with other major architectures by disabling local interrupts > and stopping other CPUs at the beginning of the shutdown sequences. This > guarantees the architectural expectations of the kernel's restart and > power-off handlers are met. > > Signed-off-by: Troy Mitchell <[email protected]> > Tested-by: Aurelien Jarno <[email protected]> Hi Paul, A gentle ping on this patch. When you have a chance, could you please take a look and let me know whether this approach looks reasonable? - Troy --554137b98fdb9fb3d0fba56055422f9db991cf28966e80a0180e40cc316f Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iJcEABYKAD8WIQSL4Ay2cExaPXAQcU2YCe+A+TM0LwUCamq5kyEcdHJveS5taXRj aGVsbEBsaW51eC5zcGFjZW1pdC5jb20ACgkQmAnvgPkzNC/WUAEAo/Ayg3TKHBDa h9ruUla/m+yRTaS8PyNF80vaN+vWPBsA/3qm/T+HOqlqDGPdwk5MY23wPc7amVyX g6ursIB/U4kO =1YnG -----END PGP SIGNATURE----- --554137b98fdb9fb3d0fba56055422f9db991cf28966e80a0180e40cc316f--