All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
Cc: 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>,
	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: Mon, 17 Oct 2022 15:17:35 +0100	[thread overview]
Message-ID: <Y01j/3qKUvj346AH@shell.armlinux.org.uk> (raw)
In-Reply-To: <8e30b99e-70ed-7d5a-ea1f-3b0fadb644bc@igalia.com>

On Mon, Oct 17, 2022 at 11:00:46AM -0300, Guilherme G. Piccoli wrote:
> 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@kernel.org>
> >> Cc: Michael Kelley <mikelley@microsoft.com>
> >> Cc: Russell King <linux@armlinux.org.uk>
> >> Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
> >>
> 
> Monthly ping - let me know if there's something I should improve in
> order this fix is considered!

Patches don't get applied unless they end up in the patch system.
Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
Cc: 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>,
	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: Mon, 17 Oct 2022 15:17:35 +0100	[thread overview]
Message-ID: <Y01j/3qKUvj346AH@shell.armlinux.org.uk> (raw)
In-Reply-To: <8e30b99e-70ed-7d5a-ea1f-3b0fadb644bc@igalia.com>

On Mon, Oct 17, 2022 at 11:00:46AM -0300, Guilherme G. Piccoli wrote:
> 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@kernel.org>
> >> Cc: Michael Kelley <mikelley@microsoft.com>
> >> Cc: Russell King <linux@armlinux.org.uk>
> >> Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
> >>
> 
> Monthly ping - let me know if there's something I should improve in
> order this fix is considered!

Patches don't get applied unless they end up in the patch system.
Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

WARNING: multiple messages have this Message-ID (diff)
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
Cc: 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>,
	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: Mon, 17 Oct 2022 15:17:35 +0100	[thread overview]
Message-ID: <Y01j/3qKUvj346AH@shell.armlinux.org.uk> (raw)
In-Reply-To: <8e30b99e-70ed-7d5a-ea1f-3b0fadb644bc@igalia.com>

On Mon, Oct 17, 2022 at 11:00:46AM -0300, Guilherme G. Piccoli wrote:
> 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@kernel.org>
> >> Cc: Michael Kelley <mikelley@microsoft.com>
> >> Cc: Russell King <linux@armlinux.org.uk>
> >> Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
> >>
> 
> Monthly ping - let me know if there's something I should improve in
> order this fix is considered!

Patches don't get applied unless they end up in the patch system.
Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-10-21 13:54 UTC|newest]

