LKML Archive on
help / color / mirror / Atom feed
From: James Morse <>
To: Mark Rutland <>,
	Dongjiu Geng <>
Subject: Re: [PATCH v1 2/2] arm64: handle NOTIFY_SEI notification by the APEI driver
Date: Thu, 31 May 2018 17:51:31 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hi Mark, Dongjiu Geng,

On 31/05/18 12:01, Mark Rutland wrote:
> In do_serror() we already handle nmi_{enter,exit}(), so there's no need
> for that here.

Even better: nmi_enter() has a BUG_ON(in_nmi()).

> TBH, I don't understand why do_sea() does that conditionally today.
> Unless there's some constraint I'm missing, 

APEI uses a different fixmap entry and locks when in_nmi(). This was because we
may interrupt the irq-masked region in APEI that was using the regular memory.
(e.g. the 'polled' notification, or something backed by an interrupt.) But,
Borislav has spotted other things in here that are broken[0]. I'm working on
rolling all that into 'v5' of the in_nmi() rework stuff.

We currently get away with this on arm because 'SEA' is the only NMI-like thing,
and it occurs synchronously. The problem cases are all also cases where the
kernel text is corrupt, which we can't possibly hope to handle.

For NOTIFY_SDEI and NOTIFY_SEI this is the wrong pattern as these are
asynchronous. do_serror() has already done most of the work for NOTIFY_SEI, but
we need to use the estatus queue in APEI, which is currently x86 only.

> I think it would make more
> sense to do that regardless of whether the interrupted context had
> interrupts enabled. James -- does that make sense to you?
> If you update the prior patch with a stub for !CONFIG_ACPI_APEI_SEI, you
> can simplify all of the above additions down to:
> 	if (!ghes_notify_sei())
> 		return;
> ... which would look a lot nicer.

The code that calls ghes_notify_sei() may need calling by KVM too, but its
default action to an 'unclaimed' SError will be different.
Because of the race between memory_failure() and return-to-userspace, we may
need to kick the irq work queue (if we can), as we return from do_serror(). [1]
and [2] provide an example for NOTIFY_SEA. SDEI does this by returning to the
kernel through the IRQ handler, (which handles the KVM case too).

I think this series is unsafe until we can use the estatus queue in APEI. Its
also missing the handling for an SError interrupting a KVM guest.




  reply	other threads:[~2018-05-31 16:54 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-31 12:41 [PATCH v1 0/2] Add NOTIFY_SEI notification type support Dongjiu Geng
2018-05-31 12:41 ` [PATCH v1 1/2] ACPI / APEI: Add SEI notification type support for ARMv8 Dongjiu Geng
2018-05-31 10:52   ` Mark Rutland
2018-06-01 10:07     ` gengdongjiu
2018-05-31 12:41 ` [PATCH v1 2/2] arm64: handle NOTIFY_SEI notification by the APEI driver Dongjiu Geng
2018-05-31 11:01   ` Mark Rutland
2018-05-31 16:51     ` James Morse [this message]
2018-06-01  7:21       ` gengdongjiu
2018-06-15 16:49         ` James Morse

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH v1 2/2] arm64: handle NOTIFY_SEI notification by the APEI driver' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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