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--