[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5b1805ff-eb9f-8575-ceb0-9d2e768f3589@igalia.com>
Date: Sun, 7 Aug 2022 12:35:56 -0300
From: "Guilherme G. Piccoli" <gpiccoli@...lia.com>
To: kexec@...ts.infradead.org, linux-arm-kernel@...ts.infradead.org,
Marc Zyngier <maz@...nel.org>,
Russell King <linux@...linux.org.uk>
Cc: bhe@...hat.com, pmladek@...e.com, akpm@...ux-foundation.org,
linux-kernel@...r.kernel.org, linux-hyperv@...r.kernel.org,
netdev@...r.kernel.org, x86@...nel.org, kernel-dev@...lia.com,
kernel@...ccoli.net, halves@...onical.com, fabiomirmar@...il.com,
alejandro.j.jimenez@...cle.com, andriy.shevchenko@...ux.intel.com,
arnd@...db.de, bp@...en8.de, corbet@....net,
d.hatayama@...fujitsu.com, dave.hansen@...ux.intel.com,
dyoung@...hat.com, feng.tang@...el.com, gregkh@...uxfoundation.org,
mikelley@...rosoft.com, hidehiro.kawai.ez@...achi.com,
jgross@...e.com, john.ogness@...utronix.de, keescook@...omium.org,
luto@...nel.org, mhiramat@...nel.org, mingo@...hat.com,
paulmck@...nel.org, peterz@...radead.org, rostedt@...dmis.org,
senozhatsky@...omium.org, stern@...land.harvard.edu,
tglx@...utronix.de, vgoyal@...hat.com, vkuznets@...hat.com,
will@...nel.org
Subject: Re: [PATCH v2 01/13] ARM: Disable FIQs (but not IRQs) on CPUs
shutdown paths
On 19/07/2022 16:53, Guilherme G. Piccoli wrote:
> Currently the regular CPU shutdown path for ARM disables IRQs/FIQs
> in the secondary CPUs - smp_send_stop() calls ipi_cpu_stop(), which
> is responsible for that. IRQs are architecturally masked when we
> take an interrupt, but FIQs are high priority than IRQs, hence they
> aren't masked. With that said, it makes sense to disable FIQs here,
> but there's no need for (re-)disabling IRQs.
>
> More than that: there is an alternative path for disabling CPUs,
> in the form of function crash_smp_send_stop(), which is used for
> kexec/panic path. This function relies on a SMP call that also
> triggers a busy-wait loop [at machine_crash_nonpanic_core()], but
> without disabling FIQs. This might lead to odd scenarios, like
> early interrupts in the boot of kexec'd kernel or even interrupts
> in secondary "disabled" CPUs while the main one still works in the
> panic path and assumes all secondary CPUs are (really!) off.
>
> So, let's disable FIQs in both paths and *not* disable IRQs a second
> time, since they are already masked in both paths by the architecture.
> This way, we keep both CPU quiesce paths consistent and safe.
>
> Cc: Marc Zyngier <maz@...nel.org>
> Cc: Michael Kelley <mikelley@...rosoft.com>
> Cc: Russell King <linux@...linux.org.uk>
> Signed-off-by: Guilherme G. Piccoli <gpiccoli@...lia.com>
>
> ---
>
> V2:
> - Small wording improvement (thanks Michael Kelley);
> - Only disable FIQs, since IRQs are masked by architecture
> definition when we take an interrupt. Thanks a lot Russell
> and Marc for the discussion [0].
>
> Should we add a Fixes tag here? If so, maybe the proper target is:
> b23065313297 ("ARM: 6522/1: kexec: Add call to non-crashing cores through IPI")
>
> [0] https://lore.kernel.org/lkml/Ymxcaqy6DwhoQrZT@shell.armlinux.org.uk/
>
> arch/arm/kernel/machine_kexec.c | 2 ++
> arch/arm/kernel/smp.c | 5 ++---
> 2 files changed, 4 insertions(+), 3 deletions(-)
> [...]
Hi Mark / Russell, do you think this one is good enough or is there room
for improvement?
Appreciate the reviews!
Cheers,
Guilherme
Powered by blists - more mailing lists