[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8e30b99e-70ed-7d5a-ea1f-3b0fadb644bc@igalia.com>
Date: Mon, 17 Oct 2022 11:00:46 -0300
From: "Guilherme G. Piccoli" <gpiccoli@...lia.com>
To: Russell King <linux@...linux.org.uk>,
Marc Zyngier <maz@...nel.org>,
linux-arm-kernel@...ts.infradead.org, will@...nel.org,
Mark Rutland <mark.rutland@....com>, arnd@...db.de,
Catalin Marinas <catalin.marinas@....com>
Cc: kexec@...ts.infradead.org, pmladek@...e.com, bhe@...hat.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,
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,
xuqiang36@...wei.com
Subject: Re: [PATCH V3 01/11] ARM: Disable FIQs (but not IRQs) on CPUs
shutdown paths
On 18/09/2022 10:58, Guilherme G. Piccoli wrote:
> On 19/08/2022 19:17, 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>
>>
Monthly ping - let me know if there's something I should improve in
order this fix is considered!
Thanks,
Guilherme
Powered by blists - more mailing lists