From: James Morse <james.morse@arm.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Rafael Wysocki <rjw@rjwysocki.net>,
Tony Luck <tony.luck@intel.com>, Fan Wu <wufan@codeaurora.org>,
linux-mm@kvack.org, Marc Zyngier <marc.zyngier@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Xie XiuQi <xiexiuqi@huawei.com>,
Will Deacon <will.deacon@arm.com>,
Christoffer Dall <christoffer.dall@arm.com>,
Dongjiu Geng <gengdongjiu@huawei.com>,
linux-acpi@vger.kernel.org,
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org, Len Brown <lenb@kernel.org>
Subject: Re: [PATCH v7 22/25] ACPI / APEI: Kick the memory_failure() queue for synchronous errors
Date: Wed, 23 Jan 2019 18:40:08 +0000 [thread overview]
Message-ID: <58053f17-5f03-8408-7252-a38ed3d448a9@arm.com> (raw)
In-Reply-To: <20190121175850.GO29166@zn.tnic>
Hi Boris,
On 21/01/2019 17:58, Borislav Petkov wrote:
> On Mon, Dec 03, 2018 at 06:06:10PM +0000, James Morse wrote:
>> memory_failure() offlines or repairs pages of memory that have been
>> discovered to be corrupt. These may be detected by an external
>> component, (e.g. the memory controller), and notified via an IRQ.
>> In this case the work is queued as not all of memory_failure()s work
>> can happen in IRQ context.
>>
>> If the error was detected as a result of user-space accessing a
>> corrupt memory location the CPU may take an abort instead. On arm64
>> this is a 'synchronous external abort', and on a firmware first
>> system it is replayed using NOTIFY_SEA.
>>
>> This notification has NMI like properties, (it can interrupt
>> IRQ-masked code), so the memory_failure() work is queued. If we
>> return to user-space before the queued memory_failure() work is
>> processed, we will take the fault again. This loop may cause platform
>> firmware to exceed some threshold and reboot when Linux could have
>> recovered from this error.
>>
>> If a ghes notification type indicates that it may be triggered again
>> when we return to user-space, use the task-work and notify-resume
>> hooks to kick the relevant memory_failure() queue before returning
>> to user-space.
>> ---
>> I assume that if NOTIFY_NMI is coming from SMM it must suffer from
>> this problem too.
>
> Good question.
>
> I'm guessing all those things should be queued on a normal struct
> work_struct queue, no?
ghes_notify_nmi() does this today with its:
| irq_work_queue(&ghes_proc_irq_work);
Once its in IRQ context, the irq_work pokes memory_failure_queue(), which
schedule_work_on()s.
Finally we schedule() in process context, and can unmap the affected memory.
The problem is between each of these steps we might return to user-space and run
the instruction that tripped all this to begin with.
My SMM comment was because the CPU must jump from user-space->SMM, which injects
an NMI into the kernel. The kernel's EIP must point into user-space, so
returning from the NMI without doing the memory_failure() work puts us back the
same position we started in.
> Now, memory_failure_queue() does that and can run from IRQ context so
> you need only an irq_work which can queue from NMI context. We do it
> this way in the MCA code:
>
(was there something missing here?)
> We queue in an irq_work in NMI context and work through the items in
> process context.
How are you getting from NMI to process context in one go?
This patch causes the IRQ->process transition.
The arch specific bit of this gives the irq work queue a kick if returning from
the NMI would unmask IRQs. This makes it look like we moved from NMI to IRQ
context without returning to user-space.
Once ghes_handle_memory_failure() runs in IRQ context, it task_work_add()s the
call to ghes_kick_memory_failure().
Finally on the way out of the kernel to user-space that task_work runs and the
memory_failure() work happens in process context.
During all this the user-space program counter can point at a poisoned location,
but we don't return there until the memory_failure() work has been done.
>> @@ -407,7 +447,22 @@ static void ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata, int
>>
>> if (flags != -1)
>> memory_failure_queue(pfn, flags);
>> -#endif
>> +
>> + /*
>> + * If the notification indicates that it was the interrupted
>> + * instruction that caused the error, try to kick the
>> + * memory_failure() queue before returning to user-space.
>> + */
>> + if (ghes_is_synchronous(ghes) && current->mm != &init_mm) {
>> + callback = kzalloc(sizeof(*callback), GFP_ATOMIC);
>
> Can we avoid that GFP_ATOMIC allocation and kfree() in
> ghes_kick_memory_failure()?
>
> I mean, that struct ghes_memory_failure_work is small enough and we
> already do lockless allocation:
>
> estatus_node = (void *)gen_pool_alloc(ghes_estatus_pool, node_len);
>
> so I guess we could add that ghes_memory_failure_work struct to that
> estatus_node, hand it into ghes_do_proc() and then free it.
I forget estatus_node is a linux thing, not an ACPI-spec thing!
Hmmm, ghes_handle_memory_failure() runs for POLLED and irq error sources too,
they don't have an estatus_node. We don't care about this ret_to_user() problem
as they are all asynchronous, this is why we have ghes_is_synchronous()...
It feels like there should be a way to do this, let me have a go...
Thanks,
James
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-01-23 18:40 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-03 18:05 [PATCH v7 00/25] APEI in_nmi() rework and SDEI wire-up James Morse
2018-12-03 18:05 ` [PATCH v7 01/25] ACPI / APEI: Don't wait to serialise with oops messages when panic()ing James Morse
2018-12-03 18:05 ` [PATCH v7 02/25] ACPI / APEI: Remove silent flag from ghes_read_estatus() James Morse
2018-12-04 11:36 ` Borislav Petkov
2018-12-03 18:05 ` [PATCH v7 03/25] ACPI / APEI: Switch estatus pool to use vmalloc memory James Morse
2018-12-04 13:01 ` Borislav Petkov
2018-12-03 18:05 ` [PATCH v7 04/25] ACPI / APEI: Make hest.c manage the estatus memory pool James Morse
2018-12-11 16:48 ` Borislav Petkov
2018-12-14 13:56 ` James Morse
2018-12-19 14:42 ` Borislav Petkov
2019-01-10 18:20 ` James Morse
2018-12-03 18:05 ` [PATCH v7 05/25] ACPI / APEI: Make estatus pool allocation a static size James Morse
2018-12-11 16:54 ` Borislav Petkov
2018-12-03 18:05 ` [PATCH v7 06/25] ACPI / APEI: Don't store CPER records physical address in struct ghes James Morse
2018-12-11 17:04 ` Borislav Petkov
2018-12-03 18:05 ` [PATCH v7 07/25] ACPI / APEI: Remove spurious GHES_TO_CLEAR check James Morse
2018-12-11 17:18 ` Borislav Petkov
2018-12-03 18:05 ` [PATCH v7 08/25] ACPI / APEI: Don't update struct ghes' flags in read/clear estatus James Morse
2018-12-03 18:05 ` [PATCH v7 09/25] ACPI / APEI: Generalise the estatus queue's notify code James Morse
2018-12-11 17:44 ` Borislav Petkov
2019-01-10 18:21 ` James Morse
2019-01-11 11:46 ` Borislav Petkov
2018-12-03 18:05 ` [PATCH v7 10/25] ACPI / APEI: Tell firmware the estatus queue consumed the records James Morse
2018-12-11 18:36 ` Borislav Petkov
2019-01-10 18:22 ` James Morse
2019-01-10 21:01 ` Tyler Baicar
2019-01-11 12:03 ` Borislav Petkov
2019-01-11 15:32 ` Tyler Baicar
2019-01-11 17:45 ` Borislav Petkov
2019-01-11 18:25 ` James Morse
2019-01-11 19:58 ` Borislav Petkov
2019-01-23 18:36 ` James Morse
2019-01-29 11:49 ` Borislav Petkov
2019-01-29 18:48 ` James Morse
2019-01-31 13:29 ` Borislav Petkov
2019-01-11 18:09 ` James Morse
2019-01-11 20:01 ` Borislav Petkov
2019-01-11 20:53 ` Tyler Baicar
2019-01-29 18:48 ` James Morse
2018-12-03 18:05 ` [PATCH v7 11/25] ACPI / APEI: Move NOTIFY_SEA between the estatus-queue and NOTIFY_NMI James Morse
2019-01-21 13:01 ` Borislav Petkov
2018-12-03 18:06 ` [PATCH v7 12/25] ACPI / APEI: Switch NOTIFY_SEA to use the estatus queue James Morse
2018-12-03 18:06 ` [PATCH v7 13/25] KVM: arm/arm64: Add kvm_ras.h to collect kvm specific RAS plumbing James Morse
2018-12-06 16:17 ` Catalin Marinas
2018-12-03 18:06 ` [PATCH v7 14/25] arm64: KVM/mm: Move SEA handling behind a single 'claim' interface James Morse
2018-12-06 16:17 ` Catalin Marinas
2018-12-03 18:06 ` [PATCH v7 15/25] ACPI / APEI: Move locking to the notification helper James Morse
2018-12-03 18:06 ` [PATCH v7 16/25] ACPI / APEI: Let the notification helper specify the fixmap slot James Morse
2018-12-03 18:06 ` [PATCH v7 17/25] ACPI / APEI: Pass ghes and estatus separately to avoid a later copy James Morse
2019-01-21 13:35 ` Borislav Petkov
2018-12-03 18:06 ` [PATCH v7 18/25] ACPI / APEI: Split ghes_read_estatus() to allow a peek at the CPER length James Morse
2019-01-21 13:53 ` Borislav Petkov
2018-12-03 18:06 ` [PATCH v7 19/25] ACPI / APEI: Only use queued estatus entry during _in_nmi_notify_one() James Morse
2019-01-21 17:19 ` Borislav Petkov
2018-12-03 18:06 ` [PATCH v7 20/25] ACPI / APEI: Use separate fixmap pages for arm64 NMI-like notifications James Morse
2019-01-21 17:27 ` Borislav Petkov
2019-01-23 18:33 ` James Morse
2019-01-31 13:38 ` Borislav Petkov
2018-12-03 18:06 ` [PATCH v7 21/25] mm/memory-failure: Add memory_failure_queue_kick() James Morse
2018-12-03 18:06 ` [PATCH v7 22/25] ACPI / APEI: Kick the memory_failure() queue for synchronous errors James Morse
2018-12-05 2:02 ` Xie XiuQi
2018-12-10 19:15 ` James Morse
2019-01-22 10:51 ` Borislav Petkov
2019-01-23 18:37 ` James Morse
2019-01-21 17:58 ` Borislav Petkov
2019-01-23 18:40 ` James Morse [this message]
2019-01-31 14:04 ` Borislav Petkov
2018-12-03 18:06 ` [PATCH v7 23/25] arm64: acpi: Make apei_claim_sea() synchronise with APEI's irq work James Morse
2018-12-06 16:18 ` Catalin Marinas
2018-12-03 18:06 ` [PATCH v7 24/25] firmware: arm_sdei: Add ACPI GHES registration helper James Morse
2018-12-06 16:18 ` Catalin Marinas
2018-12-03 18:06 ` [PATCH v7 25/25] ACPI / APEI: Add support for the SDEI GHES Notification type 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:
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=58053f17-5f03-8408-7252-a38ed3d448a9@arm.com \
--to=james.morse@arm.com \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=christoffer.dall@arm.com \
--cc=gengdongjiu@huawei.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=marc.zyngier@arm.com \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=rjw@rjwysocki.net \
--cc=tony.luck@intel.com \
--cc=will.deacon@arm.com \
--cc=wufan@codeaurora.org \
--cc=xiexiuqi@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).