From: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
To: Russell King <linux@armlinux.org.uk>,
Marc Zyngier <maz@kernel.org>,
linux-arm-kernel@lists.infradead.org, will@kernel.org,
Mark Rutland <mark.rutland@arm.com>,
arnd@arndb.de, Catalin Marinas <catalin.marinas@arm.com>
Cc: kexec@lists.infradead.org, pmladek@suse.com, bhe@redhat.com,
akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
linux-hyperv@vger.kernel.org, netdev@vger.kernel.org,
x86@kernel.org, kernel-dev@igalia.com, kernel@gpiccoli.net,
halves@canonical.com, fabiomirmar@gmail.com,
alejandro.j.jimenez@oracle.com,
andriy.shevchenko@linux.intel.com, bp@alien8.de, corbet@lwn.net,
d.hatayama@jp.fujitsu.com, dave.hansen@linux.intel.com,
dyoung@redhat.com, feng.tang@intel.com,
gregkh@linuxfoundation.org, mikelley@microsoft.com,
hidehiro.kawai.ez@hitachi.com, jgross@suse.com,
john.ogness@linutronix.de, keescook@chromium.org,
luto@kernel.org, mhiramat@kernel.org, mingo@redhat.com,
paulmck@kernel.org, peterz@infradead.org, rostedt@goodmis.org,
senozhatsky@chromium.org, stern@rowland.harvard.edu,
tglx@linutronix.de, vgoyal@redhat.com, vkuznets@redhat.com,
xuqiang36@huawei.com
Subject: Re: [PATCH V3 01/11] ARM: Disable FIQs (but not IRQs) on CPUs shutdown paths
Date: Sun, 18 Sep 2022 10:58:34 -0300 [thread overview]
Message-ID: <a25cb242-7c85-867c-8a61-f3119458dcdb@igalia.com> (raw)
In-Reply-To: <20220819221731.480795-2-gpiccoli@igalia.com>
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@kernel.org>
> Cc: Michael Kelley <mikelley@microsoft.com>
> Cc: Russell King <linux@armlinux.org.uk>
> Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
>
> ---
>
> V3:
> - No changes.
>
> 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(-)
>
> diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
> index f567032a09c0..0b482bcb97f7 100644
> --- a/arch/arm/kernel/machine_kexec.c
> +++ b/arch/arm/kernel/machine_kexec.c
> @@ -77,6 +77,8 @@ void machine_crash_nonpanic_core(void *unused)
> {
> struct pt_regs regs;
>
> + local_fiq_disable();
> +
> crash_setup_regs(®s, get_irq_regs());
> printk(KERN_DEBUG "CPU %u will stop doing anything useful since another CPU has crashed\n",
> smp_processor_id());
> diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
> index 978db2d96b44..36e6efad89f3 100644
> --- a/arch/arm/kernel/smp.c
> +++ b/arch/arm/kernel/smp.c
> @@ -600,6 +600,8 @@ static DEFINE_RAW_SPINLOCK(stop_lock);
> */
> static void ipi_cpu_stop(unsigned int cpu)
> {
> + local_fiq_disable();
> +
> if (system_state <= SYSTEM_RUNNING) {
> raw_spin_lock(&stop_lock);
> pr_crit("CPU%u: stopping\n", cpu);
> @@ -609,9 +611,6 @@ static void ipi_cpu_stop(unsigned int cpu)
>
> set_cpu_online(cpu, false);
>
> - local_fiq_disable();
> - local_irq_disable();
> -
> while (1) {
> cpu_relax();
> wfe();
[+CC all ARM folks I could find]
Hi folks, sorry for the ping. Any reviews are greatly appreciated in
this one - this is the V3 of the series but I never got any specific
review for this patch.
Based on a previous discussion with Russell and Marc [0], seems this one
makes sense and fixes an inconsistency related to kdump/panic.
Really appreciate reviews or at least some indication on which path I
should take to get this potentially merged.
Cheers,
Guilherme
[0] https://lore.kernel.org/lkml/Ymxcaqy6DwhoQrZT@shell.armlinux.org.uk/
next prev parent reply other threads:[~2022-09-18 14:01 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-19 22:17 [PATCH V3 00/11] The panic notifiers refactor - fixes/clean-ups (V3) Guilherme G. Piccoli
2022-08-19 22:17 ` [PATCH V3 01/11] ARM: Disable FIQs (but not IRQs) on CPUs shutdown paths Guilherme G. Piccoli
2022-09-18 13:58 ` Guilherme G. Piccoli [this message]
2022-10-17 14:00 ` Guilherme G. Piccoli
2022-10-17 14:17 ` Russell King (Oracle)
2022-10-17 14:50 ` Guilherme G. Piccoli
2022-10-17 17:47 ` Russell King (Oracle)
2022-10-17 19:43 ` Guilherme G. Piccoli
2022-08-19 22:17 ` [PATCH V3 02/11] notifier: Add panic notifiers info and purge trailing whitespaces Guilherme G. Piccoli
2022-11-22 13:19 ` Guilherme G. Piccoli
2022-08-19 22:17 ` [PATCH V3 03/11] alpha: Clean-up the panic notifier code Guilherme G. Piccoli
2022-11-22 13:22 ` Guilherme G. Piccoli
2022-08-19 22:17 ` [PATCH V3 04/11] um: Improve panic notifiers consistency and ordering Guilherme G. Piccoli
2022-09-18 14:00 ` Guilherme G. Piccoli
2022-09-18 21:19 ` Richard Weinberger
2022-09-19 11:44 ` Guilherme G. Piccoli
2022-10-17 14:01 ` Guilherme G. Piccoli
2022-10-17 14:10 ` Richard Weinberger
2022-10-17 14:22 ` Guilherme G. Piccoli
2022-08-19 22:17 ` [PATCH V3 05/11] parisc: Replace regular spinlock with spin_trylock on panic path Guilherme G. Piccoli
2022-08-19 22:17 ` [PATCH V3 06/11] tracing: Improve panic/die notifiers Guilherme G. Piccoli
2022-09-18 14:04 ` Guilherme G. Piccoli
2022-10-17 14:02 ` Guilherme G. Piccoli
2022-10-20 21:29 ` Steven Rostedt
2022-10-20 21:53 ` Guilherme G. Piccoli
2022-10-20 22:22 ` Steven Rostedt
2022-10-20 22:37 ` Guilherme G. Piccoli
2022-11-22 13:27 ` Guilherme G. Piccoli
2022-12-13 23:51 ` Guilherme G. Piccoli
2022-12-14 0:06 ` Steven Rostedt
2022-12-14 0:52 ` Guilherme G. Piccoli
2022-08-19 22:17 ` [PATCH V3 07/11] notifiers: Add tracepoints to the notifiers infrastructure Guilherme G. Piccoli
2022-09-18 14:07 ` Guilherme G. Piccoli
2022-10-17 14:04 ` Guilherme G. Piccoli
2022-11-22 13:30 ` Guilherme G. Piccoli
2022-08-19 22:17 ` [PATCH V3 08/11] EDAC/altera: Skip the panic notifier if kdump is loaded Guilherme G. Piccoli
2022-09-18 14:10 ` Guilherme G. Piccoli
2022-10-17 14:05 ` Guilherme G. Piccoli
2022-11-22 13:33 ` Guilherme G. Piccoli
2022-11-22 15:06 ` Borislav Petkov
2023-02-10 16:01 ` Guilherme G. Piccoli
2022-12-09 16:03 ` Petr Mladek
2022-08-19 22:17 ` [PATCH V3 09/11] video/hyperv_fb: Avoid taking busy spinlock on panic path Guilherme G. Piccoli
2022-09-18 14:12 ` Guilherme G. Piccoli
2022-10-04 16:17 ` Michael Kelley (LINUX)
2022-08-19 22:17 ` [PATCH V3 10/11] drivers/hv/vmbus, video/hyperv_fb: Untangle and refactor Hyper-V panic notifiers Guilherme G. Piccoli
2022-10-04 16:24 ` Michael Kelley (LINUX)
2022-10-04 17:20 ` Guilherme G. Piccoli
2022-10-17 15:26 ` Michael Kelley (LINUX)
2022-11-10 21:32 ` Guilherme G. Piccoli
2022-11-11 22:47 ` Wei Liu
2022-11-11 23:16 ` Wei Liu
2022-11-12 21:53 ` Guilherme G. Piccoli
2022-08-19 22:17 ` [PATCH V3 11/11] panic: Fixes the panic_print NMI backtrace setting Guilherme G. Piccoli
2022-09-18 14:13 ` Guilherme G. Piccoli
2022-11-22 13:35 ` Guilherme G. Piccoli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a25cb242-7c85-867c-8a61-f3119458dcdb@igalia.com \
--to=gpiccoli@igalia.com \
--cc=akpm@linux-foundation.org \
--cc=alejandro.j.jimenez@oracle.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=arnd@arndb.de \
--cc=bhe@redhat.com \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=corbet@lwn.net \
--cc=d.hatayama@jp.fujitsu.com \
--cc=dave.hansen@linux.intel.com \
--cc=dyoung@redhat.com \
--cc=fabiomirmar@gmail.com \
--cc=feng.tang@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=halves@canonical.com \
--cc=hidehiro.kawai.ez@hitachi.com \
--cc=jgross@suse.com \
--cc=john.ogness@linutronix.de \
--cc=keescook@chromium.org \
--cc=kernel-dev@igalia.com \
--cc=kernel@gpiccoli.net \
--cc=kexec@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=luto@kernel.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=mhiramat@kernel.org \
--cc=mikelley@microsoft.com \
--cc=mingo@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.org \
--cc=stern@rowland.harvard.edu \
--cc=tglx@linutronix.de \
--cc=vgoyal@redhat.com \
--cc=vkuznets@redhat.com \
--cc=will@kernel.org \
--cc=x86@kernel.org \
--cc=xuqiang36@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).