Thread overview: 128+ 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 ` Guilherme G. Piccoli
2022-08-19 22:17 ` Guilherme G. Piccoli
2022-08-19 22:17 ` Guilherme G. Piccoli
2022-08-19 22:17 ` 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-08-19 22:17   ` Guilherme G. Piccoli
2022-08-19 22:17   ` Guilherme G. Piccoli
2022-09-18 13:58   ` Guilherme G. Piccoli
2022-09-18 13:58     ` Guilherme G. Piccoli
2022-09-18 13:58     ` Guilherme G. Piccoli
2022-10-17 14:00     ` Guilherme G. Piccoli
2022-10-17 14:00       ` Guilherme G. Piccoli
2022-10-17 14:00       ` Guilherme G. Piccoli
2022-10-17 14:17       ` Russell King (Oracle) [this message]
2022-10-17 14:17         ` Russell King (Oracle)
2022-10-17 14:17         ` Russell King (Oracle)
2022-10-17 14:50         ` Guilherme G. Piccoli
2022-10-17 14:50           ` Guilherme G. Piccoli
2022-10-17 14:50           ` Guilherme G. Piccoli
2022-10-17 17:47           ` Russell King (Oracle)
2022-10-17 17:47             ` Russell King (Oracle)
2022-10-17 17:47             ` Russell King (Oracle)
2022-10-17 19:43             ` Guilherme G. Piccoli
2022-10-17 19:43               ` Guilherme G. Piccoli
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-08-19 22:17   ` Guilherme G. Piccoli
2022-11-22 13:19   ` 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-08-19 22:17   ` Guilherme G. Piccoli
2022-08-19 22:17   ` Guilherme G. Piccoli
2022-11-22 13:22   ` Guilherme G. Piccoli
2022-11-22 13:22     ` 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-08-19 22:17   ` Guilherme G. Piccoli
2022-08-19 22:17   ` Guilherme G. Piccoli
2022-09-18 14:00   ` Guilherme G. Piccoli
2022-09-18 14:00     ` Guilherme G. Piccoli
2022-09-18 14:00     ` Guilherme G. Piccoli
2022-09-18 21:19     ` Richard Weinberger
2022-09-18 21:19       ` Richard Weinberger
2022-09-18 21:19       ` Richard Weinberger
2022-09-19 11:44       ` Guilherme G. Piccoli
2022-09-19 11:44         ` Guilherme G. Piccoli
2022-09-19 11:44         ` Guilherme G. Piccoli
2022-10-17 14:01       ` Guilherme G. Piccoli
2022-10-17 14:01         ` Guilherme G. Piccoli
2022-10-17 14:10         ` Richard Weinberger
2022-10-17 14:10           ` Richard Weinberger
2022-10-17 14:22           ` Guilherme G. Piccoli
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   ` Guilherme G. Piccoli
2022-08-19 22:17 ` [PATCH V3 06/11] tracing: Improve panic/die notifiers Guilherme G. Piccoli
2022-08-19 22:17   ` Guilherme G. Piccoli
2022-09-18 14:04   ` Guilherme G. Piccoli
2022-09-18 14:04     ` Guilherme G. Piccoli
2022-10-17 14:02   ` Guilherme G. Piccoli
2022-10-17 14:02     ` Guilherme G. Piccoli
2022-10-20 21:29   ` Steven Rostedt
2022-10-20 21:29     ` Steven Rostedt
2022-10-20 21:53     ` Guilherme G. Piccoli
2022-10-20 21:53       ` Guilherme G. Piccoli
2022-10-20 22:22       ` Steven Rostedt
2022-10-20 22:22         ` Steven Rostedt
2022-10-20 22:37         ` Guilherme G. Piccoli
2022-10-20 22:37           ` Guilherme G. Piccoli
2022-11-22 13:27         ` Guilherme G. Piccoli
2022-11-22 13:27           ` Guilherme G. Piccoli
2022-12-13 23:51     ` Guilherme G. Piccoli
2022-12-13 23:51       ` Guilherme G. Piccoli
2022-12-14  0:06       ` Steven Rostedt
2022-12-14  0:06         ` Steven Rostedt
2022-12-14  0:52         ` Guilherme G. Piccoli
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-08-19 22:17   ` Guilherme G. Piccoli
2022-09-18 14:07   ` Guilherme G. Piccoli
2022-09-18 14:07     ` Guilherme G. Piccoli
2022-10-17 14:04   ` Guilherme G. Piccoli
2022-10-17 14:04     ` Guilherme G. Piccoli
2022-11-22 13:30   ` 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-08-19 22:17   ` Guilherme G. Piccoli
2022-09-18 14:10   ` Guilherme G. Piccoli
2022-09-18 14:10     ` Guilherme G. Piccoli
2022-10-17 14:05     ` Guilherme G. Piccoli
2022-10-17 14:05       ` Guilherme G. Piccoli
2022-11-22 13:33     ` Guilherme G. Piccoli
2022-11-22 13:33       ` Guilherme G. Piccoli
2022-11-22 15:06       ` Borislav Petkov
2022-11-22 15:06         ` Borislav Petkov
2023-02-10 16:01         ` Guilherme G. Piccoli
2023-02-10 16:01           ` Guilherme G. Piccoli
2022-12-09 16:03   ` Petr Mladek
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-08-19 22:17   ` Guilherme G. Piccoli
2022-09-18 14:12   ` Guilherme G. Piccoli
2022-09-18 14:12     ` Guilherme G. Piccoli
2022-10-04 16:17   ` Michael Kelley (LINUX)
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-08-19 22:17   ` Guilherme G. Piccoli
2022-10-04 16:24   ` Michael Kelley (LINUX)
2022-10-04 16:24     ` Michael Kelley (LINUX)
2022-10-04 17:20     ` Guilherme G. Piccoli
2022-10-04 17:20       ` Guilherme G. Piccoli
2022-10-17 15:26       ` Michael Kelley (LINUX)
2022-10-17 15:26         ` Michael Kelley (LINUX)
2022-11-10 21:32         ` Guilherme G. Piccoli
2022-11-10 21:32           ` Guilherme G. Piccoli
2022-11-11 22:47           ` Wei Liu
2022-11-11 22:47             ` Wei Liu
2022-11-11 23:16             ` Wei Liu
2022-11-11 23:16               ` Wei Liu
2022-11-12 21:53               ` Guilherme G. Piccoli
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-08-19 22:17   ` Guilherme G. Piccoli
2022-09-18 14:13   ` Guilherme G. Piccoli
2022-09-18 14:13     ` Guilherme G. Piccoli
2022-11-22 13:35   ` 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=Y01j/3qKUvj346AH@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --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=gpiccoli@igalia.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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.