* [PATCH 00/11] APEI in_nmi() rework and arm64 SDEI wire-up
@ 2018-02-15 18:55 ` James Morse
0 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-02-15 18:55 UTC (permalink / raw)
To: linux-acpi
Cc: kvmarm, linux-arm-kernel, linux-mm, Borislav Petkov,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
Naoya Horiguchi, Rafael Wysocki, Len Brown, Tony Luck,
Tyler Baicar, Dongjiu Geng, Xie XiuQi, Punit Agrawal,
James Morse
Hello!
The aim of this series is to wire arm64's SDEI into APEI.
What's SDEI? Its ARM's "Software Delegated Exception Interface" [0]. It's
used by firmware to tell the OS about firmware-first RAS events.
These Software exceptions can interrupt anything, so I describe them as
NMI-like. They aren't the only NMI-like way to notify the OS about
firmware-first RAS events, the ACPI spec also defines 'NOTFIY_SEA' and
'NOTIFY_SEI'.
(Acronyms: SEA, Synchronous External Abort. The CPU requested some memory,
but the owner of that memory said no. These are always synchronous with the
instruction that caused them. SEI, System-Error Interrupt, commonly called
SError. This is an asynchronous external abort, the memory-owner didn't say no
at the right point. Collectively these things are called external-aborts
How is firmware involved? It traps these and re-injects them into the kernel
once its written the CPER records).
APEI's GHES code only expects one source of NMI. If a platform implements
more than one of these mechanisms, APEI needs to handle the interaction.
'SEA' and 'SEI' can interact as 'SEI' is asynchronous. SDEI can interact
with itself: its exceptions can be 'normal' or 'critical', and firmware
could use both types for RAS. (errors using normal, 'panic-now' using
critical).
What does this series do?
Patches 1-3 refactor APEIs 'estatus queue' so it can be used for all
NMI-like notifications. This defers the NMI work to irq_work, which will
happen when we next unmask interrupts.
Patches 4&5 move the arch and KVM code around so that NMI-like notifications
are always called in_nmi().
Patch 6 splits the 'irq or nmi?' path through ghes_copy_tofrom_phys()
up to be per-ghes. This lets each ghes specify which other error-sources
it can share a fixmap-slot and lock with.
Patch 7 renames NOTIFY_SEA's use of NOTIFY_NMI's infrastructure, as we're
about to have multiple NMI-like users that can't share resources.
Pathes 8&9 add the SDEI helper, and notify methods for APEI.
After this, adding the last firmware-first piece for arm64 is simple
(and safe), and all our NMI-like notifications behave the same as x86's
NOTIFY_NMI.
All of this makes the race between memory_failure_queue() and
ret_to_user worse, as there is now always irq_work involved.
Patch 10 makes the reschedule to memory_failure() run as soon as possible.
Patch 11 makes sure the arch code knows whether the irq_work has run by
the time do_sea() returns. We can skip the signalling step if it has as
APEI has done its work.
ghes.c became clearer to me when I worked out that it has three sets of
functions with 'estatus' in the name. One is a pool of memory that can be
allocated-from atomically. This is grown/shrunk when new NMI users are
allocated.
The second is the estatus-cache, which holds recent notifications so it
can suppress notifications we've already handled.
The last it the estatus-queue, which holds data from NMI-like notifications
(in pool memory) to be processed from irq_work.
Testing?
Tested with the SDEI FVP based software model and a mocked up NOTFIY_SEA using
KVM. I've only build tested this on x86.
Trees... The changes outside APEI are tiny, but there will be some changes
to how arch/arm64/mm/fault.c generates signals, affecting do_sea() that will
cause conflicts with patch 5.
Thanks,
James
[0] http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf
James Morse (11):
ACPI / APEI: Move the estatus queue code up, and under its own ifdef
ACPI / APEI: Generalise the estatus queue's add/remove and notify code
ACPI / APEI: Switch NOTIFY_SEA to use the estatus queue
KVM: arm/arm64: Add kvm_ras.h to collect kvm specific RAS plumbing
arm64: KVM/mm: Move SEA handling behind a single 'claim' interface
ACPI / APEI: Make the fixmap_idx per-ghes to allow multiple in_nmi()
users
ACPI / APEI: Split fixmap pages for arm64 NMI-like notifications
firmware: arm_sdei: Add ACPI GHES registration helper
ACPI / APEI: Add support for the SDEI GHES Notification type
mm/memory-failure: increase queued recovery work's priority
arm64: acpi: Make apei_claim_sea() synchronise with APEI's irq work
arch/arm/include/asm/kvm_ras.h | 14 +
arch/arm/include/asm/system_misc.h | 5 -
arch/arm64/include/asm/acpi.h | 3 +
arch/arm64/include/asm/daifflags.h | 1 +
arch/arm64/include/asm/fixmap.h | 8 +-
arch/arm64/include/asm/kvm_ras.h | 29 ++
arch/arm64/include/asm/system_misc.h | 2 -
arch/arm64/kernel/acpi.c | 49 ++++
arch/arm64/mm/fault.c | 30 +-
drivers/acpi/apei/ghes.c | 533 ++++++++++++++++++++---------------
drivers/firmware/arm_sdei.c | 75 +++++
include/acpi/ghes.h | 5 +
include/linux/arm_sdei.h | 8 +
mm/memory-failure.c | 11 +-
virt/kvm/arm/mmu.c | 4 +-
15 files changed, 517 insertions(+), 260 deletions(-)
create mode 100644 arch/arm/include/asm/kvm_ras.h
create mode 100644 arch/arm64/include/asm/kvm_ras.h
--
2.15.1
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH 00/11] APEI in_nmi() rework and arm64 SDEI wire-up
@ 2018-02-15 18:55 ` James Morse
0 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-02-15 18:55 UTC (permalink / raw)
To: linux-acpi
Cc: kvmarm, linux-arm-kernel, linux-mm, Borislav Petkov,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
Naoya Horiguchi, Rafael Wysocki, Len Brown, Tony Luck,
Tyler Baicar, Dongjiu Geng, Xie XiuQi, Punit Agrawal,
James Morse
Hello!
The aim of this series is to wire arm64's SDEI into APEI.
What's SDEI? Its ARM's "Software Delegated Exception Interface" [0]. It's
used by firmware to tell the OS about firmware-first RAS events.
These Software exceptions can interrupt anything, so I describe them as
NMI-like. They aren't the only NMI-like way to notify the OS about
firmware-first RAS events, the ACPI spec also defines 'NOTFIY_SEA' and
'NOTIFY_SEI'.
(Acronyms: SEA, Synchronous External Abort. The CPU requested some memory,
but the owner of that memory said no. These are always synchronous with the
instruction that caused them. SEI, System-Error Interrupt, commonly called
SError. This is an asynchronous external abort, the memory-owner didn't say no
at the right point. Collectively these things are called external-aborts
How is firmware involved? It traps these and re-injects them into the kernel
once its written the CPER records).
APEI's GHES code only expects one source of NMI. If a platform implements
more than one of these mechanisms, APEI needs to handle the interaction.
'SEA' and 'SEI' can interact as 'SEI' is asynchronous. SDEI can interact
with itself: its exceptions can be 'normal' or 'critical', and firmware
could use both types for RAS. (errors using normal, 'panic-now' using
critical).
What does this series do?
Patches 1-3 refactor APEIs 'estatus queue' so it can be used for all
NMI-like notifications. This defers the NMI work to irq_work, which will
happen when we next unmask interrupts.
Patches 4&5 move the arch and KVM code around so that NMI-like notifications
are always called in_nmi().
Patch 6 splits the 'irq or nmi?' path through ghes_copy_tofrom_phys()
up to be per-ghes. This lets each ghes specify which other error-sources
it can share a fixmap-slot and lock with.
Patch 7 renames NOTIFY_SEA's use of NOTIFY_NMI's infrastructure, as we're
about to have multiple NMI-like users that can't share resources.
Pathes 8&9 add the SDEI helper, and notify methods for APEI.
After this, adding the last firmware-first piece for arm64 is simple
(and safe), and all our NMI-like notifications behave the same as x86's
NOTIFY_NMI.
All of this makes the race between memory_failure_queue() and
ret_to_user worse, as there is now always irq_work involved.
Patch 10 makes the reschedule to memory_failure() run as soon as possible.
Patch 11 makes sure the arch code knows whether the irq_work has run by
the time do_sea() returns. We can skip the signalling step if it has as
APEI has done its work.
ghes.c became clearer to me when I worked out that it has three sets of
functions with 'estatus' in the name. One is a pool of memory that can be
allocated-from atomically. This is grown/shrunk when new NMI users are
allocated.
The second is the estatus-cache, which holds recent notifications so it
can suppress notifications we've already handled.
The last it the estatus-queue, which holds data from NMI-like notifications
(in pool memory) to be processed from irq_work.
Testing?
Tested with the SDEI FVP based software model and a mocked up NOTFIY_SEA using
KVM. I've only build tested this on x86.
Trees... The changes outside APEI are tiny, but there will be some changes
to how arch/arm64/mm/fault.c generates signals, affecting do_sea() that will
cause conflicts with patch 5.
Thanks,
James
[0] http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf
James Morse (11):
ACPI / APEI: Move the estatus queue code up, and under its own ifdef
ACPI / APEI: Generalise the estatus queue's add/remove and notify code
ACPI / APEI: Switch NOTIFY_SEA to use the estatus queue
KVM: arm/arm64: Add kvm_ras.h to collect kvm specific RAS plumbing
arm64: KVM/mm: Move SEA handling behind a single 'claim' interface
ACPI / APEI: Make the fixmap_idx per-ghes to allow multiple in_nmi()
users
ACPI / APEI: Split fixmap pages for arm64 NMI-like notifications
firmware: arm_sdei: Add ACPI GHES registration helper
ACPI / APEI: Add support for the SDEI GHES Notification type
mm/memory-failure: increase queued recovery work's priority
arm64: acpi: Make apei_claim_sea() synchronise with APEI's irq work
arch/arm/include/asm/kvm_ras.h | 14 +
arch/arm/include/asm/system_misc.h | 5 -
arch/arm64/include/asm/acpi.h | 3 +
arch/arm64/include/asm/daifflags.h | 1 +
arch/arm64/include/asm/fixmap.h | 8 +-
arch/arm64/include/asm/kvm_ras.h | 29 ++
arch/arm64/include/asm/system_misc.h | 2 -
arch/arm64/kernel/acpi.c | 49 ++++
arch/arm64/mm/fault.c | 30 +-
drivers/acpi/apei/ghes.c | 533 ++++++++++++++++++++---------------
drivers/firmware/arm_sdei.c | 75 +++++
include/acpi/ghes.h | 5 +
include/linux/arm_sdei.h | 8 +
mm/memory-failure.c | 11 +-
virt/kvm/arm/mmu.c | 4 +-
15 files changed, 517 insertions(+), 260 deletions(-)
create mode 100644 arch/arm/include/asm/kvm_ras.h
create mode 100644 arch/arm64/include/asm/kvm_ras.h
--
2.15.1
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH 00/11] APEI in_nmi() rework and arm64 SDEI wire-up
@ 2018-02-15 18:55 ` James Morse
0 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-02-15 18:55 UTC (permalink / raw)
To: linux-arm-kernel
Hello!
The aim of this series is to wire arm64's SDEI into APEI.
What's SDEI? Its ARM's "Software Delegated Exception Interface" [0]. It's
used by firmware to tell the OS about firmware-first RAS events.
These Software exceptions can interrupt anything, so I describe them as
NMI-like. They aren't the only NMI-like way to notify the OS about
firmware-first RAS events, the ACPI spec also defines 'NOTFIY_SEA' and
'NOTIFY_SEI'.
(Acronyms: SEA, Synchronous External Abort. The CPU requested some memory,
but the owner of that memory said no. These are always synchronous with the
instruction that caused them. SEI, System-Error Interrupt, commonly called
SError. This is an asynchronous external abort, the memory-owner didn't say no
at the right point. Collectively these things are called external-aborts
How is firmware involved? It traps these and re-injects them into the kernel
once its written the CPER records).
APEI's GHES code only expects one source of NMI. If a platform implements
more than one of these mechanisms, APEI needs to handle the interaction.
'SEA' and 'SEI' can interact as 'SEI' is asynchronous. SDEI can interact
with itself: its exceptions can be 'normal' or 'critical', and firmware
could use both types for RAS. (errors using normal, 'panic-now' using
critical).
What does this series do?
Patches 1-3 refactor APEIs 'estatus queue' so it can be used for all
NMI-like notifications. This defers the NMI work to irq_work, which will
happen when we next unmask interrupts.
Patches 4&5 move the arch and KVM code around so that NMI-like notifications
are always called in_nmi().
Patch 6 splits the 'irq or nmi?' path through ghes_copy_tofrom_phys()
up to be per-ghes. This lets each ghes specify which other error-sources
it can share a fixmap-slot and lock with.
Patch 7 renames NOTIFY_SEA's use of NOTIFY_NMI's infrastructure, as we're
about to have multiple NMI-like users that can't share resources.
Pathes 8&9 add the SDEI helper, and notify methods for APEI.
After this, adding the last firmware-first piece for arm64 is simple
(and safe), and all our NMI-like notifications behave the same as x86's
NOTIFY_NMI.
All of this makes the race between memory_failure_queue() and
ret_to_user worse, as there is now always irq_work involved.
Patch 10 makes the reschedule to memory_failure() run as soon as possible.
Patch 11 makes sure the arch code knows whether the irq_work has run by
the time do_sea() returns. We can skip the signalling step if it has as
APEI has done its work.
ghes.c became clearer to me when I worked out that it has three sets of
functions with 'estatus' in the name. One is a pool of memory that can be
allocated-from atomically. This is grown/shrunk when new NMI users are
allocated.
The second is the estatus-cache, which holds recent notifications so it
can suppress notifications we've already handled.
The last it the estatus-queue, which holds data from NMI-like notifications
(in pool memory) to be processed from irq_work.
Testing?
Tested with the SDEI FVP based software model and a mocked up NOTFIY_SEA using
KVM. I've only build tested this on x86.
Trees... The changes outside APEI are tiny, but there will be some changes
to how arch/arm64/mm/fault.c generates signals, affecting do_sea() that will
cause conflicts with patch 5.
Thanks,
James
[0] http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf
James Morse (11):
ACPI / APEI: Move the estatus queue code up, and under its own ifdef
ACPI / APEI: Generalise the estatus queue's add/remove and notify code
ACPI / APEI: Switch NOTIFY_SEA to use the estatus queue
KVM: arm/arm64: Add kvm_ras.h to collect kvm specific RAS plumbing
arm64: KVM/mm: Move SEA handling behind a single 'claim' interface
ACPI / APEI: Make the fixmap_idx per-ghes to allow multiple in_nmi()
users
ACPI / APEI: Split fixmap pages for arm64 NMI-like notifications
firmware: arm_sdei: Add ACPI GHES registration helper
ACPI / APEI: Add support for the SDEI GHES Notification type
mm/memory-failure: increase queued recovery work's priority
arm64: acpi: Make apei_claim_sea() synchronise with APEI's irq work
arch/arm/include/asm/kvm_ras.h | 14 +
arch/arm/include/asm/system_misc.h | 5 -
arch/arm64/include/asm/acpi.h | 3 +
arch/arm64/include/asm/daifflags.h | 1 +
arch/arm64/include/asm/fixmap.h | 8 +-
arch/arm64/include/asm/kvm_ras.h | 29 ++
arch/arm64/include/asm/system_misc.h | 2 -
arch/arm64/kernel/acpi.c | 49 ++++
arch/arm64/mm/fault.c | 30 +-
drivers/acpi/apei/ghes.c | 533 ++++++++++++++++++++---------------
drivers/firmware/arm_sdei.c | 75 +++++
include/acpi/ghes.h | 5 +
include/linux/arm_sdei.h | 8 +
mm/memory-failure.c | 11 +-
virt/kvm/arm/mmu.c | 4 +-
15 files changed, 517 insertions(+), 260 deletions(-)
create mode 100644 arch/arm/include/asm/kvm_ras.h
create mode 100644 arch/arm64/include/asm/kvm_ras.h
--
2.15.1
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH 01/11] ACPI / APEI: Move the estatus queue code up, and under its own ifdef
2018-02-15 18:55 ` James Morse
(?)
@ 2018-02-15 18:55 ` James Morse
-1 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-02-15 18:55 UTC (permalink / raw)
To: linux-acpi
Cc: kvmarm, linux-arm-kernel, linux-mm, Borislav Petkov,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
Naoya Horiguchi, Rafael Wysocki, Len Brown, Tony Luck,
Tyler Baicar, Dongjiu Geng, Xie XiuQi, Punit Agrawal,
James Morse
To support asynchronous NMI-like notifications on arm64 we need to use
the estatus-queue. These patches refactor it to allow multiple APEI
notification types to use it.
First we move the estatus-queue code higher in the file so that any
notify_foo() handler can make user of it.
This patch moves code around ... and makes the following trivial change:
Freshen the dated comment above ghes_estatus_llist. printk() is no
longer the issue, its the helpers like memory_failure_queue() that
still aren't nmi safe.
Signed-off-by: James Morse <james.morse@arm.com>
---
drivers/acpi/apei/ghes.c | 267 ++++++++++++++++++++++++-----------------------
1 file changed, 139 insertions(+), 128 deletions(-)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 1efefe919555..e42b587c509b 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -545,6 +545,16 @@ static int ghes_print_estatus(const char *pfx,
return 0;
}
+static void __ghes_panic(struct ghes *ghes)
+{
+ __ghes_print_estatus(KERN_EMERG, ghes->generic, ghes->estatus);
+
+ /* reboot to log the error! */
+ if (!panic_timeout)
+ panic_timeout = ghes_panic_timeout;
+ panic("Fatal hardware error!");
+}
+
/*
* GHES error status reporting throttle, to report more kinds of
* errors, instead of just most frequently occurred errors.
@@ -672,6 +682,135 @@ static void ghes_estatus_cache_add(
rcu_read_unlock();
}
+#ifdef CONFIG_HAVE_ACPI_APEI_NMI
+/*
+ * While printk() now has an in_nmi() path, the handling for CPER records
+ * does not. For example, memory_failure_queue() takes spinlocks and calls
+ * schedule_work_on().
+ *
+ * So in any NMI-like handler, we allocate required memory from lock-less
+ * memory allocator (ghes_estatus_pool), save estatus into it, put them into
+ * lock-less list (ghes_estatus_llist), then delay printk into IRQ context via
+ * irq_work (ghes_proc_irq_work). ghes_estatus_size_request record
+ * required pool size by all NMI error source.
+ *
+ * Memory from the ghes_estatus_pool is also used with the ghes_estatus_cache
+ * to suppress frequent messages.
+ */
+static struct llist_head ghes_estatus_llist;
+static struct irq_work ghes_proc_irq_work;
+
+static void ghes_print_queued_estatus(void)
+{
+ struct llist_node *llnode;
+ struct ghes_estatus_node *estatus_node;
+ struct acpi_hest_generic *generic;
+ struct acpi_hest_generic_status *estatus;
+
+ llnode = llist_del_all(&ghes_estatus_llist);
+ /*
+ * Because the time order of estatus in list is reversed,
+ * revert it back to proper order.
+ */
+ llnode = llist_reverse_order(llnode);
+ while (llnode) {
+ estatus_node = llist_entry(llnode, struct ghes_estatus_node,
+ llnode);
+ estatus = GHES_ESTATUS_FROM_NODE(estatus_node);
+ generic = estatus_node->generic;
+ ghes_print_estatus(NULL, generic, estatus);
+ llnode = llnode->next;
+ }
+}
+
+/* Save estatus for further processing in IRQ context */
+static void __process_error(struct ghes *ghes)
+{
+#ifdef CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG
+ u32 len, node_len;
+ struct ghes_estatus_node *estatus_node;
+ struct acpi_hest_generic_status *estatus;
+
+ if (ghes_estatus_cached(ghes->estatus))
+ return;
+
+ len = cper_estatus_len(ghes->estatus);
+ node_len = GHES_ESTATUS_NODE_LEN(len);
+
+ estatus_node = (void *)gen_pool_alloc(ghes_estatus_pool, node_len);
+ if (!estatus_node)
+ return;
+
+ estatus_node->ghes = ghes;
+ estatus_node->generic = ghes->generic;
+ estatus = GHES_ESTATUS_FROM_NODE(estatus_node);
+ memcpy(estatus, ghes->estatus, len);
+ llist_add(&estatus_node->llnode, &ghes_estatus_llist);
+#endif
+}
+
+static unsigned long ghes_esource_prealloc_size(
+ const struct acpi_hest_generic *generic)
+{
+ unsigned long block_length, prealloc_records, prealloc_size;
+
+ block_length = min_t(unsigned long, generic->error_block_length,
+ GHES_ESTATUS_MAX_SIZE);
+ prealloc_records = max_t(unsigned long,
+ generic->records_to_preallocate, 1);
+ prealloc_size = min_t(unsigned long, block_length * prealloc_records,
+ GHES_ESOURCE_PREALLOC_MAX_SIZE);
+
+ return prealloc_size;
+}
+
+static void ghes_estatus_pool_shrink(unsigned long len)
+{
+ ghes_estatus_pool_size_request -= PAGE_ALIGN(len);
+}
+
+static void ghes_proc_in_irq(struct irq_work *irq_work)
+{
+ struct llist_node *llnode, *next;
+ struct ghes_estatus_node *estatus_node;
+ struct acpi_hest_generic *generic;
+ struct acpi_hest_generic_status *estatus;
+ u32 len, node_len;
+
+ llnode = llist_del_all(&ghes_estatus_llist);
+ /*
+ * Because the time order of estatus in list is reversed,
+ * revert it back to proper order.
+ */
+ llnode = llist_reverse_order(llnode);
+ while (llnode) {
+ next = llnode->next;
+ estatus_node = llist_entry(llnode, struct ghes_estatus_node,
+ llnode);
+ estatus = GHES_ESTATUS_FROM_NODE(estatus_node);
+ len = cper_estatus_len(estatus);
+ node_len = GHES_ESTATUS_NODE_LEN(len);
+ ghes_do_proc(estatus_node->ghes, estatus);
+ if (!ghes_estatus_cached(estatus)) {
+ generic = estatus_node->generic;
+ if (ghes_print_estatus(NULL, generic, estatus))
+ ghes_estatus_cache_add(generic, estatus);
+ }
+ gen_pool_free(ghes_estatus_pool, (unsigned long)estatus_node,
+ node_len);
+ llnode = next;
+ }
+}
+
+static void ghes_nmi_init_cxt(void)
+{
+ init_irq_work(&ghes_proc_irq_work, ghes_proc_in_irq);
+}
+
+#else
+static inline void ghes_nmi_init_cxt(void) { }
+#endif /* CONFIG_HAVE_ACPI_APEI_NMI */
+
static int ghes_ack_error(struct acpi_hest_generic_v2 *gv2)
{
int rc;
@@ -687,16 +826,6 @@ static int ghes_ack_error(struct acpi_hest_generic_v2 *gv2)
return apei_write(val, &gv2->read_ack_register);
}
-static void __ghes_panic(struct ghes *ghes)
-{
- __ghes_print_estatus(KERN_EMERG, ghes->generic, ghes->estatus);
-
- /* reboot to log the error! */
- if (!panic_timeout)
- panic_timeout = ghes_panic_timeout;
- panic("Fatal hardware error!");
-}
-
static int ghes_proc(struct ghes *ghes)
{
int rc;
@@ -828,17 +957,6 @@ static inline void ghes_sea_remove(struct ghes *ghes) { }
#endif /* CONFIG_ACPI_APEI_SEA */
#ifdef CONFIG_HAVE_ACPI_APEI_NMI
-/*
- * printk is not safe in NMI context. So in NMI handler, we allocate
- * required memory from lock-less memory allocator
- * (ghes_estatus_pool), save estatus into it, put them into lock-less
- * list (ghes_estatus_llist), then delay printk into IRQ context via
- * irq_work (ghes_proc_irq_work). ghes_estatus_size_request record
- * required pool size by all NMI error source.
- */
-static struct llist_head ghes_estatus_llist;
-static struct irq_work ghes_proc_irq_work;
-
/*
* NMI may be triggered on any CPU, so ghes_in_nmi is used for
* having only one concurrent reader.
@@ -847,88 +965,6 @@ static atomic_t ghes_in_nmi = ATOMIC_INIT(0);
static LIST_HEAD(ghes_nmi);
-static void ghes_proc_in_irq(struct irq_work *irq_work)
-{
- struct llist_node *llnode, *next;
- struct ghes_estatus_node *estatus_node;
- struct acpi_hest_generic *generic;
- struct acpi_hest_generic_status *estatus;
- u32 len, node_len;
-
- llnode = llist_del_all(&ghes_estatus_llist);
- /*
- * Because the time order of estatus in list is reversed,
- * revert it back to proper order.
- */
- llnode = llist_reverse_order(llnode);
- while (llnode) {
- next = llnode->next;
- estatus_node = llist_entry(llnode, struct ghes_estatus_node,
- llnode);
- estatus = GHES_ESTATUS_FROM_NODE(estatus_node);
- len = cper_estatus_len(estatus);
- node_len = GHES_ESTATUS_NODE_LEN(len);
- ghes_do_proc(estatus_node->ghes, estatus);
- if (!ghes_estatus_cached(estatus)) {
- generic = estatus_node->generic;
- if (ghes_print_estatus(NULL, generic, estatus))
- ghes_estatus_cache_add(generic, estatus);
- }
- gen_pool_free(ghes_estatus_pool, (unsigned long)estatus_node,
- node_len);
- llnode = next;
- }
-}
-
-static void ghes_print_queued_estatus(void)
-{
- struct llist_node *llnode;
- struct ghes_estatus_node *estatus_node;
- struct acpi_hest_generic *generic;
- struct acpi_hest_generic_status *estatus;
-
- llnode = llist_del_all(&ghes_estatus_llist);
- /*
- * Because the time order of estatus in list is reversed,
- * revert it back to proper order.
- */
- llnode = llist_reverse_order(llnode);
- while (llnode) {
- estatus_node = llist_entry(llnode, struct ghes_estatus_node,
- llnode);
- estatus = GHES_ESTATUS_FROM_NODE(estatus_node);
- generic = estatus_node->generic;
- ghes_print_estatus(NULL, generic, estatus);
- llnode = llnode->next;
- }
-}
-
-/* Save estatus for further processing in IRQ context */
-static void __process_error(struct ghes *ghes)
-{
-#ifdef CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG
- u32 len, node_len;
- struct ghes_estatus_node *estatus_node;
- struct acpi_hest_generic_status *estatus;
-
- if (ghes_estatus_cached(ghes->estatus))
- return;
-
- len = cper_estatus_len(ghes->estatus);
- node_len = GHES_ESTATUS_NODE_LEN(len);
-
- estatus_node = (void *)gen_pool_alloc(ghes_estatus_pool, node_len);
- if (!estatus_node)
- return;
-
- estatus_node->ghes = ghes;
- estatus_node->generic = ghes->generic;
- estatus = GHES_ESTATUS_FROM_NODE(estatus_node);
- memcpy(estatus, ghes->estatus, len);
- llist_add(&estatus_node->llnode, &ghes_estatus_llist);
-#endif
-}
-
static int ghes_notify_nmi(unsigned int cmd, struct pt_regs *regs)
{
struct ghes *ghes;
@@ -967,26 +1003,6 @@ static int ghes_notify_nmi(unsigned int cmd, struct pt_regs *regs)
return ret;
}
-static unsigned long ghes_esource_prealloc_size(
- const struct acpi_hest_generic *generic)
-{
- unsigned long block_length, prealloc_records, prealloc_size;
-
- block_length = min_t(unsigned long, generic->error_block_length,
- GHES_ESTATUS_MAX_SIZE);
- prealloc_records = max_t(unsigned long,
- generic->records_to_preallocate, 1);
- prealloc_size = min_t(unsigned long, block_length * prealloc_records,
- GHES_ESOURCE_PREALLOC_MAX_SIZE);
-
- return prealloc_size;
-}
-
-static void ghes_estatus_pool_shrink(unsigned long len)
-{
- ghes_estatus_pool_size_request -= PAGE_ALIGN(len);
-}
-
static void ghes_nmi_add(struct ghes *ghes)
{
unsigned long len;
@@ -1018,14 +1034,9 @@ static void ghes_nmi_remove(struct ghes *ghes)
ghes_estatus_pool_shrink(len);
}
-static void ghes_nmi_init_cxt(void)
-{
- init_irq_work(&ghes_proc_irq_work, ghes_proc_in_irq);
-}
#else /* CONFIG_HAVE_ACPI_APEI_NMI */
static inline void ghes_nmi_add(struct ghes *ghes) { }
static inline void ghes_nmi_remove(struct ghes *ghes) { }
-static inline void ghes_nmi_init_cxt(void) { }
#endif /* CONFIG_HAVE_ACPI_APEI_NMI */
static int ghes_probe(struct platform_device *ghes_dev)
--
2.15.1
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH 01/11] ACPI / APEI: Move the estatus queue code up, and under its own ifdef
@ 2018-02-15 18:55 ` James Morse
0 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-02-15 18:55 UTC (permalink / raw)
To: linux-acpi
Cc: kvmarm, linux-arm-kernel, linux-mm, Borislav Petkov,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
Naoya Horiguchi, Rafael Wysocki, Len Brown, Tony Luck,
Tyler Baicar, Dongjiu Geng, Xie XiuQi, Punit Agrawal,
James Morse
To support asynchronous NMI-like notifications on arm64 we need to use
the estatus-queue. These patches refactor it to allow multiple APEI
notification types to use it.
First we move the estatus-queue code higher in the file so that any
notify_foo() handler can make user of it.
This patch moves code around ... and makes the following trivial change:
Freshen the dated comment above ghes_estatus_llist. printk() is no
longer the issue, its the helpers like memory_failure_queue() that
still aren't nmi safe.
Signed-off-by: James Morse <james.morse@arm.com>
---
drivers/acpi/apei/ghes.c | 267 ++++++++++++++++++++++++-----------------------
1 file changed, 139 insertions(+), 128 deletions(-)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 1efefe919555..e42b587c509b 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -545,6 +545,16 @@ static int ghes_print_estatus(const char *pfx,
return 0;
}
+static void __ghes_panic(struct ghes *ghes)
+{
+ __ghes_print_estatus(KERN_EMERG, ghes->generic, ghes->estatus);
+
+ /* reboot to log the error! */
+ if (!panic_timeout)
+ panic_timeout = ghes_panic_timeout;
+ panic("Fatal hardware error!");
+}
+
/*
* GHES error status reporting throttle, to report more kinds of
* errors, instead of just most frequently occurred errors.
@@ -672,6 +682,135 @@ static void ghes_estatus_cache_add(
rcu_read_unlock();
}
+#ifdef CONFIG_HAVE_ACPI_APEI_NMI
+/*
+ * While printk() now has an in_nmi() path, the handling for CPER records
+ * does not. For example, memory_failure_queue() takes spinlocks and calls
+ * schedule_work_on().
+ *
+ * So in any NMI-like handler, we allocate required memory from lock-less
+ * memory allocator (ghes_estatus_pool), save estatus into it, put them into
+ * lock-less list (ghes_estatus_llist), then delay printk into IRQ context via
+ * irq_work (ghes_proc_irq_work). ghes_estatus_size_request record
+ * required pool size by all NMI error source.
+ *
+ * Memory from the ghes_estatus_pool is also used with the ghes_estatus_cache
+ * to suppress frequent messages.
+ */
+static struct llist_head ghes_estatus_llist;
+static struct irq_work ghes_proc_irq_work;
+
+static void ghes_print_queued_estatus(void)
+{
+ struct llist_node *llnode;
+ struct ghes_estatus_node *estatus_node;
+ struct acpi_hest_generic *generic;
+ struct acpi_hest_generic_status *estatus;
+
+ llnode = llist_del_all(&ghes_estatus_llist);
+ /*
+ * Because the time order of estatus in list is reversed,
+ * revert it back to proper order.
+ */
+ llnode = llist_reverse_order(llnode);
+ while (llnode) {
+ estatus_node = llist_entry(llnode, struct ghes_estatus_node,
+ llnode);
+ estatus = GHES_ESTATUS_FROM_NODE(estatus_node);
+ generic = estatus_node->generic;
+ ghes_print_estatus(NULL, generic, estatus);
+ llnode = llnode->next;
+ }
+}
+
+/* Save estatus for further processing in IRQ context */
+static void __process_error(struct ghes *ghes)
+{
+#ifdef CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG
+ u32 len, node_len;
+ struct ghes_estatus_node *estatus_node;
+ struct acpi_hest_generic_status *estatus;
+
+ if (ghes_estatus_cached(ghes->estatus))
+ return;
+
+ len = cper_estatus_len(ghes->estatus);
+ node_len = GHES_ESTATUS_NODE_LEN(len);
+
+ estatus_node = (void *)gen_pool_alloc(ghes_estatus_pool, node_len);
+ if (!estatus_node)
+ return;
+
+ estatus_node->ghes = ghes;
+ estatus_node->generic = ghes->generic;
+ estatus = GHES_ESTATUS_FROM_NODE(estatus_node);
+ memcpy(estatus, ghes->estatus, len);
+ llist_add(&estatus_node->llnode, &ghes_estatus_llist);
+#endif
+}
+
+static unsigned long ghes_esource_prealloc_size(
+ const struct acpi_hest_generic *generic)
+{
+ unsigned long block_length, prealloc_records, prealloc_size;
+
+ block_length = min_t(unsigned long, generic->error_block_length,
+ GHES_ESTATUS_MAX_SIZE);
+ prealloc_records = max_t(unsigned long,
+ generic->records_to_preallocate, 1);
+ prealloc_size = min_t(unsigned long, block_length * prealloc_records,
+ GHES_ESOURCE_PREALLOC_MAX_SIZE);
+
+ return prealloc_size;
+}
+
+static void ghes_estatus_pool_shrink(unsigned long len)
+{
+ ghes_estatus_pool_size_request -= PAGE_ALIGN(len);
+}
+
+static void ghes_proc_in_irq(struct irq_work *irq_work)
+{
+ struct llist_node *llnode, *next;
+ struct ghes_estatus_node *estatus_node;
+ struct acpi_hest_generic *generic;
+ struct acpi_hest_generic_status *estatus;
+ u32 len, node_len;
+
+ llnode = llist_del_all(&ghes_estatus_llist);
+ /*
+ * Because the time order of estatus in list is reversed,
+ * revert it back to proper order.
+ */
+ llnode = llist_reverse_order(llnode);
+ while (llnode) {
+ next = llnode->next;
+ estatus_node = llist_entry(llnode, struct ghes_estatus_node,
+ llnode);
+ estatus = GHES_ESTATUS_FROM_NODE(estatus_node);
+ len = cper_estatus_len(estatus);
+ node_len = GHES_ESTATUS_NODE_LEN(len);
+ ghes_do_proc(estatus_node->ghes, estatus);
+ if (!ghes_estatus_cached(estatus)) {
+ generic = estatus_node->generic;
+ if (ghes_print_estatus(NULL, generic, estatus))
+ ghes_estatus_cache_add(generic, estatus);
+ }
+ gen_pool_free(ghes_estatus_pool, (unsigned long)estatus_node,
+ node_len);
+ llnode = next;
+ }
+}
+
+static void ghes_nmi_init_cxt(void)
+{
+ init_irq_work(&ghes_proc_irq_work, ghes_proc_in_irq);
+}
+
+#else
+static inline void ghes_nmi_init_cxt(void) { }
+#endif /* CONFIG_HAVE_ACPI_APEI_NMI */
+
static int ghes_ack_error(struct acpi_hest_generic_v2 *gv2)
{
int rc;
@@ -687,16 +826,6 @@ static int ghes_ack_error(struct acpi_hest_generic_v2 *gv2)
return apei_write(val, &gv2->read_ack_register);
}
-static void __ghes_panic(struct ghes *ghes)
-{
- __ghes_print_estatus(KERN_EMERG, ghes->generic, ghes->estatus);
-
- /* reboot to log the error! */
- if (!panic_timeout)
- panic_timeout = ghes_panic_timeout;
- panic("Fatal hardware error!");
-}
-
static int ghes_proc(struct ghes *ghes)
{
int rc;
@@ -828,17 +957,6 @@ static inline void ghes_sea_remove(struct ghes *ghes) { }
#endif /* CONFIG_ACPI_APEI_SEA */
#ifdef CONFIG_HAVE_ACPI_APEI_NMI
-/*
- * printk is not safe in NMI context. So in NMI handler, we allocate
- * required memory from lock-less memory allocator
- * (ghes_estatus_pool), save estatus into it, put them into lock-less
- * list (ghes_estatus_llist), then delay printk into IRQ context via
- * irq_work (ghes_proc_irq_work). ghes_estatus_size_request record
- * required pool size by all NMI error source.
- */
-static struct llist_head ghes_estatus_llist;
-static struct irq_work ghes_proc_irq_work;
-
/*
* NMI may be triggered on any CPU, so ghes_in_nmi is used for
* having only one concurrent reader.
@@ -847,88 +965,6 @@ static atomic_t ghes_in_nmi = ATOMIC_INIT(0);
static LIST_HEAD(ghes_nmi);
-static void ghes_proc_in_irq(struct irq_work *irq_work)
-{
- struct llist_node *llnode, *next;
- struct ghes_estatus_node *estatus_node;
- struct acpi_hest_generic *generic;
- struct acpi_hest_generic_status *estatus;
- u32 len, node_len;
-
- llnode = llist_del_all(&ghes_estatus_llist);
- /*
- * Because the time order of estatus in list is reversed,
- * revert it back to proper order.
- */
- llnode = llist_reverse_order(llnode);
- while (llnode) {
- next = llnode->next;
- estatus_node = llist_entry(llnode, struct ghes_estatus_node,
- llnode);
- estatus = GHES_ESTATUS_FROM_NODE(estatus_node);
- len = cper_estatus_len(estatus);
- node_len = GHES_ESTATUS_NODE_LEN(len);
- ghes_do_proc(estatus_node->ghes, estatus);
- if (!ghes_estatus_cached(estatus)) {
- generic = estatus_node->generic;
- if (ghes_print_estatus(NULL, generic, estatus))
- ghes_estatus_cache_add(generic, estatus);
- }
- gen_pool_free(ghes_estatus_pool, (unsigned long)estatus_node,
- node_len);
- llnode = next;
- }
-}
-
-static void ghes_print_queued_estatus(void)
-{
- struct llist_node *llnode;
- struct ghes_estatus_node *estatus_node;
- struct acpi_hest_generic *generic;
- struct acpi_hest_generic_status *estatus;
-
- llnode = llist_del_all(&ghes_estatus_llist);
- /*
- * Because the time order of estatus in list is reversed,
- * revert it back to proper order.
- */
- llnode = llist_reverse_order(llnode);
- while (llnode) {
- estatus_node = llist_entry(llnode, struct ghes_estatus_node,
- llnode);
- estatus = GHES_ESTATUS_FROM_NODE(estatus_node);
- generic = estatus_node->generic;
- ghes_print_estatus(NULL, generic, estatus);
- llnode = llnode->next;
- }
-}
-
-/* Save estatus for further processing in IRQ context */
-static void __process_error(struct ghes *ghes)
-{
-#ifdef CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG
- u32 len, node_len;
- struct ghes_estatus_node *estatus_node;
- struct acpi_hest_generic_status *estatus;
-
- if (ghes_estatus_cached(ghes->estatus))
- return;
-
- len = cper_estatus_len(ghes->estatus);
- node_len = GHES_ESTATUS_NODE_LEN(len);
-
- estatus_node = (void *)gen_pool_alloc(ghes_estatus_pool, node_len);
- if (!estatus_node)
- return;
-
- estatus_node->ghes = ghes;
- estatus_node->generic = ghes->generic;
- estatus = GHES_ESTATUS_FROM_NODE(estatus_node);
- memcpy(estatus, ghes->estatus, len);
- llist_add(&estatus_node->llnode, &ghes_estatus_llist);
-#endif
-}
-
static int ghes_notify_nmi(unsigned int cmd, struct pt_regs *regs)
{
struct ghes *ghes;
@@ -967,26 +1003,6 @@ static int ghes_notify_nmi(unsigned int cmd, struct pt_regs *regs)
return ret;
}
-static unsigned long ghes_esource_prealloc_size(
- const struct acpi_hest_generic *generic)
-{
- unsigned long block_length, prealloc_records, prealloc_size;
-
- block_length = min_t(unsigned long, generic->error_block_length,
- GHES_ESTATUS_MAX_SIZE);
- prealloc_records = max_t(unsigned long,
- generic->records_to_preallocate, 1);
- prealloc_size = min_t(unsigned long, block_length * prealloc_records,
- GHES_ESOURCE_PREALLOC_MAX_SIZE);
-
- return prealloc_size;
-}
-
-static void ghes_estatus_pool_shrink(unsigned long len)
-{
- ghes_estatus_pool_size_request -= PAGE_ALIGN(len);
-}
-
static void ghes_nmi_add(struct ghes *ghes)
{
unsigned long len;
@@ -1018,14 +1034,9 @@ static void ghes_nmi_remove(struct ghes *ghes)
ghes_estatus_pool_shrink(len);
}
-static void ghes_nmi_init_cxt(void)
-{
- init_irq_work(&ghes_proc_irq_work, ghes_proc_in_irq);
-}
#else /* CONFIG_HAVE_ACPI_APEI_NMI */
static inline void ghes_nmi_add(struct ghes *ghes) { }
static inline void ghes_nmi_remove(struct ghes *ghes) { }
-static inline void ghes_nmi_init_cxt(void) { }
#endif /* CONFIG_HAVE_ACPI_APEI_NMI */
static int ghes_probe(struct platform_device *ghes_dev)
--
2.15.1
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH 01/11] ACPI / APEI: Move the estatus queue code up, and under its own ifdef
@ 2018-02-15 18:55 ` James Morse
0 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-02-15 18:55 UTC (permalink / raw)
To: linux-arm-kernel
To support asynchronous NMI-like notifications on arm64 we need to use
the estatus-queue. These patches refactor it to allow multiple APEI
notification types to use it.
First we move the estatus-queue code higher in the file so that any
notify_foo() handler can make user of it.
This patch moves code around ... and makes the following trivial change:
Freshen the dated comment above ghes_estatus_llist. printk() is no
longer the issue, its the helpers like memory_failure_queue() that
still aren't nmi safe.
Signed-off-by: James Morse <james.morse@arm.com>
---
drivers/acpi/apei/ghes.c | 267 ++++++++++++++++++++++++-----------------------
1 file changed, 139 insertions(+), 128 deletions(-)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 1efefe919555..e42b587c509b 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -545,6 +545,16 @@ static int ghes_print_estatus(const char *pfx,
return 0;
}
+static void __ghes_panic(struct ghes *ghes)
+{
+ __ghes_print_estatus(KERN_EMERG, ghes->generic, ghes->estatus);
+
+ /* reboot to log the error! */
+ if (!panic_timeout)
+ panic_timeout = ghes_panic_timeout;
+ panic("Fatal hardware error!");
+}
+
/*
* GHES error status reporting throttle, to report more kinds of
* errors, instead of just most frequently occurred errors.
@@ -672,6 +682,135 @@ static void ghes_estatus_cache_add(
rcu_read_unlock();
}
+#ifdef CONFIG_HAVE_ACPI_APEI_NMI
+/*
+ * While printk() now has an in_nmi() path, the handling for CPER records
+ * does not. For example, memory_failure_queue() takes spinlocks and calls
+ * schedule_work_on().
+ *
+ * So in any NMI-like handler, we allocate required memory from lock-less
+ * memory allocator (ghes_estatus_pool), save estatus into it, put them into
+ * lock-less list (ghes_estatus_llist), then delay printk into IRQ context via
+ * irq_work (ghes_proc_irq_work). ghes_estatus_size_request record
+ * required pool size by all NMI error source.
+ *
+ * Memory from the ghes_estatus_pool is also used with the ghes_estatus_cache
+ * to suppress frequent messages.
+ */
+static struct llist_head ghes_estatus_llist;
+static struct irq_work ghes_proc_irq_work;
+
+static void ghes_print_queued_estatus(void)
+{
+ struct llist_node *llnode;
+ struct ghes_estatus_node *estatus_node;
+ struct acpi_hest_generic *generic;
+ struct acpi_hest_generic_status *estatus;
+
+ llnode = llist_del_all(&ghes_estatus_llist);
+ /*
+ * Because the time order of estatus in list is reversed,
+ * revert it back to proper order.
+ */
+ llnode = llist_reverse_order(llnode);
+ while (llnode) {
+ estatus_node = llist_entry(llnode, struct ghes_estatus_node,
+ llnode);
+ estatus = GHES_ESTATUS_FROM_NODE(estatus_node);
+ generic = estatus_node->generic;
+ ghes_print_estatus(NULL, generic, estatus);
+ llnode = llnode->next;
+ }
+}
+
+/* Save estatus for further processing in IRQ context */
+static void __process_error(struct ghes *ghes)
+{
+#ifdef CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG
+ u32 len, node_len;
+ struct ghes_estatus_node *estatus_node;
+ struct acpi_hest_generic_status *estatus;
+
+ if (ghes_estatus_cached(ghes->estatus))
+ return;
+
+ len = cper_estatus_len(ghes->estatus);
+ node_len = GHES_ESTATUS_NODE_LEN(len);
+
+ estatus_node = (void *)gen_pool_alloc(ghes_estatus_pool, node_len);
+ if (!estatus_node)
+ return;
+
+ estatus_node->ghes = ghes;
+ estatus_node->generic = ghes->generic;
+ estatus = GHES_ESTATUS_FROM_NODE(estatus_node);
+ memcpy(estatus, ghes->estatus, len);
+ llist_add(&estatus_node->llnode, &ghes_estatus_llist);
+#endif
+}
+
+static unsigned long ghes_esource_prealloc_size(
+ const struct acpi_hest_generic *generic)
+{
+ unsigned long block_length, prealloc_records, prealloc_size;
+
+ block_length = min_t(unsigned long, generic->error_block_length,
+ GHES_ESTATUS_MAX_SIZE);
+ prealloc_records = max_t(unsigned long,
+ generic->records_to_preallocate, 1);
+ prealloc_size = min_t(unsigned long, block_length * prealloc_records,
+ GHES_ESOURCE_PREALLOC_MAX_SIZE);
+
+ return prealloc_size;
+}
+
+static void ghes_estatus_pool_shrink(unsigned long len)
+{
+ ghes_estatus_pool_size_request -= PAGE_ALIGN(len);
+}
+
+static void ghes_proc_in_irq(struct irq_work *irq_work)
+{
+ struct llist_node *llnode, *next;
+ struct ghes_estatus_node *estatus_node;
+ struct acpi_hest_generic *generic;
+ struct acpi_hest_generic_status *estatus;
+ u32 len, node_len;
+
+ llnode = llist_del_all(&ghes_estatus_llist);
+ /*
+ * Because the time order of estatus in list is reversed,
+ * revert it back to proper order.
+ */
+ llnode = llist_reverse_order(llnode);
+ while (llnode) {
+ next = llnode->next;
+ estatus_node = llist_entry(llnode, struct ghes_estatus_node,
+ llnode);
+ estatus = GHES_ESTATUS_FROM_NODE(estatus_node);
+ len = cper_estatus_len(estatus);
+ node_len = GHES_ESTATUS_NODE_LEN(len);
+ ghes_do_proc(estatus_node->ghes, estatus);
+ if (!ghes_estatus_cached(estatus)) {
+ generic = estatus_node->generic;
+ if (ghes_print_estatus(NULL, generic, estatus))
+ ghes_estatus_cache_add(generic, estatus);
+ }
+ gen_pool_free(ghes_estatus_pool, (unsigned long)estatus_node,
+ node_len);
+ llnode = next;
+ }
+}
+
+static void ghes_nmi_init_cxt(void)
+{
+ init_irq_work(&ghes_proc_irq_work, ghes_proc_in_irq);
+}
+
+#else
+static inline void ghes_nmi_init_cxt(void) { }
+#endif /* CONFIG_HAVE_ACPI_APEI_NMI */
+
static int ghes_ack_error(struct acpi_hest_generic_v2 *gv2)
{
int rc;
@@ -687,16 +826,6 @@ static int ghes_ack_error(struct acpi_hest_generic_v2 *gv2)
return apei_write(val, &gv2->read_ack_register);
}
-static void __ghes_panic(struct ghes *ghes)
-{
- __ghes_print_estatus(KERN_EMERG, ghes->generic, ghes->estatus);
-
- /* reboot to log the error! */
- if (!panic_timeout)
- panic_timeout = ghes_panic_timeout;
- panic("Fatal hardware error!");
-}
-
static int ghes_proc(struct ghes *ghes)
{
int rc;
@@ -828,17 +957,6 @@ static inline void ghes_sea_remove(struct ghes *ghes) { }
#endif /* CONFIG_ACPI_APEI_SEA */
#ifdef CONFIG_HAVE_ACPI_APEI_NMI
-/*
- * printk is not safe in NMI context. So in NMI handler, we allocate
- * required memory from lock-less memory allocator
- * (ghes_estatus_pool), save estatus into it, put them into lock-less
- * list (ghes_estatus_llist), then delay printk into IRQ context via
- * irq_work (ghes_proc_irq_work). ghes_estatus_size_request record
- * required pool size by all NMI error source.
- */
-static struct llist_head ghes_estatus_llist;
-static struct irq_work ghes_proc_irq_work;
-
/*
* NMI may be triggered on any CPU, so ghes_in_nmi is used for
* having only one concurrent reader.
@@ -847,88 +965,6 @@ static atomic_t ghes_in_nmi = ATOMIC_INIT(0);
static LIST_HEAD(ghes_nmi);
-static void ghes_proc_in_irq(struct irq_work *irq_work)
-{
- struct llist_node *llnode, *next;
- struct ghes_estatus_node *estatus_node;
- struct acpi_hest_generic *generic;
- struct acpi_hest_generic_status *estatus;
- u32 len, node_len;
-
- llnode = llist_del_all(&ghes_estatus_llist);
- /*
- * Because the time order of estatus in list is reversed,
- * revert it back to proper order.
- */
- llnode = llist_reverse_order(llnode);
- while (llnode) {
- next = llnode->next;
- estatus_node = llist_entry(llnode, struct ghes_estatus_node,
- llnode);
- estatus = GHES_ESTATUS_FROM_NODE(estatus_node);
- len = cper_estatus_len(estatus);
- node_len = GHES_ESTATUS_NODE_LEN(len);
- ghes_do_proc(estatus_node->ghes, estatus);
- if (!ghes_estatus_cached(estatus)) {
- generic = estatus_node->generic;
- if (ghes_print_estatus(NULL, generic, estatus))
- ghes_estatus_cache_add(generic, estatus);
- }
- gen_pool_free(ghes_estatus_pool, (unsigned long)estatus_node,
- node_len);
- llnode = next;
- }
-}
-
-static void ghes_print_queued_estatus(void)
-{
- struct llist_node *llnode;
- struct ghes_estatus_node *estatus_node;
- struct acpi_hest_generic *generic;
- struct acpi_hest_generic_status *estatus;
-
- llnode = llist_del_all(&ghes_estatus_llist);
- /*
- * Because the time order of estatus in list is reversed,
- * revert it back to proper order.
- */
- llnode = llist_reverse_order(llnode);
- while (llnode) {
- estatus_node = llist_entry(llnode, struct ghes_estatus_node,
- llnode);
- estatus = GHES_ESTATUS_FROM_NODE(estatus_node);
- generic = estatus_node->generic;
- ghes_print_estatus(NULL, generic, estatus);
- llnode = llnode->next;
- }
-}
-
-/* Save estatus for further processing in IRQ context */
-static void __process_error(struct ghes *ghes)
-{
-#ifdef CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG
- u32 len, node_len;
- struct ghes_estatus_node *estatus_node;
- struct acpi_hest_generic_status *estatus;
-
- if (ghes_estatus_cached(ghes->estatus))
- return;
-
- len = cper_estatus_len(ghes->estatus);
- node_len = GHES_ESTATUS_NODE_LEN(len);
-
- estatus_node = (void *)gen_pool_alloc(ghes_estatus_pool, node_len);
- if (!estatus_node)
- return;
-
- estatus_node->ghes = ghes;
- estatus_node->generic = ghes->generic;
- estatus = GHES_ESTATUS_FROM_NODE(estatus_node);
- memcpy(estatus, ghes->estatus, len);
- llist_add(&estatus_node->llnode, &ghes_estatus_llist);
-#endif
-}
-
static int ghes_notify_nmi(unsigned int cmd, struct pt_regs *regs)
{
struct ghes *ghes;
@@ -967,26 +1003,6 @@ static int ghes_notify_nmi(unsigned int cmd, struct pt_regs *regs)
return ret;
}
-static unsigned long ghes_esource_prealloc_size(
- const struct acpi_hest_generic *generic)
-{
- unsigned long block_length, prealloc_records, prealloc_size;
-
- block_length = min_t(unsigned long, generic->error_block_length,
- GHES_ESTATUS_MAX_SIZE);
- prealloc_records = max_t(unsigned long,
- generic->records_to_preallocate, 1);
- prealloc_size = min_t(unsigned long, block_length * prealloc_records,
- GHES_ESOURCE_PREALLOC_MAX_SIZE);
-
- return prealloc_size;
-}
-
-static void ghes_estatus_pool_shrink(unsigned long len)
-{
- ghes_estatus_pool_size_request -= PAGE_ALIGN(len);
-}
-
static void ghes_nmi_add(struct ghes *ghes)
{
unsigned long len;
@@ -1018,14 +1034,9 @@ static void ghes_nmi_remove(struct ghes *ghes)
ghes_estatus_pool_shrink(len);
}
-static void ghes_nmi_init_cxt(void)
-{
- init_irq_work(&ghes_proc_irq_work, ghes_proc_in_irq);
-}
#else /* CONFIG_HAVE_ACPI_APEI_NMI */
static inline void ghes_nmi_add(struct ghes *ghes) { }
static inline void ghes_nmi_remove(struct ghes *ghes) { }
-static inline void ghes_nmi_init_cxt(void) { }
#endif /* CONFIG_HAVE_ACPI_APEI_NMI */
static int ghes_probe(struct platform_device *ghes_dev)
--
2.15.1
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code
2018-02-15 18:55 ` James Morse
(?)
@ 2018-02-15 18:55 ` James Morse
-1 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-02-15 18:55 UTC (permalink / raw)
To: linux-acpi
Cc: kvmarm, linux-arm-kernel, linux-mm, Borislav Petkov,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
Naoya Horiguchi, Rafael Wysocki, Len Brown, Tony Luck,
Tyler Baicar, Dongjiu Geng, Xie XiuQi, Punit Agrawal,
James Morse
To support asynchronous NMI-like notifications on arm64 we need to use
the estatus-queue. These patches refactor it to allow multiple APEI
notification types to use it.
Refactor the estatus queue's pool grow/shrink code and notification
routine from NOTIFY_NMI's handlers. This will allow another notification
method to use the estatus queue without duplicating this code.
This patch adds rcu_read_lock()/rcu_read_unlock() around the list
list_for_each_entry_rcu() walker. These aren't strictly necessary as
the whole nmi_enter/nmi_exit() window is a spooky RCU read-side
critical section.
Keep the oops_begin() call for x86, arm64 doesn't have one of these,
and APEI is the only thing outside arch code calling this..
The existing ghes_estatus_pool_shrink() is folded into the new
ghes_estatus_queue_shrink_pool() as only the queue uses it.
_in_nmi_notify_one() is separate from the rcu-list walker for a later
caller that doesn't need to walk a list.
Signed-off-by: James Morse <james.morse@arm.com>
---
drivers/acpi/apei/ghes.c | 103 +++++++++++++++++++++++++++++++----------------
1 file changed, 68 insertions(+), 35 deletions(-)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index e42b587c509b..d3cc5bd5b496 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -749,6 +749,54 @@ static void __process_error(struct ghes *ghes)
#endif
}
+static int _in_nmi_notify_one(struct ghes *ghes)
+{
+ int sev;
+ int ret = -ENOENT;
+
+ if (ghes_read_estatus(ghes, 1)) {
+ ghes_clear_estatus(ghes);
+ return ret;
+ } else {
+ ret = 0;
+ }
+
+ sev = ghes_severity(ghes->estatus->error_severity);
+ if (sev >= GHES_SEV_PANIC) {
+#ifdef CONFIG_X86
+ oops_begin();
+#endif
+ ghes_print_queued_estatus();
+ __ghes_panic(ghes);
+ }
+
+ if (!(ghes->flags & GHES_TO_CLEAR))
+ return ret;
+
+ __process_error(ghes);
+ ghes_clear_estatus(ghes);
+
+ return ret;
+}
+
+static int ghes_estatus_queue_notified(struct list_head *rcu_list)
+{
+ int ret = -ENOENT;
+ struct ghes *ghes;
+
+ rcu_read_lock();
+ list_for_each_entry_rcu(ghes, rcu_list, list) {
+ if (!_in_nmi_notify_one(ghes))
+ ret = 0;
+ }
+ rcu_read_unlock();
+
+ if (IS_ENABLED(CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG) && ret == 0)
+ irq_work_queue(&ghes_proc_irq_work);
+
+ return ret;
+}
+
static unsigned long ghes_esource_prealloc_size(
const struct acpi_hest_generic *generic)
{
@@ -764,11 +812,24 @@ static unsigned long ghes_esource_prealloc_size(
return prealloc_size;
}
-static void ghes_estatus_pool_shrink(unsigned long len)
+/* After removing a queue user, we can shrink to pool */
+static void ghes_estatus_queue_shrink_pool(struct ghes *ghes)
{
+ unsigned long len;
+
+ len = ghes_esource_prealloc_size(ghes->generic);
ghes_estatus_pool_size_request -= PAGE_ALIGN(len);
}
+/* Before adding a queue user, grow the pool */
+static void ghes_estatus_queue_grow_pool(struct ghes *ghes)
+{
+ unsigned long len;
+
+ len = ghes_esource_prealloc_size(ghes->generic);
+ ghes_estatus_pool_expand(len);
+}
+
static void ghes_proc_in_irq(struct irq_work *irq_work)
{
struct llist_node *llnode, *next;
@@ -967,48 +1028,22 @@ static LIST_HEAD(ghes_nmi);
static int ghes_notify_nmi(unsigned int cmd, struct pt_regs *regs)
{
- struct ghes *ghes;
- int sev, ret = NMI_DONE;
+ int ret = NMI_DONE;
if (!atomic_add_unless(&ghes_in_nmi, 1, 1))
return ret;
- list_for_each_entry_rcu(ghes, &ghes_nmi, list) {
- if (ghes_read_estatus(ghes, 1)) {
- ghes_clear_estatus(ghes);
- continue;
- } else {
- ret = NMI_HANDLED;
- }
-
- sev = ghes_severity(ghes->estatus->error_severity);
- if (sev >= GHES_SEV_PANIC) {
- oops_begin();
- ghes_print_queued_estatus();
- __ghes_panic(ghes);
- }
-
- if (!(ghes->flags & GHES_TO_CLEAR))
- continue;
-
- __process_error(ghes);
- ghes_clear_estatus(ghes);
- }
+ if (!ghes_estatus_queue_notified(&ghes_nmi))
+ ret = NMI_HANDLED;
-#ifdef CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG
- if (ret == NMI_HANDLED)
- irq_work_queue(&ghes_proc_irq_work);
-#endif
atomic_dec(&ghes_in_nmi);
return ret;
}
static void ghes_nmi_add(struct ghes *ghes)
{
- unsigned long len;
+ ghes_estatus_queue_grow_pool(ghes);
- len = ghes_esource_prealloc_size(ghes->generic);
- ghes_estatus_pool_expand(len);
mutex_lock(&ghes_list_mutex);
if (list_empty(&ghes_nmi))
register_nmi_handler(NMI_LOCAL, ghes_notify_nmi, 0, "ghes");
@@ -1018,8 +1053,6 @@ static void ghes_nmi_add(struct ghes *ghes)
static void ghes_nmi_remove(struct ghes *ghes)
{
- unsigned long len;
-
mutex_lock(&ghes_list_mutex);
list_del_rcu(&ghes->list);
if (list_empty(&ghes_nmi))
@@ -1030,8 +1063,8 @@ static void ghes_nmi_remove(struct ghes *ghes)
* freed after NMI handler finishes.
*/
synchronize_rcu();
- len = ghes_esource_prealloc_size(ghes->generic);
- ghes_estatus_pool_shrink(len);
+
+ ghes_estatus_queue_shrink_pool(ghes);
}
#else /* CONFIG_HAVE_ACPI_APEI_NMI */
--
2.15.1
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code
@ 2018-02-15 18:55 ` James Morse
0 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-02-15 18:55 UTC (permalink / raw)
To: linux-acpi
Cc: kvmarm, linux-arm-kernel, linux-mm, Borislav Petkov,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
Naoya Horiguchi, Rafael Wysocki, Len Brown, Tony Luck,
Tyler Baicar, Dongjiu Geng, Xie XiuQi, Punit Agrawal,
James Morse
To support asynchronous NMI-like notifications on arm64 we need to use
the estatus-queue. These patches refactor it to allow multiple APEI
notification types to use it.
Refactor the estatus queue's pool grow/shrink code and notification
routine from NOTIFY_NMI's handlers. This will allow another notification
method to use the estatus queue without duplicating this code.
This patch adds rcu_read_lock()/rcu_read_unlock() around the list
list_for_each_entry_rcu() walker. These aren't strictly necessary as
the whole nmi_enter/nmi_exit() window is a spooky RCU read-side
critical section.
Keep the oops_begin() call for x86, arm64 doesn't have one of these,
and APEI is the only thing outside arch code calling this..
The existing ghes_estatus_pool_shrink() is folded into the new
ghes_estatus_queue_shrink_pool() as only the queue uses it.
_in_nmi_notify_one() is separate from the rcu-list walker for a later
caller that doesn't need to walk a list.
Signed-off-by: James Morse <james.morse@arm.com>
---
drivers/acpi/apei/ghes.c | 103 +++++++++++++++++++++++++++++++----------------
1 file changed, 68 insertions(+), 35 deletions(-)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index e42b587c509b..d3cc5bd5b496 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -749,6 +749,54 @@ static void __process_error(struct ghes *ghes)
#endif
}
+static int _in_nmi_notify_one(struct ghes *ghes)
+{
+ int sev;
+ int ret = -ENOENT;
+
+ if (ghes_read_estatus(ghes, 1)) {
+ ghes_clear_estatus(ghes);
+ return ret;
+ } else {
+ ret = 0;
+ }
+
+ sev = ghes_severity(ghes->estatus->error_severity);
+ if (sev >= GHES_SEV_PANIC) {
+#ifdef CONFIG_X86
+ oops_begin();
+#endif
+ ghes_print_queued_estatus();
+ __ghes_panic(ghes);
+ }
+
+ if (!(ghes->flags & GHES_TO_CLEAR))
+ return ret;
+
+ __process_error(ghes);
+ ghes_clear_estatus(ghes);
+
+ return ret;
+}
+
+static int ghes_estatus_queue_notified(struct list_head *rcu_list)
+{
+ int ret = -ENOENT;
+ struct ghes *ghes;
+
+ rcu_read_lock();
+ list_for_each_entry_rcu(ghes, rcu_list, list) {
+ if (!_in_nmi_notify_one(ghes))
+ ret = 0;
+ }
+ rcu_read_unlock();
+
+ if (IS_ENABLED(CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG) && ret == 0)
+ irq_work_queue(&ghes_proc_irq_work);
+
+ return ret;
+}
+
static unsigned long ghes_esource_prealloc_size(
const struct acpi_hest_generic *generic)
{
@@ -764,11 +812,24 @@ static unsigned long ghes_esource_prealloc_size(
return prealloc_size;
}
-static void ghes_estatus_pool_shrink(unsigned long len)
+/* After removing a queue user, we can shrink to pool */
+static void ghes_estatus_queue_shrink_pool(struct ghes *ghes)
{
+ unsigned long len;
+
+ len = ghes_esource_prealloc_size(ghes->generic);
ghes_estatus_pool_size_request -= PAGE_ALIGN(len);
}
+/* Before adding a queue user, grow the pool */
+static void ghes_estatus_queue_grow_pool(struct ghes *ghes)
+{
+ unsigned long len;
+
+ len = ghes_esource_prealloc_size(ghes->generic);
+ ghes_estatus_pool_expand(len);
+}
+
static void ghes_proc_in_irq(struct irq_work *irq_work)
{
struct llist_node *llnode, *next;
@@ -967,48 +1028,22 @@ static LIST_HEAD(ghes_nmi);
static int ghes_notify_nmi(unsigned int cmd, struct pt_regs *regs)
{
- struct ghes *ghes;
- int sev, ret = NMI_DONE;
+ int ret = NMI_DONE;
if (!atomic_add_unless(&ghes_in_nmi, 1, 1))
return ret;
- list_for_each_entry_rcu(ghes, &ghes_nmi, list) {
- if (ghes_read_estatus(ghes, 1)) {
- ghes_clear_estatus(ghes);
- continue;
- } else {
- ret = NMI_HANDLED;
- }
-
- sev = ghes_severity(ghes->estatus->error_severity);
- if (sev >= GHES_SEV_PANIC) {
- oops_begin();
- ghes_print_queued_estatus();
- __ghes_panic(ghes);
- }
-
- if (!(ghes->flags & GHES_TO_CLEAR))
- continue;
-
- __process_error(ghes);
- ghes_clear_estatus(ghes);
- }
+ if (!ghes_estatus_queue_notified(&ghes_nmi))
+ ret = NMI_HANDLED;
-#ifdef CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG
- if (ret == NMI_HANDLED)
- irq_work_queue(&ghes_proc_irq_work);
-#endif
atomic_dec(&ghes_in_nmi);
return ret;
}
static void ghes_nmi_add(struct ghes *ghes)
{
- unsigned long len;
+ ghes_estatus_queue_grow_pool(ghes);
- len = ghes_esource_prealloc_size(ghes->generic);
- ghes_estatus_pool_expand(len);
mutex_lock(&ghes_list_mutex);
if (list_empty(&ghes_nmi))
register_nmi_handler(NMI_LOCAL, ghes_notify_nmi, 0, "ghes");
@@ -1018,8 +1053,6 @@ static void ghes_nmi_add(struct ghes *ghes)
static void ghes_nmi_remove(struct ghes *ghes)
{
- unsigned long len;
-
mutex_lock(&ghes_list_mutex);
list_del_rcu(&ghes->list);
if (list_empty(&ghes_nmi))
@@ -1030,8 +1063,8 @@ static void ghes_nmi_remove(struct ghes *ghes)
* freed after NMI handler finishes.
*/
synchronize_rcu();
- len = ghes_esource_prealloc_size(ghes->generic);
- ghes_estatus_pool_shrink(len);
+
+ ghes_estatus_queue_shrink_pool(ghes);
}
#else /* CONFIG_HAVE_ACPI_APEI_NMI */
--
2.15.1
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code
@ 2018-02-15 18:55 ` James Morse
0 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-02-15 18:55 UTC (permalink / raw)
To: linux-arm-kernel
To support asynchronous NMI-like notifications on arm64 we need to use
the estatus-queue. These patches refactor it to allow multiple APEI
notification types to use it.
Refactor the estatus queue's pool grow/shrink code and notification
routine from NOTIFY_NMI's handlers. This will allow another notification
method to use the estatus queue without duplicating this code.
This patch adds rcu_read_lock()/rcu_read_unlock() around the list
list_for_each_entry_rcu() walker. These aren't strictly necessary as
the whole nmi_enter/nmi_exit() window is a spooky RCU read-side
critical section.
Keep the oops_begin() call for x86, arm64 doesn't have one of these,
and APEI is the only thing outside arch code calling this..
The existing ghes_estatus_pool_shrink() is folded into the new
ghes_estatus_queue_shrink_pool() as only the queue uses it.
_in_nmi_notify_one() is separate from the rcu-list walker for a later
caller that doesn't need to walk a list.
Signed-off-by: James Morse <james.morse@arm.com>
---
drivers/acpi/apei/ghes.c | 103 +++++++++++++++++++++++++++++++----------------
1 file changed, 68 insertions(+), 35 deletions(-)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index e42b587c509b..d3cc5bd5b496 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -749,6 +749,54 @@ static void __process_error(struct ghes *ghes)
#endif
}
+static int _in_nmi_notify_one(struct ghes *ghes)
+{
+ int sev;
+ int ret = -ENOENT;
+
+ if (ghes_read_estatus(ghes, 1)) {
+ ghes_clear_estatus(ghes);
+ return ret;
+ } else {
+ ret = 0;
+ }
+
+ sev = ghes_severity(ghes->estatus->error_severity);
+ if (sev >= GHES_SEV_PANIC) {
+#ifdef CONFIG_X86
+ oops_begin();
+#endif
+ ghes_print_queued_estatus();
+ __ghes_panic(ghes);
+ }
+
+ if (!(ghes->flags & GHES_TO_CLEAR))
+ return ret;
+
+ __process_error(ghes);
+ ghes_clear_estatus(ghes);
+
+ return ret;
+}
+
+static int ghes_estatus_queue_notified(struct list_head *rcu_list)
+{
+ int ret = -ENOENT;
+ struct ghes *ghes;
+
+ rcu_read_lock();
+ list_for_each_entry_rcu(ghes, rcu_list, list) {
+ if (!_in_nmi_notify_one(ghes))
+ ret = 0;
+ }
+ rcu_read_unlock();
+
+ if (IS_ENABLED(CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG) && ret == 0)
+ irq_work_queue(&ghes_proc_irq_work);
+
+ return ret;
+}
+
static unsigned long ghes_esource_prealloc_size(
const struct acpi_hest_generic *generic)
{
@@ -764,11 +812,24 @@ static unsigned long ghes_esource_prealloc_size(
return prealloc_size;
}
-static void ghes_estatus_pool_shrink(unsigned long len)
+/* After removing a queue user, we can shrink to pool */
+static void ghes_estatus_queue_shrink_pool(struct ghes *ghes)
{
+ unsigned long len;
+
+ len = ghes_esource_prealloc_size(ghes->generic);
ghes_estatus_pool_size_request -= PAGE_ALIGN(len);
}
+/* Before adding a queue user, grow the pool */
+static void ghes_estatus_queue_grow_pool(struct ghes *ghes)
+{
+ unsigned long len;
+
+ len = ghes_esource_prealloc_size(ghes->generic);
+ ghes_estatus_pool_expand(len);
+}
+
static void ghes_proc_in_irq(struct irq_work *irq_work)
{
struct llist_node *llnode, *next;
@@ -967,48 +1028,22 @@ static LIST_HEAD(ghes_nmi);
static int ghes_notify_nmi(unsigned int cmd, struct pt_regs *regs)
{
- struct ghes *ghes;
- int sev, ret = NMI_DONE;
+ int ret = NMI_DONE;
if (!atomic_add_unless(&ghes_in_nmi, 1, 1))
return ret;
- list_for_each_entry_rcu(ghes, &ghes_nmi, list) {
- if (ghes_read_estatus(ghes, 1)) {
- ghes_clear_estatus(ghes);
- continue;
- } else {
- ret = NMI_HANDLED;
- }
-
- sev = ghes_severity(ghes->estatus->error_severity);
- if (sev >= GHES_SEV_PANIC) {
- oops_begin();
- ghes_print_queued_estatus();
- __ghes_panic(ghes);
- }
-
- if (!(ghes->flags & GHES_TO_CLEAR))
- continue;
-
- __process_error(ghes);
- ghes_clear_estatus(ghes);
- }
+ if (!ghes_estatus_queue_notified(&ghes_nmi))
+ ret = NMI_HANDLED;
-#ifdef CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG
- if (ret == NMI_HANDLED)
- irq_work_queue(&ghes_proc_irq_work);
-#endif
atomic_dec(&ghes_in_nmi);
return ret;
}
static void ghes_nmi_add(struct ghes *ghes)
{
- unsigned long len;
+ ghes_estatus_queue_grow_pool(ghes);
- len = ghes_esource_prealloc_size(ghes->generic);
- ghes_estatus_pool_expand(len);
mutex_lock(&ghes_list_mutex);
if (list_empty(&ghes_nmi))
register_nmi_handler(NMI_LOCAL, ghes_notify_nmi, 0, "ghes");
@@ -1018,8 +1053,6 @@ static void ghes_nmi_add(struct ghes *ghes)
static void ghes_nmi_remove(struct ghes *ghes)
{
- unsigned long len;
-
mutex_lock(&ghes_list_mutex);
list_del_rcu(&ghes->list);
if (list_empty(&ghes_nmi))
@@ -1030,8 +1063,8 @@ static void ghes_nmi_remove(struct ghes *ghes)
* freed after NMI handler finishes.
*/
synchronize_rcu();
- len = ghes_esource_prealloc_size(ghes->generic);
- ghes_estatus_pool_shrink(len);
+
+ ghes_estatus_queue_shrink_pool(ghes);
}
#else /* CONFIG_HAVE_ACPI_APEI_NMI */
--
2.15.1
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH 03/11] ACPI / APEI: Switch NOTIFY_SEA to use the estatus queue
2018-02-15 18:55 ` James Morse
(?)
@ 2018-02-15 18:55 ` James Morse
-1 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-02-15 18:55 UTC (permalink / raw)
To: linux-acpi
Cc: kvmarm, linux-arm-kernel, linux-mm, Borislav Petkov,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
Naoya Horiguchi, Rafael Wysocki, Len Brown, Tony Luck,
Tyler Baicar, Dongjiu Geng, Xie XiuQi, Punit Agrawal,
James Morse
Now that the estatus queue can be used by more than one notification
method, we can move notifications that have NMI-like behaviour over to
it, and start abstracting GHES's single in_nmi() path.
Switch NOTIFY_SEA over to use the estatus queue. This makes it behave
in the same way as x86's NOTIFY_NMI.
Signed-off-by: James Morse <james.morse@arm.com>
CC: Tyler Baicar <tbaicar@codeaurora.org>
---
drivers/acpi/apei/ghes.c | 23 +++++++++++------------
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index d3cc5bd5b496..7b2504aa23b1 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -59,6 +59,10 @@
#define GHES_PFX "GHES: "
+#if defined(CONFIG_HAVE_ACPI_APEI_NMI) || defined(CONFIG_ACPI_APEI_SEA)
+#define WANT_NMI_ESTATUS_QUEUE 1
+#endif
+
#define GHES_ESTATUS_MAX_SIZE 65536
#define GHES_ESOURCE_PREALLOC_MAX_SIZE 65536
@@ -682,7 +686,7 @@ static void ghes_estatus_cache_add(
rcu_read_unlock();
}
-#ifdef CONFIG_HAVE_ACPI_APEI_NMI
+#ifdef WANT_NMI_ESTATUS_QUEUE
/*
* While printk() now has an in_nmi() path, the handling for CPER records
* does not. For example, memory_failure_queue() takes spinlocks and calls
@@ -870,7 +874,7 @@ static void ghes_nmi_init_cxt(void)
#else
static inline void ghes_nmi_init_cxt(void) { }
-#endif /* CONFIG_HAVE_ACPI_APEI_NMI */
+#endif /* WANT_NMI_ESTATUS_QUEUE */
static int ghes_ack_error(struct acpi_hest_generic_v2 *gv2)
{
@@ -986,20 +990,13 @@ static LIST_HEAD(ghes_sea);
*/
int ghes_notify_sea(void)
{
- struct ghes *ghes;
- int ret = -ENOENT;
-
- rcu_read_lock();
- list_for_each_entry_rcu(ghes, &ghes_sea, list) {
- if (!ghes_proc(ghes))
- ret = 0;
- }
- rcu_read_unlock();
- return ret;
+ return ghes_estatus_queue_notified(&ghes_sea);
}
static void ghes_sea_add(struct ghes *ghes)
{
+ ghes_estatus_queue_grow_pool(ghes);
+
mutex_lock(&ghes_list_mutex);
list_add_rcu(&ghes->list, &ghes_sea);
mutex_unlock(&ghes_list_mutex);
@@ -1011,6 +1008,8 @@ static void ghes_sea_remove(struct ghes *ghes)
list_del_rcu(&ghes->list);
mutex_unlock(&ghes_list_mutex);
synchronize_rcu();
+
+ ghes_estatus_queue_shrink_pool(ghes);
}
#else /* CONFIG_ACPI_APEI_SEA */
static inline void ghes_sea_add(struct ghes *ghes) { }
--
2.15.1
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH 03/11] ACPI / APEI: Switch NOTIFY_SEA to use the estatus queue
@ 2018-02-15 18:55 ` James Morse
0 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-02-15 18:55 UTC (permalink / raw)
To: linux-acpi
Cc: kvmarm, linux-arm-kernel, linux-mm, Borislav Petkov,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
Naoya Horiguchi, Rafael Wysocki, Len Brown, Tony Luck,
Tyler Baicar, Dongjiu Geng, Xie XiuQi, Punit Agrawal,
James Morse
Now that the estatus queue can be used by more than one notification
method, we can move notifications that have NMI-like behaviour over to
it, and start abstracting GHES's single in_nmi() path.
Switch NOTIFY_SEA over to use the estatus queue. This makes it behave
in the same way as x86's NOTIFY_NMI.
Signed-off-by: James Morse <james.morse@arm.com>
CC: Tyler Baicar <tbaicar@codeaurora.org>
---
drivers/acpi/apei/ghes.c | 23 +++++++++++------------
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index d3cc5bd5b496..7b2504aa23b1 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -59,6 +59,10 @@
#define GHES_PFX "GHES: "
+#if defined(CONFIG_HAVE_ACPI_APEI_NMI) || defined(CONFIG_ACPI_APEI_SEA)
+#define WANT_NMI_ESTATUS_QUEUE 1
+#endif
+
#define GHES_ESTATUS_MAX_SIZE 65536
#define GHES_ESOURCE_PREALLOC_MAX_SIZE 65536
@@ -682,7 +686,7 @@ static void ghes_estatus_cache_add(
rcu_read_unlock();
}
-#ifdef CONFIG_HAVE_ACPI_APEI_NMI
+#ifdef WANT_NMI_ESTATUS_QUEUE
/*
* While printk() now has an in_nmi() path, the handling for CPER records
* does not. For example, memory_failure_queue() takes spinlocks and calls
@@ -870,7 +874,7 @@ static void ghes_nmi_init_cxt(void)
#else
static inline void ghes_nmi_init_cxt(void) { }
-#endif /* CONFIG_HAVE_ACPI_APEI_NMI */
+#endif /* WANT_NMI_ESTATUS_QUEUE */
static int ghes_ack_error(struct acpi_hest_generic_v2 *gv2)
{
@@ -986,20 +990,13 @@ static LIST_HEAD(ghes_sea);
*/
int ghes_notify_sea(void)
{
- struct ghes *ghes;
- int ret = -ENOENT;
-
- rcu_read_lock();
- list_for_each_entry_rcu(ghes, &ghes_sea, list) {
- if (!ghes_proc(ghes))
- ret = 0;
- }
- rcu_read_unlock();
- return ret;
+ return ghes_estatus_queue_notified(&ghes_sea);
}
static void ghes_sea_add(struct ghes *ghes)
{
+ ghes_estatus_queue_grow_pool(ghes);
+
mutex_lock(&ghes_list_mutex);
list_add_rcu(&ghes->list, &ghes_sea);
mutex_unlock(&ghes_list_mutex);
@@ -1011,6 +1008,8 @@ static void ghes_sea_remove(struct ghes *ghes)
list_del_rcu(&ghes->list);
mutex_unlock(&ghes_list_mutex);
synchronize_rcu();
+
+ ghes_estatus_queue_shrink_pool(ghes);
}
#else /* CONFIG_ACPI_APEI_SEA */
static inline void ghes_sea_add(struct ghes *ghes) { }
--
2.15.1
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH 03/11] ACPI / APEI: Switch NOTIFY_SEA to use the estatus queue
@ 2018-02-15 18:55 ` James Morse
0 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-02-15 18:55 UTC (permalink / raw)
To: linux-arm-kernel
Now that the estatus queue can be used by more than one notification
method, we can move notifications that have NMI-like behaviour over to
it, and start abstracting GHES's single in_nmi() path.
Switch NOTIFY_SEA over to use the estatus queue. This makes it behave
in the same way as x86's NOTIFY_NMI.
Signed-off-by: James Morse <james.morse@arm.com>
CC: Tyler Baicar <tbaicar@codeaurora.org>
---
drivers/acpi/apei/ghes.c | 23 +++++++++++------------
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index d3cc5bd5b496..7b2504aa23b1 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -59,6 +59,10 @@
#define GHES_PFX "GHES: "
+#if defined(CONFIG_HAVE_ACPI_APEI_NMI) || defined(CONFIG_ACPI_APEI_SEA)
+#define WANT_NMI_ESTATUS_QUEUE 1
+#endif
+
#define GHES_ESTATUS_MAX_SIZE 65536
#define GHES_ESOURCE_PREALLOC_MAX_SIZE 65536
@@ -682,7 +686,7 @@ static void ghes_estatus_cache_add(
rcu_read_unlock();
}
-#ifdef CONFIG_HAVE_ACPI_APEI_NMI
+#ifdef WANT_NMI_ESTATUS_QUEUE
/*
* While printk() now has an in_nmi() path, the handling for CPER records
* does not. For example, memory_failure_queue() takes spinlocks and calls
@@ -870,7 +874,7 @@ static void ghes_nmi_init_cxt(void)
#else
static inline void ghes_nmi_init_cxt(void) { }
-#endif /* CONFIG_HAVE_ACPI_APEI_NMI */
+#endif /* WANT_NMI_ESTATUS_QUEUE */
static int ghes_ack_error(struct acpi_hest_generic_v2 *gv2)
{
@@ -986,20 +990,13 @@ static LIST_HEAD(ghes_sea);
*/
int ghes_notify_sea(void)
{
- struct ghes *ghes;
- int ret = -ENOENT;
-
- rcu_read_lock();
- list_for_each_entry_rcu(ghes, &ghes_sea, list) {
- if (!ghes_proc(ghes))
- ret = 0;
- }
- rcu_read_unlock();
- return ret;
+ return ghes_estatus_queue_notified(&ghes_sea);
}
static void ghes_sea_add(struct ghes *ghes)
{
+ ghes_estatus_queue_grow_pool(ghes);
+
mutex_lock(&ghes_list_mutex);
list_add_rcu(&ghes->list, &ghes_sea);
mutex_unlock(&ghes_list_mutex);
@@ -1011,6 +1008,8 @@ static void ghes_sea_remove(struct ghes *ghes)
list_del_rcu(&ghes->list);
mutex_unlock(&ghes_list_mutex);
synchronize_rcu();
+
+ ghes_estatus_queue_shrink_pool(ghes);
}
#else /* CONFIG_ACPI_APEI_SEA */
static inline void ghes_sea_add(struct ghes *ghes) { }
--
2.15.1
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH 04/11] KVM: arm/arm64: Add kvm_ras.h to collect kvm specific RAS plumbing
2018-02-15 18:55 ` James Morse
@ 2018-02-15 18:55 ` James Morse
-1 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-02-15 18:55 UTC (permalink / raw)
To: linux-acpi
Cc: kvmarm, linux-arm-kernel, linux-mm, Borislav Petkov,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
Naoya Horiguchi, Rafael Wysocki, Len Brown, Tony Luck,
Tyler Baicar, Dongjiu Geng, Xie XiuQi, Punit Agrawal,
James Morse
To split up APEIs in_nmi() path, we need any nmi-like callers to always
be in_nmi(). KVM shouldn't have to know about this, pull the RAS plumbing
out into a header file.
Currently guest synchronous external aborts are claimed as RAS
notifications by handle_guest_sea(), which is hidden in the arch codes
mm/fault.c. 32bit gets a dummy declaration in system_misc.h.
There is going to be more of this in the future if/when we support
the SError-based firmware-first notification mechanism and/or
kernel-first notifications for both synchronous external abort and
SError. Each of these will come with some Kconfig symbols and a
handful of header files.
Create a header file for all this.
This patch gives handle_guest_sea() a 'kvm_' prefix, and moves the
declarations to kvm_ras.h as preparation for a future patch that moves
the ACPI-specific RAS code out of mm/fault.c.
Signed-off-by: James Morse <james.morse@arm.com>
CC: Tyler Baicar <tbaicar@codeaurora.org>
---
arch/arm/include/asm/kvm_ras.h | 14 ++++++++++++++
arch/arm/include/asm/system_misc.h | 5 -----
arch/arm64/include/asm/kvm_ras.h | 11 +++++++++++
arch/arm64/include/asm/system_misc.h | 2 --
arch/arm64/mm/fault.c | 2 +-
virt/kvm/arm/mmu.c | 4 ++--
6 files changed, 28 insertions(+), 10 deletions(-)
create mode 100644 arch/arm/include/asm/kvm_ras.h
create mode 100644 arch/arm64/include/asm/kvm_ras.h
diff --git a/arch/arm/include/asm/kvm_ras.h b/arch/arm/include/asm/kvm_ras.h
new file mode 100644
index 000000000000..aaff56bf338f
--- /dev/null
+++ b/arch/arm/include/asm/kvm_ras.h
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 - Arm Ltd
+
+#ifndef __ARM_KVM_RAS_H__
+#define __ARM_KVM_RAS_H__
+
+#include <linux/types.h>
+
+static inline int kvm_handle_guest_sea(phys_addr_t addr, unsigned int esr)
+{
+ return -1;
+}
+
+#endif /* __ARM_KVM_RAS_H__ */
diff --git a/arch/arm/include/asm/system_misc.h b/arch/arm/include/asm/system_misc.h
index 78f6db114faf..51e5ab50b35f 100644
--- a/arch/arm/include/asm/system_misc.h
+++ b/arch/arm/include/asm/system_misc.h
@@ -23,11 +23,6 @@ extern void (*arm_pm_idle)(void);
extern unsigned int user_debug;
-static inline int handle_guest_sea(phys_addr_t addr, unsigned int esr)
-{
- return -1;
-}
-
#endif /* !__ASSEMBLY__ */
#endif /* __ASM_ARM_SYSTEM_MISC_H */
diff --git a/arch/arm64/include/asm/kvm_ras.h b/arch/arm64/include/asm/kvm_ras.h
new file mode 100644
index 000000000000..5f72b07b7912
--- /dev/null
+++ b/arch/arm64/include/asm/kvm_ras.h
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 - Arm Ltd
+
+#ifndef __ARM64_KVM_RAS_H__
+#define __ARM64_KVM_RAS_H__
+
+#include <linux/types.h>
+
+int kvm_handle_guest_sea(phys_addr_t addr, unsigned int esr);
+
+#endif /* __ARM64_KVM_RAS_H__ */
diff --git a/arch/arm64/include/asm/system_misc.h b/arch/arm64/include/asm/system_misc.h
index 07aa8e3c5630..d0beefeb6d25 100644
--- a/arch/arm64/include/asm/system_misc.h
+++ b/arch/arm64/include/asm/system_misc.h
@@ -56,8 +56,6 @@ extern void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
__show_ratelimited; \
})
-int handle_guest_sea(phys_addr_t addr, unsigned int esr);
-
#endif /* __ASSEMBLY__ */
#endif /* __ASM_SYSTEM_MISC_H */
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index f76bb2c3c943..adac28ce9be3 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -673,7 +673,7 @@ static const struct fault_info fault_info[] = {
{ do_bad, SIGBUS, BUS_FIXME, "unknown 63" },
};
-int handle_guest_sea(phys_addr_t addr, unsigned int esr)
+int kvm_handle_guest_sea(phys_addr_t addr, unsigned int esr)
{
int ret = -ENOENT;
diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
index ec62d1cccab7..8ae691194170 100644
--- a/virt/kvm/arm/mmu.c
+++ b/virt/kvm/arm/mmu.c
@@ -27,10 +27,10 @@
#include <asm/kvm_arm.h>
#include <asm/kvm_mmu.h>
#include <asm/kvm_mmio.h>
+#include <asm/kvm_ras.h>
#include <asm/kvm_asm.h>
#include <asm/kvm_emulate.h>
#include <asm/virt.h>
-#include <asm/system_misc.h>
#include "trace.h"
@@ -1535,7 +1535,7 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu, struct kvm_run *run)
* For RAS the host kernel may handle this abort.
* There is no need to pass the error into the guest.
*/
- if (!handle_guest_sea(fault_ipa, kvm_vcpu_get_hsr(vcpu)))
+ if (!kvm_handle_guest_sea(fault_ipa, kvm_vcpu_get_hsr(vcpu)))
return 1;
if (unlikely(!is_iabt)) {
--
2.15.1
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH 04/11] KVM: arm/arm64: Add kvm_ras.h to collect kvm specific RAS plumbing
@ 2018-02-15 18:55 ` James Morse
0 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-02-15 18:55 UTC (permalink / raw)
To: linux-arm-kernel
To split up APEIs in_nmi() path, we need any nmi-like callers to always
be in_nmi(). KVM shouldn't have to know about this, pull the RAS plumbing
out into a header file.
Currently guest synchronous external aborts are claimed as RAS
notifications by handle_guest_sea(), which is hidden in the arch codes
mm/fault.c. 32bit gets a dummy declaration in system_misc.h.
There is going to be more of this in the future if/when we support
the SError-based firmware-first notification mechanism and/or
kernel-first notifications for both synchronous external abort and
SError. Each of these will come with some Kconfig symbols and a
handful of header files.
Create a header file for all this.
This patch gives handle_guest_sea() a 'kvm_' prefix, and moves the
declarations to kvm_ras.h as preparation for a future patch that moves
the ACPI-specific RAS code out of mm/fault.c.
Signed-off-by: James Morse <james.morse@arm.com>
CC: Tyler Baicar <tbaicar@codeaurora.org>
---
arch/arm/include/asm/kvm_ras.h | 14 ++++++++++++++
arch/arm/include/asm/system_misc.h | 5 -----
arch/arm64/include/asm/kvm_ras.h | 11 +++++++++++
arch/arm64/include/asm/system_misc.h | 2 --
arch/arm64/mm/fault.c | 2 +-
virt/kvm/arm/mmu.c | 4 ++--
6 files changed, 28 insertions(+), 10 deletions(-)
create mode 100644 arch/arm/include/asm/kvm_ras.h
create mode 100644 arch/arm64/include/asm/kvm_ras.h
diff --git a/arch/arm/include/asm/kvm_ras.h b/arch/arm/include/asm/kvm_ras.h
new file mode 100644
index 000000000000..aaff56bf338f
--- /dev/null
+++ b/arch/arm/include/asm/kvm_ras.h
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 - Arm Ltd
+
+#ifndef __ARM_KVM_RAS_H__
+#define __ARM_KVM_RAS_H__
+
+#include <linux/types.h>
+
+static inline int kvm_handle_guest_sea(phys_addr_t addr, unsigned int esr)
+{
+ return -1;
+}
+
+#endif /* __ARM_KVM_RAS_H__ */
diff --git a/arch/arm/include/asm/system_misc.h b/arch/arm/include/asm/system_misc.h
index 78f6db114faf..51e5ab50b35f 100644
--- a/arch/arm/include/asm/system_misc.h
+++ b/arch/arm/include/asm/system_misc.h
@@ -23,11 +23,6 @@ extern void (*arm_pm_idle)(void);
extern unsigned int user_debug;
-static inline int handle_guest_sea(phys_addr_t addr, unsigned int esr)
-{
- return -1;
-}
-
#endif /* !__ASSEMBLY__ */
#endif /* __ASM_ARM_SYSTEM_MISC_H */
diff --git a/arch/arm64/include/asm/kvm_ras.h b/arch/arm64/include/asm/kvm_ras.h
new file mode 100644
index 000000000000..5f72b07b7912
--- /dev/null
+++ b/arch/arm64/include/asm/kvm_ras.h
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 - Arm Ltd
+
+#ifndef __ARM64_KVM_RAS_H__
+#define __ARM64_KVM_RAS_H__
+
+#include <linux/types.h>
+
+int kvm_handle_guest_sea(phys_addr_t addr, unsigned int esr);
+
+#endif /* __ARM64_KVM_RAS_H__ */
diff --git a/arch/arm64/include/asm/system_misc.h b/arch/arm64/include/asm/system_misc.h
index 07aa8e3c5630..d0beefeb6d25 100644
--- a/arch/arm64/include/asm/system_misc.h
+++ b/arch/arm64/include/asm/system_misc.h
@@ -56,8 +56,6 @@ extern void (*arm_pm_restart)(enum reboot_mode reboot_mode, const char *cmd);
__show_ratelimited; \
})
-int handle_guest_sea(phys_addr_t addr, unsigned int esr);
-
#endif /* __ASSEMBLY__ */
#endif /* __ASM_SYSTEM_MISC_H */
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index f76bb2c3c943..adac28ce9be3 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -673,7 +673,7 @@ static const struct fault_info fault_info[] = {
{ do_bad, SIGBUS, BUS_FIXME, "unknown 63" },
};
-int handle_guest_sea(phys_addr_t addr, unsigned int esr)
+int kvm_handle_guest_sea(phys_addr_t addr, unsigned int esr)
{
int ret = -ENOENT;
diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
index ec62d1cccab7..8ae691194170 100644
--- a/virt/kvm/arm/mmu.c
+++ b/virt/kvm/arm/mmu.c
@@ -27,10 +27,10 @@
#include <asm/kvm_arm.h>
#include <asm/kvm_mmu.h>
#include <asm/kvm_mmio.h>
+#include <asm/kvm_ras.h>
#include <asm/kvm_asm.h>
#include <asm/kvm_emulate.h>
#include <asm/virt.h>
-#include <asm/system_misc.h>
#include "trace.h"
@@ -1535,7 +1535,7 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu, struct kvm_run *run)
* For RAS the host kernel may handle this abort.
* There is no need to pass the error into the guest.
*/
- if (!handle_guest_sea(fault_ipa, kvm_vcpu_get_hsr(vcpu)))
+ if (!kvm_handle_guest_sea(fault_ipa, kvm_vcpu_get_hsr(vcpu)))
return 1;
if (unlikely(!is_iabt)) {
--
2.15.1
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH 05/11] arm64: KVM/mm: Move SEA handling behind a single 'claim' interface
2018-02-15 18:55 ` James Morse
@ 2018-02-15 18:56 ` James Morse
-1 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-02-15 18:56 UTC (permalink / raw)
To: linux-acpi
Cc: kvmarm, linux-arm-kernel, linux-mm, Borislav Petkov,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
Naoya Horiguchi, Rafael Wysocki, Len Brown, Tony Luck,
Tyler Baicar, Dongjiu Geng, Xie XiuQi, Punit Agrawal,
James Morse
To split up APEIs in_nmi() path, we need the nmi-like callers to always
be in_nmi(). Add a helper to do the work and claim the notification.
When KVM or the arch code takes an exception that might be a RAS
notification, it asks the APEI firmware-first code whether it wants
to claim the exception. We can then go on to see if (a future)
kernel-first mechanism wants to claim the notification, before
falling through to the existing default behaviour.
The NOTIFY_SEA code was merged before we had multiple, possibly
interacting, NMI-like notifications and the need to consider kernel
first in the future. Make the 'claiming' behaviour explicit.
As we're restructuring the APEI code to allow multiple NMI-like
notifications, any notification that might interrupt interrupts-masked
code must always be wrapped in nmi_enter()/nmi_exit(). This allows APEI
to use in_nmi() so choose between the raw/regular spinlock routines.
We mask SError over this window to prevent an asynchronous RAS error
arriving and tripping 'nmi_enter()'s BUG_ON(in_nmi()).
Signed-off-by: James Morse <james.morse@arm.com>
CC: Tyler Baicar <tbaicar@codeaurora.org>
---
Why does apei_claim_sea() take a pt_regs? This gets used later to take
APEI by the hand through NMI->IRQ context, depending on what we
interrupted.
arch/arm64/include/asm/acpi.h | 3 +++
arch/arm64/include/asm/daifflags.h | 1 +
arch/arm64/include/asm/kvm_ras.h | 20 +++++++++++++++++++-
arch/arm64/kernel/acpi.c | 30 ++++++++++++++++++++++++++++++
arch/arm64/mm/fault.c | 31 +++++++------------------------
5 files changed, 60 insertions(+), 25 deletions(-)
diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index 32f465a80e4e..256811cd4b8b 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -16,6 +16,7 @@
#include <linux/psci.h>
#include <asm/cputype.h>
+#include <asm/ptrace.h>
#include <asm/smp_plat.h>
#include <asm/tlbflush.h>
@@ -94,6 +95,8 @@ void __init acpi_init_cpus(void);
static inline void acpi_init_cpus(void) { }
#endif /* CONFIG_ACPI */
+int apei_claim_sea(struct pt_regs *regs);
+
#ifdef CONFIG_ARM64_ACPI_PARKING_PROTOCOL
bool acpi_parking_protocol_valid(int cpu);
void __init
diff --git a/arch/arm64/include/asm/daifflags.h b/arch/arm64/include/asm/daifflags.h
index 22e4c83de5a5..cbd753855bf3 100644
--- a/arch/arm64/include/asm/daifflags.h
+++ b/arch/arm64/include/asm/daifflags.h
@@ -20,6 +20,7 @@
#define DAIF_PROCCTX 0
#define DAIF_PROCCTX_NOIRQ PSR_I_BIT
+#define DAIF_ERRCTX (PSR_I_BIT | PSR_A_BIT)
/* mask/save/unmask/restore all exceptions, including interrupts. */
static inline void local_daif_mask(void)
diff --git a/arch/arm64/include/asm/kvm_ras.h b/arch/arm64/include/asm/kvm_ras.h
index 5f72b07b7912..9d52bc333110 100644
--- a/arch/arm64/include/asm/kvm_ras.h
+++ b/arch/arm64/include/asm/kvm_ras.h
@@ -4,8 +4,26 @@
#ifndef __ARM64_KVM_RAS_H__
#define __ARM64_KVM_RAS_H__
+#include <linux/acpi.h>
+#include <linux/errno.h>
#include <linux/types.h>
-int kvm_handle_guest_sea(phys_addr_t addr, unsigned int esr);
+#include <asm/acpi.h>
+
+/*
+ * Was this synchronous external abort a RAS notification?
+ * Returns '0' for errors handled by some RAS subsystem, or -ENOENT.
+ *
+ * Call with irqs unmaksed.
+ */
+static inline int kvm_handle_guest_sea(phys_addr_t addr, unsigned int esr)
+{
+ int ret = -ENOENT;
+
+ if (IS_ENABLED(CONFIG_ACPI_APEI_SEA))
+ ret = apei_claim_sea(NULL);
+
+ return ret;
+}
#endif /* __ARM64_KVM_RAS_H__ */
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 7b09487ff8fb..6a4823a3eb5e 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -33,6 +33,8 @@
#ifdef CONFIG_ACPI_APEI
# include <linux/efi.h>
+# include <acpi/ghes.h>
+# include <asm/daifflags.h>
# include <asm/pgtable.h>
#endif
@@ -261,4 +263,32 @@ pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr)
return __pgprot(PROT_NORMAL_NC);
return __pgprot(PROT_DEVICE_nGnRnE);
}
+
+
+/*
+ * Claim Synchronous External Aborts as a firmware first notification.
+ *
+ * Used by KVM and the arch do_sea handler.
+ * @regs may be NULL when called from process context.
+ */
+int apei_claim_sea(struct pt_regs *regs)
+{
+ int err = -ENOENT;
+ unsigned long current_flags = arch_local_save_flags();
+
+ if (!IS_ENABLED(CONFIG_ACPI_APEI_SEA))
+ return err;
+
+ /*
+ * APEI expects an NMI-like notification to always be called
+ * in NMI context.
+ */
+ local_daif_restore(DAIF_ERRCTX);
+ nmi_enter();
+ err = ghes_notify_sea();
+ nmi_exit();
+ local_daif_restore(current_flags);
+
+ return err;
+}
#endif
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index adac28ce9be3..8cbbd9a5ec7d 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -18,6 +18,7 @@
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
+#include <linux/acpi.h>
#include <linux/extable.h>
#include <linux/signal.h>
#include <linux/mm.h>
@@ -33,6 +34,7 @@
#include <linux/preempt.h>
#include <linux/hugetlb.h>
+#include <asm/acpi.h>
#include <asm/bug.h>
#include <asm/cmpxchg.h>
#include <asm/cpufeature.h>
@@ -44,8 +46,6 @@
#include <asm/pgtable.h>
#include <asm/tlbflush.h>
-#include <acpi/ghes.h>
-
struct fault_info {
int (*fn)(unsigned long addr, unsigned int esr,
struct pt_regs *regs);
@@ -579,19 +579,12 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
pr_err("Synchronous External Abort: %s (0x%08x) at 0x%016lx\n",
inf->name, esr, addr);
- /*
- * Synchronous aborts may interrupt code which had interrupts masked.
- * Before calling out into the wider kernel tell the interested
- * subsystems.
- */
if (IS_ENABLED(CONFIG_ACPI_APEI_SEA)) {
- if (interrupts_enabled(regs))
- nmi_enter();
-
- ghes_notify_sea();
-
- if (interrupts_enabled(regs))
- nmi_exit();
+ /*
+ * Return value ignored as we rely on signal merging.
+ * Future patches will make this more robust.
+ */
+ apei_claim_sea(regs);
}
info.si_signo = SIGBUS;
@@ -673,16 +666,6 @@ static const struct fault_info fault_info[] = {
{ do_bad, SIGBUS, BUS_FIXME, "unknown 63" },
};
-int kvm_handle_guest_sea(phys_addr_t addr, unsigned int esr)
-{
- int ret = -ENOENT;
-
- if (IS_ENABLED(CONFIG_ACPI_APEI_SEA))
- ret = ghes_notify_sea();
-
- return ret;
-}
-
asmlinkage void __exception do_mem_abort(unsigned long addr, unsigned int esr,
struct pt_regs *regs)
{
--
2.15.1
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH 05/11] arm64: KVM/mm: Move SEA handling behind a single 'claim' interface
@ 2018-02-15 18:56 ` James Morse
0 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-02-15 18:56 UTC (permalink / raw)
To: linux-arm-kernel
To split up APEIs in_nmi() path, we need the nmi-like callers to always
be in_nmi(). Add a helper to do the work and claim the notification.
When KVM or the arch code takes an exception that might be a RAS
notification, it asks the APEI firmware-first code whether it wants
to claim the exception. We can then go on to see if (a future)
kernel-first mechanism wants to claim the notification, before
falling through to the existing default behaviour.
The NOTIFY_SEA code was merged before we had multiple, possibly
interacting, NMI-like notifications and the need to consider kernel
first in the future. Make the 'claiming' behaviour explicit.
As we're restructuring the APEI code to allow multiple NMI-like
notifications, any notification that might interrupt interrupts-masked
code must always be wrapped in nmi_enter()/nmi_exit(). This allows APEI
to use in_nmi() so choose between the raw/regular spinlock routines.
We mask SError over this window to prevent an asynchronous RAS error
arriving and tripping 'nmi_enter()'s BUG_ON(in_nmi()).
Signed-off-by: James Morse <james.morse@arm.com>
CC: Tyler Baicar <tbaicar@codeaurora.org>
---
Why does apei_claim_sea() take a pt_regs? This gets used later to take
APEI by the hand through NMI->IRQ context, depending on what we
interrupted.
arch/arm64/include/asm/acpi.h | 3 +++
arch/arm64/include/asm/daifflags.h | 1 +
arch/arm64/include/asm/kvm_ras.h | 20 +++++++++++++++++++-
arch/arm64/kernel/acpi.c | 30 ++++++++++++++++++++++++++++++
arch/arm64/mm/fault.c | 31 +++++++------------------------
5 files changed, 60 insertions(+), 25 deletions(-)
diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index 32f465a80e4e..256811cd4b8b 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -16,6 +16,7 @@
#include <linux/psci.h>
#include <asm/cputype.h>
+#include <asm/ptrace.h>
#include <asm/smp_plat.h>
#include <asm/tlbflush.h>
@@ -94,6 +95,8 @@ void __init acpi_init_cpus(void);
static inline void acpi_init_cpus(void) { }
#endif /* CONFIG_ACPI */
+int apei_claim_sea(struct pt_regs *regs);
+
#ifdef CONFIG_ARM64_ACPI_PARKING_PROTOCOL
bool acpi_parking_protocol_valid(int cpu);
void __init
diff --git a/arch/arm64/include/asm/daifflags.h b/arch/arm64/include/asm/daifflags.h
index 22e4c83de5a5..cbd753855bf3 100644
--- a/arch/arm64/include/asm/daifflags.h
+++ b/arch/arm64/include/asm/daifflags.h
@@ -20,6 +20,7 @@
#define DAIF_PROCCTX 0
#define DAIF_PROCCTX_NOIRQ PSR_I_BIT
+#define DAIF_ERRCTX (PSR_I_BIT | PSR_A_BIT)
/* mask/save/unmask/restore all exceptions, including interrupts. */
static inline void local_daif_mask(void)
diff --git a/arch/arm64/include/asm/kvm_ras.h b/arch/arm64/include/asm/kvm_ras.h
index 5f72b07b7912..9d52bc333110 100644
--- a/arch/arm64/include/asm/kvm_ras.h
+++ b/arch/arm64/include/asm/kvm_ras.h
@@ -4,8 +4,26 @@
#ifndef __ARM64_KVM_RAS_H__
#define __ARM64_KVM_RAS_H__
+#include <linux/acpi.h>
+#include <linux/errno.h>
#include <linux/types.h>
-int kvm_handle_guest_sea(phys_addr_t addr, unsigned int esr);
+#include <asm/acpi.h>
+
+/*
+ * Was this synchronous external abort a RAS notification?
+ * Returns '0' for errors handled by some RAS subsystem, or -ENOENT.
+ *
+ * Call with irqs unmaksed.
+ */
+static inline int kvm_handle_guest_sea(phys_addr_t addr, unsigned int esr)
+{
+ int ret = -ENOENT;
+
+ if (IS_ENABLED(CONFIG_ACPI_APEI_SEA))
+ ret = apei_claim_sea(NULL);
+
+ return ret;
+}
#endif /* __ARM64_KVM_RAS_H__ */
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 7b09487ff8fb..6a4823a3eb5e 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -33,6 +33,8 @@
#ifdef CONFIG_ACPI_APEI
# include <linux/efi.h>
+# include <acpi/ghes.h>
+# include <asm/daifflags.h>
# include <asm/pgtable.h>
#endif
@@ -261,4 +263,32 @@ pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr)
return __pgprot(PROT_NORMAL_NC);
return __pgprot(PROT_DEVICE_nGnRnE);
}
+
+
+/*
+ * Claim Synchronous External Aborts as a firmware first notification.
+ *
+ * Used by KVM and the arch do_sea handler.
+ * @regs may be NULL when called from process context.
+ */
+int apei_claim_sea(struct pt_regs *regs)
+{
+ int err = -ENOENT;
+ unsigned long current_flags = arch_local_save_flags();
+
+ if (!IS_ENABLED(CONFIG_ACPI_APEI_SEA))
+ return err;
+
+ /*
+ * APEI expects an NMI-like notification to always be called
+ * in NMI context.
+ */
+ local_daif_restore(DAIF_ERRCTX);
+ nmi_enter();
+ err = ghes_notify_sea();
+ nmi_exit();
+ local_daif_restore(current_flags);
+
+ return err;
+}
#endif
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index adac28ce9be3..8cbbd9a5ec7d 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -18,6 +18,7 @@
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
+#include <linux/acpi.h>
#include <linux/extable.h>
#include <linux/signal.h>
#include <linux/mm.h>
@@ -33,6 +34,7 @@
#include <linux/preempt.h>
#include <linux/hugetlb.h>
+#include <asm/acpi.h>
#include <asm/bug.h>
#include <asm/cmpxchg.h>
#include <asm/cpufeature.h>
@@ -44,8 +46,6 @@
#include <asm/pgtable.h>
#include <asm/tlbflush.h>
-#include <acpi/ghes.h>
-
struct fault_info {
int (*fn)(unsigned long addr, unsigned int esr,
struct pt_regs *regs);
@@ -579,19 +579,12 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
pr_err("Synchronous External Abort: %s (0x%08x) at 0x%016lx\n",
inf->name, esr, addr);
- /*
- * Synchronous aborts may interrupt code which had interrupts masked.
- * Before calling out into the wider kernel tell the interested
- * subsystems.
- */
if (IS_ENABLED(CONFIG_ACPI_APEI_SEA)) {
- if (interrupts_enabled(regs))
- nmi_enter();
-
- ghes_notify_sea();
-
- if (interrupts_enabled(regs))
- nmi_exit();
+ /*
+ * Return value ignored as we rely on signal merging.
+ * Future patches will make this more robust.
+ */
+ apei_claim_sea(regs);
}
info.si_signo = SIGBUS;
@@ -673,16 +666,6 @@ static const struct fault_info fault_info[] = {
{ do_bad, SIGBUS, BUS_FIXME, "unknown 63" },
};
-int kvm_handle_guest_sea(phys_addr_t addr, unsigned int esr)
-{
- int ret = -ENOENT;
-
- if (IS_ENABLED(CONFIG_ACPI_APEI_SEA))
- ret = ghes_notify_sea();
-
- return ret;
-}
-
asmlinkage void __exception do_mem_abort(unsigned long addr, unsigned int esr,
struct pt_regs *regs)
{
--
2.15.1
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH 06/11] ACPI / APEI: Make the fixmap_idx per-ghes to allow multiple in_nmi() users
2018-02-15 18:55 ` James Morse
@ 2018-02-15 18:56 ` James Morse
-1 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-02-15 18:56 UTC (permalink / raw)
To: linux-acpi
Cc: kvmarm, linux-arm-kernel, linux-mm, Borislav Petkov,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
Naoya Horiguchi, Rafael Wysocki, Len Brown, Tony Luck,
Tyler Baicar, Dongjiu Geng, Xie XiuQi, Punit Agrawal,
James Morse
Arm64 has multiple NMI-like notifications, but GHES only has one
in_nmi() path. The interactions between these multiple NMI-like
notifications is, unclear.
Split this single path up by moving the fixmap idx and lock into
the struct ghes. Each notification's init function can consider
which other notifications it masks and can share a fixmap_idx with.
This lets us merge the two ghes_ioremap_pfn_* flavours.
Two lock pointers are provided, but only one will be used by
ghes_copy_tofrom_phys(), depending on in_nmi(). This means any
notification that might arrive as an NMI must always be wrapped in
nmi_enter()/nmi_exit().
The double-underscore version of fix_to_virt() is used because
the index to be mapped can't be tested against the end of the
enum at compile time.
Signed-off-by: James Morse <james.morse@arm.com>
---
drivers/acpi/apei/ghes.c | 79 ++++++++++++++++++------------------------------
include/acpi/ghes.h | 5 +++
2 files changed, 35 insertions(+), 49 deletions(-)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 7b2504aa23b1..70ccb309a9d8 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -118,12 +118,9 @@ static DEFINE_MUTEX(ghes_list_mutex);
* from BIOS to Linux can be determined only in NMI, IRQ or timer
* handler, but general ioremap can not be used in atomic context, so
* the fixmap is used instead.
- *
- * These 2 spinlocks are used to prevent the fixmap entries from being used
- * simultaneously.
*/
-static DEFINE_RAW_SPINLOCK(ghes_ioremap_lock_nmi);
-static DEFINE_SPINLOCK(ghes_ioremap_lock_irq);
+static DEFINE_RAW_SPINLOCK(ghes_fixmap_lock_nmi);
+static DEFINE_SPINLOCK(ghes_fixmap_lock_irq);
static struct gen_pool *ghes_estatus_pool;
static unsigned long ghes_estatus_pool_size_request;
@@ -133,38 +130,16 @@ static atomic_t ghes_estatus_cache_alloced;
static int ghes_panic_timeout __read_mostly = 30;
-static void __iomem *ghes_ioremap_pfn_nmi(u64 pfn)
+static void __iomem *ghes_fixmap_pfn(int fixmap_idx, u64 pfn)
{
phys_addr_t paddr;
pgprot_t prot;
paddr = pfn << PAGE_SHIFT;
prot = arch_apei_get_mem_attribute(paddr);
- __set_fixmap(FIX_APEI_GHES_NMI, paddr, prot);
-
- return (void __iomem *) fix_to_virt(FIX_APEI_GHES_NMI);
-}
-
-static void __iomem *ghes_ioremap_pfn_irq(u64 pfn)
-{
- phys_addr_t paddr;
- pgprot_t prot;
-
- paddr = pfn << PAGE_SHIFT;
- prot = arch_apei_get_mem_attribute(paddr);
- __set_fixmap(FIX_APEI_GHES_IRQ, paddr, prot);
-
- return (void __iomem *) fix_to_virt(FIX_APEI_GHES_IRQ);
-}
-
-static void ghes_iounmap_nmi(void)
-{
- clear_fixmap(FIX_APEI_GHES_NMI);
-}
+ __set_fixmap(fixmap_idx, paddr, prot);
-static void ghes_iounmap_irq(void)
-{
- clear_fixmap(FIX_APEI_GHES_IRQ);
+ return (void __iomem *) __fix_to_virt(fixmap_idx);
}
static int ghes_estatus_pool_init(void)
@@ -292,8 +267,8 @@ static inline int ghes_severity(int severity)
}
}
-static void ghes_copy_tofrom_phys(void *buffer, u64 paddr, u32 len,
- int from_phys)
+static void ghes_copy_tofrom_phys(struct ghes *ghes, void *buffer, u64 paddr,
+ u32 len, int from_phys)
{
void __iomem *vaddr;
unsigned long flags = 0;
@@ -303,13 +278,11 @@ static void ghes_copy_tofrom_phys(void *buffer, u64 paddr, u32 len,
while (len > 0) {
offset = paddr - (paddr & PAGE_MASK);
- if (in_nmi) {
- raw_spin_lock(&ghes_ioremap_lock_nmi);
- vaddr = ghes_ioremap_pfn_nmi(paddr >> PAGE_SHIFT);
- } else {
- spin_lock_irqsave(&ghes_ioremap_lock_irq, flags);
- vaddr = ghes_ioremap_pfn_irq(paddr >> PAGE_SHIFT);
- }
+ if (in_nmi)
+ raw_spin_lock(ghes->nmi_fixmap_lock);
+ else
+ spin_lock_irqsave(ghes->fixmap_lock, flags);
+ vaddr = ghes_fixmap_pfn(ghes->fixmap_idx, paddr >> PAGE_SHIFT);
trunk = PAGE_SIZE - offset;
trunk = min(trunk, len);
if (from_phys)
@@ -319,13 +292,11 @@ static void ghes_copy_tofrom_phys(void *buffer, u64 paddr, u32 len,
len -= trunk;
paddr += trunk;
buffer += trunk;
- if (in_nmi) {
- ghes_iounmap_nmi();
- raw_spin_unlock(&ghes_ioremap_lock_nmi);
- } else {
- ghes_iounmap_irq();
- spin_unlock_irqrestore(&ghes_ioremap_lock_irq, flags);
- }
+ clear_fixmap(ghes->fixmap_idx);
+ if (in_nmi)
+ raw_spin_unlock(ghes->nmi_fixmap_lock);
+ else
+ spin_unlock_irqrestore(ghes->fixmap_lock, flags);
}
}
@@ -347,7 +318,7 @@ static int ghes_read_estatus(struct ghes *ghes, int silent)
if (!buf_paddr)
return -ENOENT;
- ghes_copy_tofrom_phys(ghes->estatus, buf_paddr,
+ ghes_copy_tofrom_phys(ghes, ghes->estatus, buf_paddr,
sizeof(*ghes->estatus), 1);
if (!ghes->estatus->block_status)
return -ENOENT;
@@ -363,7 +334,7 @@ static int ghes_read_estatus(struct ghes *ghes, int silent)
goto err_read_block;
if (cper_estatus_check_header(ghes->estatus))
goto err_read_block;
- ghes_copy_tofrom_phys(ghes->estatus + 1,
+ ghes_copy_tofrom_phys(ghes, ghes->estatus + 1,
buf_paddr + sizeof(*ghes->estatus),
len - sizeof(*ghes->estatus), 1);
if (cper_estatus_check(ghes->estatus))
@@ -382,7 +353,7 @@ static void ghes_clear_estatus(struct ghes *ghes)
ghes->estatus->block_status = 0;
if (!(ghes->flags & GHES_TO_CLEAR))
return;
- ghes_copy_tofrom_phys(ghes->estatus, ghes->buffer_paddr,
+ ghes_copy_tofrom_phys(ghes, ghes->estatus, ghes->buffer_paddr,
sizeof(ghes->estatus->block_status), 0);
ghes->flags &= ~GHES_TO_CLEAR;
}
@@ -995,6 +966,8 @@ int ghes_notify_sea(void)
static void ghes_sea_add(struct ghes *ghes)
{
+ ghes->nmi_fixmap_lock = &ghes_fixmap_lock_nmi;
+ ghes->fixmap_idx = FIX_APEI_GHES_NMI;
ghes_estatus_queue_grow_pool(ghes);
mutex_lock(&ghes_list_mutex);
@@ -1041,6 +1014,8 @@ static int ghes_notify_nmi(unsigned int cmd, struct pt_regs *regs)
static void ghes_nmi_add(struct ghes *ghes)
{
+ ghes->nmi_fixmap_lock = &ghes_fixmap_lock_nmi;
+ ghes->fixmap_idx = FIX_APEI_GHES_NMI;
ghes_estatus_queue_grow_pool(ghes);
mutex_lock(&ghes_list_mutex);
@@ -1136,11 +1111,15 @@ static int ghes_probe(struct platform_device *ghes_dev)
switch (generic->notify.type) {
case ACPI_HEST_NOTIFY_POLLED:
+ ghes->fixmap_lock = &ghes_fixmap_lock_irq;
+ ghes->fixmap_idx = FIX_APEI_GHES_IRQ;
timer_setup(&ghes->timer, ghes_poll_func, TIMER_DEFERRABLE);
ghes_add_timer(ghes);
break;
case ACPI_HEST_NOTIFY_EXTERNAL:
/* External interrupt vector is GSI */
+ ghes->fixmap_lock = &ghes_fixmap_lock_irq;
+ ghes->fixmap_idx = FIX_APEI_GHES_IRQ;
rc = acpi_gsi_to_irq(generic->notify.vector, &ghes->irq);
if (rc) {
pr_err(GHES_PFX "Failed to map GSI to IRQ for generic hardware error source: %d\n",
@@ -1159,6 +1138,8 @@ static int ghes_probe(struct platform_device *ghes_dev)
case ACPI_HEST_NOTIFY_SCI:
case ACPI_HEST_NOTIFY_GSIV:
case ACPI_HEST_NOTIFY_GPIO:
+ ghes->fixmap_lock = &ghes_fixmap_lock_irq;
+ ghes->fixmap_idx = FIX_APEI_GHES_IRQ;
mutex_lock(&ghes_list_mutex);
if (list_empty(&ghes_hed))
register_acpi_hed_notifier(&ghes_notifier_hed);
diff --git a/include/acpi/ghes.h b/include/acpi/ghes.h
index 8feb0c866ee0..74dbd164f3fe 100644
--- a/include/acpi/ghes.h
+++ b/include/acpi/ghes.h
@@ -29,6 +29,11 @@ struct ghes {
struct timer_list timer;
unsigned int irq;
};
+
+ spinlock_t *fixmap_lock;
+ raw_spinlock_t *nmi_fixmap_lock;
+
+ int fixmap_idx;
};
struct ghes_estatus_node {
--
2.15.1
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH 06/11] ACPI / APEI: Make the fixmap_idx per-ghes to allow multiple in_nmi() users
@ 2018-02-15 18:56 ` James Morse
0 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-02-15 18:56 UTC (permalink / raw)
To: linux-arm-kernel
Arm64 has multiple NMI-like notifications, but GHES only has one
in_nmi() path. The interactions between these multiple NMI-like
notifications is, unclear.
Split this single path up by moving the fixmap idx and lock into
the struct ghes. Each notification's init function can consider
which other notifications it masks and can share a fixmap_idx with.
This lets us merge the two ghes_ioremap_pfn_* flavours.
Two lock pointers are provided, but only one will be used by
ghes_copy_tofrom_phys(), depending on in_nmi(). This means any
notification that might arrive as an NMI must always be wrapped in
nmi_enter()/nmi_exit().
The double-underscore version of fix_to_virt() is used because
the index to be mapped can't be tested against the end of the
enum at compile time.
Signed-off-by: James Morse <james.morse@arm.com>
---
drivers/acpi/apei/ghes.c | 79 ++++++++++++++++++------------------------------
include/acpi/ghes.h | 5 +++
2 files changed, 35 insertions(+), 49 deletions(-)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 7b2504aa23b1..70ccb309a9d8 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -118,12 +118,9 @@ static DEFINE_MUTEX(ghes_list_mutex);
* from BIOS to Linux can be determined only in NMI, IRQ or timer
* handler, but general ioremap can not be used in atomic context, so
* the fixmap is used instead.
- *
- * These 2 spinlocks are used to prevent the fixmap entries from being used
- * simultaneously.
*/
-static DEFINE_RAW_SPINLOCK(ghes_ioremap_lock_nmi);
-static DEFINE_SPINLOCK(ghes_ioremap_lock_irq);
+static DEFINE_RAW_SPINLOCK(ghes_fixmap_lock_nmi);
+static DEFINE_SPINLOCK(ghes_fixmap_lock_irq);
static struct gen_pool *ghes_estatus_pool;
static unsigned long ghes_estatus_pool_size_request;
@@ -133,38 +130,16 @@ static atomic_t ghes_estatus_cache_alloced;
static int ghes_panic_timeout __read_mostly = 30;
-static void __iomem *ghes_ioremap_pfn_nmi(u64 pfn)
+static void __iomem *ghes_fixmap_pfn(int fixmap_idx, u64 pfn)
{
phys_addr_t paddr;
pgprot_t prot;
paddr = pfn << PAGE_SHIFT;
prot = arch_apei_get_mem_attribute(paddr);
- __set_fixmap(FIX_APEI_GHES_NMI, paddr, prot);
-
- return (void __iomem *) fix_to_virt(FIX_APEI_GHES_NMI);
-}
-
-static void __iomem *ghes_ioremap_pfn_irq(u64 pfn)
-{
- phys_addr_t paddr;
- pgprot_t prot;
-
- paddr = pfn << PAGE_SHIFT;
- prot = arch_apei_get_mem_attribute(paddr);
- __set_fixmap(FIX_APEI_GHES_IRQ, paddr, prot);
-
- return (void __iomem *) fix_to_virt(FIX_APEI_GHES_IRQ);
-}
-
-static void ghes_iounmap_nmi(void)
-{
- clear_fixmap(FIX_APEI_GHES_NMI);
-}
+ __set_fixmap(fixmap_idx, paddr, prot);
-static void ghes_iounmap_irq(void)
-{
- clear_fixmap(FIX_APEI_GHES_IRQ);
+ return (void __iomem *) __fix_to_virt(fixmap_idx);
}
static int ghes_estatus_pool_init(void)
@@ -292,8 +267,8 @@ static inline int ghes_severity(int severity)
}
}
-static void ghes_copy_tofrom_phys(void *buffer, u64 paddr, u32 len,
- int from_phys)
+static void ghes_copy_tofrom_phys(struct ghes *ghes, void *buffer, u64 paddr,
+ u32 len, int from_phys)
{
void __iomem *vaddr;
unsigned long flags = 0;
@@ -303,13 +278,11 @@ static void ghes_copy_tofrom_phys(void *buffer, u64 paddr, u32 len,
while (len > 0) {
offset = paddr - (paddr & PAGE_MASK);
- if (in_nmi) {
- raw_spin_lock(&ghes_ioremap_lock_nmi);
- vaddr = ghes_ioremap_pfn_nmi(paddr >> PAGE_SHIFT);
- } else {
- spin_lock_irqsave(&ghes_ioremap_lock_irq, flags);
- vaddr = ghes_ioremap_pfn_irq(paddr >> PAGE_SHIFT);
- }
+ if (in_nmi)
+ raw_spin_lock(ghes->nmi_fixmap_lock);
+ else
+ spin_lock_irqsave(ghes->fixmap_lock, flags);
+ vaddr = ghes_fixmap_pfn(ghes->fixmap_idx, paddr >> PAGE_SHIFT);
trunk = PAGE_SIZE - offset;
trunk = min(trunk, len);
if (from_phys)
@@ -319,13 +292,11 @@ static void ghes_copy_tofrom_phys(void *buffer, u64 paddr, u32 len,
len -= trunk;
paddr += trunk;
buffer += trunk;
- if (in_nmi) {
- ghes_iounmap_nmi();
- raw_spin_unlock(&ghes_ioremap_lock_nmi);
- } else {
- ghes_iounmap_irq();
- spin_unlock_irqrestore(&ghes_ioremap_lock_irq, flags);
- }
+ clear_fixmap(ghes->fixmap_idx);
+ if (in_nmi)
+ raw_spin_unlock(ghes->nmi_fixmap_lock);
+ else
+ spin_unlock_irqrestore(ghes->fixmap_lock, flags);
}
}
@@ -347,7 +318,7 @@ static int ghes_read_estatus(struct ghes *ghes, int silent)
if (!buf_paddr)
return -ENOENT;
- ghes_copy_tofrom_phys(ghes->estatus, buf_paddr,
+ ghes_copy_tofrom_phys(ghes, ghes->estatus, buf_paddr,
sizeof(*ghes->estatus), 1);
if (!ghes->estatus->block_status)
return -ENOENT;
@@ -363,7 +334,7 @@ static int ghes_read_estatus(struct ghes *ghes, int silent)
goto err_read_block;
if (cper_estatus_check_header(ghes->estatus))
goto err_read_block;
- ghes_copy_tofrom_phys(ghes->estatus + 1,
+ ghes_copy_tofrom_phys(ghes, ghes->estatus + 1,
buf_paddr + sizeof(*ghes->estatus),
len - sizeof(*ghes->estatus), 1);
if (cper_estatus_check(ghes->estatus))
@@ -382,7 +353,7 @@ static void ghes_clear_estatus(struct ghes *ghes)
ghes->estatus->block_status = 0;
if (!(ghes->flags & GHES_TO_CLEAR))
return;
- ghes_copy_tofrom_phys(ghes->estatus, ghes->buffer_paddr,
+ ghes_copy_tofrom_phys(ghes, ghes->estatus, ghes->buffer_paddr,
sizeof(ghes->estatus->block_status), 0);
ghes->flags &= ~GHES_TO_CLEAR;
}
@@ -995,6 +966,8 @@ int ghes_notify_sea(void)
static void ghes_sea_add(struct ghes *ghes)
{
+ ghes->nmi_fixmap_lock = &ghes_fixmap_lock_nmi;
+ ghes->fixmap_idx = FIX_APEI_GHES_NMI;
ghes_estatus_queue_grow_pool(ghes);
mutex_lock(&ghes_list_mutex);
@@ -1041,6 +1014,8 @@ static int ghes_notify_nmi(unsigned int cmd, struct pt_regs *regs)
static void ghes_nmi_add(struct ghes *ghes)
{
+ ghes->nmi_fixmap_lock = &ghes_fixmap_lock_nmi;
+ ghes->fixmap_idx = FIX_APEI_GHES_NMI;
ghes_estatus_queue_grow_pool(ghes);
mutex_lock(&ghes_list_mutex);
@@ -1136,11 +1111,15 @@ static int ghes_probe(struct platform_device *ghes_dev)
switch (generic->notify.type) {
case ACPI_HEST_NOTIFY_POLLED:
+ ghes->fixmap_lock = &ghes_fixmap_lock_irq;
+ ghes->fixmap_idx = FIX_APEI_GHES_IRQ;
timer_setup(&ghes->timer, ghes_poll_func, TIMER_DEFERRABLE);
ghes_add_timer(ghes);
break;
case ACPI_HEST_NOTIFY_EXTERNAL:
/* External interrupt vector is GSI */
+ ghes->fixmap_lock = &ghes_fixmap_lock_irq;
+ ghes->fixmap_idx = FIX_APEI_GHES_IRQ;
rc = acpi_gsi_to_irq(generic->notify.vector, &ghes->irq);
if (rc) {
pr_err(GHES_PFX "Failed to map GSI to IRQ for generic hardware error source: %d\n",
@@ -1159,6 +1138,8 @@ static int ghes_probe(struct platform_device *ghes_dev)
case ACPI_HEST_NOTIFY_SCI:
case ACPI_HEST_NOTIFY_GSIV:
case ACPI_HEST_NOTIFY_GPIO:
+ ghes->fixmap_lock = &ghes_fixmap_lock_irq;
+ ghes->fixmap_idx = FIX_APEI_GHES_IRQ;
mutex_lock(&ghes_list_mutex);
if (list_empty(&ghes_hed))
register_acpi_hed_notifier(&ghes_notifier_hed);
diff --git a/include/acpi/ghes.h b/include/acpi/ghes.h
index 8feb0c866ee0..74dbd164f3fe 100644
--- a/include/acpi/ghes.h
+++ b/include/acpi/ghes.h
@@ -29,6 +29,11 @@ struct ghes {
struct timer_list timer;
unsigned int irq;
};
+
+ spinlock_t *fixmap_lock;
+ raw_spinlock_t *nmi_fixmap_lock;
+
+ int fixmap_idx;
};
struct ghes_estatus_node {
--
2.15.1
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH 07/11] ACPI / APEI: Split fixmap pages for arm64 NMI-like notifications
2018-02-15 18:55 ` James Morse
(?)
@ 2018-02-15 18:56 ` James Morse
-1 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-02-15 18:56 UTC (permalink / raw)
To: linux-acpi
Cc: kvmarm, linux-arm-kernel, linux-mm, Borislav Petkov,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
Naoya Horiguchi, Rafael Wysocki, Len Brown, Tony Luck,
Tyler Baicar, Dongjiu Geng, Xie XiuQi, Punit Agrawal,
James Morse
Now that ghes uses the fixmap addresses and locks via some indirection
we can support multiple NMI-like notifications on arm64.
These should be named after their notification method. x86's
NOTIFY_NMI already is, change the SEA fixmap entry to be called
FIX_APEI_GHES_SEA.
Future patches can add support for FIX_APEI_GHES_SEI and
FIX_APEI_GHES_SDEI_{NORMAL,CRITICAL}.
Signed-off-by: James Morse <james.morse@arm.com>
CC: Tyler Baicar <tbaicar@codeaurora.org>
---
arch/arm64/include/asm/fixmap.h | 4 +++-
drivers/acpi/apei/ghes.c | 11 ++++++-----
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/include/asm/fixmap.h b/arch/arm64/include/asm/fixmap.h
index ec1e6d6fa14c..c3974517c2cb 100644
--- a/arch/arm64/include/asm/fixmap.h
+++ b/arch/arm64/include/asm/fixmap.h
@@ -55,7 +55,9 @@ enum fixed_addresses {
#ifdef CONFIG_ACPI_APEI_GHES
/* Used for GHES mapping from assorted contexts */
FIX_APEI_GHES_IRQ,
- FIX_APEI_GHES_NMI,
+#ifdef CONFIG_ACPI_APEI_SEA
+ FIX_APEI_GHES_SEA,
+#endif
#endif /* CONFIG_ACPI_APEI_GHES */
#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 70ccb309a9d8..280c0a58c700 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -119,7 +119,6 @@ static DEFINE_MUTEX(ghes_list_mutex);
* handler, but general ioremap can not be used in atomic context, so
* the fixmap is used instead.
*/
-static DEFINE_RAW_SPINLOCK(ghes_fixmap_lock_nmi);
static DEFINE_SPINLOCK(ghes_fixmap_lock_irq);
static struct gen_pool *ghes_estatus_pool;
@@ -954,6 +953,7 @@ static struct notifier_block ghes_notifier_hed = {
#ifdef CONFIG_ACPI_APEI_SEA
static LIST_HEAD(ghes_sea);
+static DEFINE_RAW_SPINLOCK(ghes_fixmap_lock_sea);
/*
* Return 0 only if one of the SEA error sources successfully reported an error
@@ -966,8 +966,8 @@ int ghes_notify_sea(void)
static void ghes_sea_add(struct ghes *ghes)
{
- ghes->nmi_fixmap_lock = &ghes_fixmap_lock_nmi;
- ghes->fixmap_idx = FIX_APEI_GHES_NMI;
+ ghes->nmi_fixmap_lock = &ghes_fixmap_lock_sea;
+ ghes->fixmap_idx = FIX_APEI_GHES_SEA;
ghes_estatus_queue_grow_pool(ghes);
mutex_lock(&ghes_list_mutex);
@@ -991,12 +991,13 @@ static inline void ghes_sea_remove(struct ghes *ghes) { }
#ifdef CONFIG_HAVE_ACPI_APEI_NMI
/*
- * NMI may be triggered on any CPU, so ghes_in_nmi is used for
- * having only one concurrent reader.
+ * NOTIFY_NMI may be triggered on any CPU, so ghes_in_nmi is
+ * used for having only one concurrent reader.
*/
static atomic_t ghes_in_nmi = ATOMIC_INIT(0);
static LIST_HEAD(ghes_nmi);
+static DEFINE_RAW_SPINLOCK(ghes_fixmap_lock_nmi);
static int ghes_notify_nmi(unsigned int cmd, struct pt_regs *regs)
{
--
2.15.1
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH 07/11] ACPI / APEI: Split fixmap pages for arm64 NMI-like notifications
@ 2018-02-15 18:56 ` James Morse
0 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-02-15 18:56 UTC (permalink / raw)
To: linux-acpi
Cc: kvmarm, linux-arm-kernel, linux-mm, Borislav Petkov,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
Naoya Horiguchi, Rafael Wysocki, Len Brown, Tony Luck,
Tyler Baicar, Dongjiu Geng, Xie XiuQi, Punit Agrawal,
James Morse
Now that ghes uses the fixmap addresses and locks via some indirection
we can support multiple NMI-like notifications on arm64.
These should be named after their notification method. x86's
NOTIFY_NMI already is, change the SEA fixmap entry to be called
FIX_APEI_GHES_SEA.
Future patches can add support for FIX_APEI_GHES_SEI and
FIX_APEI_GHES_SDEI_{NORMAL,CRITICAL}.
Signed-off-by: James Morse <james.morse@arm.com>
CC: Tyler Baicar <tbaicar@codeaurora.org>
---
arch/arm64/include/asm/fixmap.h | 4 +++-
drivers/acpi/apei/ghes.c | 11 ++++++-----
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/include/asm/fixmap.h b/arch/arm64/include/asm/fixmap.h
index ec1e6d6fa14c..c3974517c2cb 100644
--- a/arch/arm64/include/asm/fixmap.h
+++ b/arch/arm64/include/asm/fixmap.h
@@ -55,7 +55,9 @@ enum fixed_addresses {
#ifdef CONFIG_ACPI_APEI_GHES
/* Used for GHES mapping from assorted contexts */
FIX_APEI_GHES_IRQ,
- FIX_APEI_GHES_NMI,
+#ifdef CONFIG_ACPI_APEI_SEA
+ FIX_APEI_GHES_SEA,
+#endif
#endif /* CONFIG_ACPI_APEI_GHES */
#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 70ccb309a9d8..280c0a58c700 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -119,7 +119,6 @@ static DEFINE_MUTEX(ghes_list_mutex);
* handler, but general ioremap can not be used in atomic context, so
* the fixmap is used instead.
*/
-static DEFINE_RAW_SPINLOCK(ghes_fixmap_lock_nmi);
static DEFINE_SPINLOCK(ghes_fixmap_lock_irq);
static struct gen_pool *ghes_estatus_pool;
@@ -954,6 +953,7 @@ static struct notifier_block ghes_notifier_hed = {
#ifdef CONFIG_ACPI_APEI_SEA
static LIST_HEAD(ghes_sea);
+static DEFINE_RAW_SPINLOCK(ghes_fixmap_lock_sea);
/*
* Return 0 only if one of the SEA error sources successfully reported an error
@@ -966,8 +966,8 @@ int ghes_notify_sea(void)
static void ghes_sea_add(struct ghes *ghes)
{
- ghes->nmi_fixmap_lock = &ghes_fixmap_lock_nmi;
- ghes->fixmap_idx = FIX_APEI_GHES_NMI;
+ ghes->nmi_fixmap_lock = &ghes_fixmap_lock_sea;
+ ghes->fixmap_idx = FIX_APEI_GHES_SEA;
ghes_estatus_queue_grow_pool(ghes);
mutex_lock(&ghes_list_mutex);
@@ -991,12 +991,13 @@ static inline void ghes_sea_remove(struct ghes *ghes) { }
#ifdef CONFIG_HAVE_ACPI_APEI_NMI
/*
- * NMI may be triggered on any CPU, so ghes_in_nmi is used for
- * having only one concurrent reader.
+ * NOTIFY_NMI may be triggered on any CPU, so ghes_in_nmi is
+ * used for having only one concurrent reader.
*/
static atomic_t ghes_in_nmi = ATOMIC_INIT(0);
static LIST_HEAD(ghes_nmi);
+static DEFINE_RAW_SPINLOCK(ghes_fixmap_lock_nmi);
static int ghes_notify_nmi(unsigned int cmd, struct pt_regs *regs)
{
--
2.15.1
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH 07/11] ACPI / APEI: Split fixmap pages for arm64 NMI-like notifications
@ 2018-02-15 18:56 ` James Morse
0 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-02-15 18:56 UTC (permalink / raw)
To: linux-arm-kernel
Now that ghes uses the fixmap addresses and locks via some indirection
we can support multiple NMI-like notifications on arm64.
These should be named after their notification method. x86's
NOTIFY_NMI already is, change the SEA fixmap entry to be called
FIX_APEI_GHES_SEA.
Future patches can add support for FIX_APEI_GHES_SEI and
FIX_APEI_GHES_SDEI_{NORMAL,CRITICAL}.
Signed-off-by: James Morse <james.morse@arm.com>
CC: Tyler Baicar <tbaicar@codeaurora.org>
---
arch/arm64/include/asm/fixmap.h | 4 +++-
drivers/acpi/apei/ghes.c | 11 ++++++-----
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/include/asm/fixmap.h b/arch/arm64/include/asm/fixmap.h
index ec1e6d6fa14c..c3974517c2cb 100644
--- a/arch/arm64/include/asm/fixmap.h
+++ b/arch/arm64/include/asm/fixmap.h
@@ -55,7 +55,9 @@ enum fixed_addresses {
#ifdef CONFIG_ACPI_APEI_GHES
/* Used for GHES mapping from assorted contexts */
FIX_APEI_GHES_IRQ,
- FIX_APEI_GHES_NMI,
+#ifdef CONFIG_ACPI_APEI_SEA
+ FIX_APEI_GHES_SEA,
+#endif
#endif /* CONFIG_ACPI_APEI_GHES */
#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 70ccb309a9d8..280c0a58c700 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -119,7 +119,6 @@ static DEFINE_MUTEX(ghes_list_mutex);
* handler, but general ioremap can not be used in atomic context, so
* the fixmap is used instead.
*/
-static DEFINE_RAW_SPINLOCK(ghes_fixmap_lock_nmi);
static DEFINE_SPINLOCK(ghes_fixmap_lock_irq);
static struct gen_pool *ghes_estatus_pool;
@@ -954,6 +953,7 @@ static struct notifier_block ghes_notifier_hed = {
#ifdef CONFIG_ACPI_APEI_SEA
static LIST_HEAD(ghes_sea);
+static DEFINE_RAW_SPINLOCK(ghes_fixmap_lock_sea);
/*
* Return 0 only if one of the SEA error sources successfully reported an error
@@ -966,8 +966,8 @@ int ghes_notify_sea(void)
static void ghes_sea_add(struct ghes *ghes)
{
- ghes->nmi_fixmap_lock = &ghes_fixmap_lock_nmi;
- ghes->fixmap_idx = FIX_APEI_GHES_NMI;
+ ghes->nmi_fixmap_lock = &ghes_fixmap_lock_sea;
+ ghes->fixmap_idx = FIX_APEI_GHES_SEA;
ghes_estatus_queue_grow_pool(ghes);
mutex_lock(&ghes_list_mutex);
@@ -991,12 +991,13 @@ static inline void ghes_sea_remove(struct ghes *ghes) { }
#ifdef CONFIG_HAVE_ACPI_APEI_NMI
/*
- * NMI may be triggered on any CPU, so ghes_in_nmi is used for
- * having only one concurrent reader.
+ * NOTIFY_NMI may be triggered on any CPU, so ghes_in_nmi is
+ * used for having only one concurrent reader.
*/
static atomic_t ghes_in_nmi = ATOMIC_INIT(0);
static LIST_HEAD(ghes_nmi);
+static DEFINE_RAW_SPINLOCK(ghes_fixmap_lock_nmi);
static int ghes_notify_nmi(unsigned int cmd, struct pt_regs *regs)
{
--
2.15.1
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH 08/11] firmware: arm_sdei: Add ACPI GHES registration helper
2018-02-15 18:55 ` James Morse
@ 2018-02-15 18:56 ` James Morse
-1 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-02-15 18:56 UTC (permalink / raw)
To: linux-acpi
Cc: kvmarm, linux-arm-kernel, linux-mm, Borislav Petkov,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
Naoya Horiguchi, Rafael Wysocki, Len Brown, Tony Luck,
Tyler Baicar, Dongjiu Geng, Xie XiuQi, Punit Agrawal,
James Morse
APEI's Generic Hardware Error Source structures do not describe
whether the SDEI event is shared or private, as this information is
discoverable via the API.
GHES needs to know whether an event is normal or critical to avoid
sharing locks or fixmap entries.
Add a helper to ask firmware for this information so it can initialise
the struct ghes and register then enable the event.
Signed-off-by: James Morse <james.morse@arm.com>
---
arch/arm64/include/asm/fixmap.h | 4 +++
drivers/firmware/arm_sdei.c | 75 +++++++++++++++++++++++++++++++++++++++++
include/linux/arm_sdei.h | 5 +++
3 files changed, 84 insertions(+)
diff --git a/arch/arm64/include/asm/fixmap.h b/arch/arm64/include/asm/fixmap.h
index c3974517c2cb..e2b423a5feaf 100644
--- a/arch/arm64/include/asm/fixmap.h
+++ b/arch/arm64/include/asm/fixmap.h
@@ -58,6 +58,10 @@ enum fixed_addresses {
#ifdef CONFIG_ACPI_APEI_SEA
FIX_APEI_GHES_SEA,
#endif
+#ifdef CONFIG_ARM_SDE_INTERFACE
+ FIX_APEI_GHES_SDEI_NORMAL,
+ FIX_APEI_GHES_SDEI_CRITICAL,
+#endif
#endif /* CONFIG_ACPI_APEI_GHES */
#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
diff --git a/drivers/firmware/arm_sdei.c b/drivers/firmware/arm_sdei.c
index 1ea71640fdc2..9b6e140cf6cb 100644
--- a/drivers/firmware/arm_sdei.c
+++ b/drivers/firmware/arm_sdei.c
@@ -2,6 +2,7 @@
// Copyright (C) 2017 Arm Ltd.
#define pr_fmt(fmt) "sdei: " fmt
+#include <acpi/ghes.h>
#include <linux/acpi.h>
#include <linux/arm_sdei.h>
#include <linux/arm-smccc.h>
@@ -887,6 +888,80 @@ static void sdei_smccc_hvc(unsigned long function_id,
arm_smccc_hvc(function_id, arg0, arg1, arg2, arg3, arg4, 0, 0, res);
}
+#ifdef CONFIG_ACPI
+/* These stop private notifications using the fixmap entries simultaneously */
+static DEFINE_RAW_SPINLOCK(sdei_ghes_fixmap_lock_normal);
+static DEFINE_RAW_SPINLOCK(sdei_ghes_fixmap_lock_critical);
+
+int sdei_register_ghes(struct ghes *ghes, sdei_event_callback *cb)
+{
+ int err;
+ u32 event_num;
+ u64 result;
+
+ if (acpi_disabled)
+ return -EOPNOTSUPP;
+
+ event_num = ghes->generic->notify.vector;
+ if (event_num == 0) {
+ /*
+ * Event 0 is the reserved by the specification for
+ * SDEI_EVENT_SIGNAL.
+ */
+ return -EINVAL;
+ }
+
+ err = sdei_api_event_get_info(event_num, SDEI_EVENT_INFO_EV_PRIORITY,
+ &result);
+ if (err)
+ return err;
+
+ if (result == SDEI_EVENT_PRIORITY_CRITICAL) {
+ ghes->nmi_fixmap_lock = &sdei_ghes_fixmap_lock_critical;
+ ghes->fixmap_idx = FIX_APEI_GHES_SDEI_CRITICAL;
+ } else {
+ ghes->nmi_fixmap_lock = &sdei_ghes_fixmap_lock_normal;
+ ghes->fixmap_idx = FIX_APEI_GHES_SDEI_NORMAL;
+ }
+
+ err = sdei_event_register(event_num, cb, ghes);
+ if (!err)
+ err = sdei_event_enable(event_num);
+
+ return err;
+}
+
+int sdei_unregister_ghes(struct ghes *ghes)
+{
+ int i;
+ int err;
+ u32 event_num = ghes->generic->notify.vector;
+
+ might_sleep();
+
+ if (acpi_disabled)
+ return -EOPNOTSUPP;
+
+ /*
+ * The event may be running on another CPU. Disable it
+ * to stop new events, then try to unregister a few times.
+ */
+ err = sdei_event_disable(event_num);
+ if (err)
+ return err;
+
+ for (i = 0; i < 3; i++) {
+ err = sdei_event_unregister(event_num);
+ if (err != -EINPROGRESS)
+ break;
+
+ schedule();
+ }
+
+ return err;
+}
+#endif /* CONFIG_ACPI */
+
static int sdei_get_conduit(struct platform_device *pdev)
{
const char *method;
diff --git a/include/linux/arm_sdei.h b/include/linux/arm_sdei.h
index 942afbd544b7..5fdf799be026 100644
--- a/include/linux/arm_sdei.h
+++ b/include/linux/arm_sdei.h
@@ -11,6 +11,7 @@ enum sdei_conduit_types {
CONDUIT_HVC,
};
+#include <acpi/ghes.h>
#include <asm/sdei.h>
/* Arch code should override this to set the entry point from firmware... */
@@ -39,6 +40,10 @@ int sdei_event_unregister(u32 event_num);
int sdei_event_enable(u32 event_num);
int sdei_event_disable(u32 event_num);
+/* GHES register/unregister helpers */
+int sdei_register_ghes(struct ghes *ghes, sdei_event_callback *cb);
+int sdei_unregister_ghes(struct ghes *ghes);
+
#ifdef CONFIG_ARM_SDE_INTERFACE
/* For use by arch code when CPU hotplug notifiers are not appropriate. */
int sdei_mask_local_cpu(void);
--
2.15.1
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH 08/11] firmware: arm_sdei: Add ACPI GHES registration helper
@ 2018-02-15 18:56 ` James Morse
0 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-02-15 18:56 UTC (permalink / raw)
To: linux-arm-kernel
APEI's Generic Hardware Error Source structures do not describe
whether the SDEI event is shared or private, as this information is
discoverable via the API.
GHES needs to know whether an event is normal or critical to avoid
sharing locks or fixmap entries.
Add a helper to ask firmware for this information so it can initialise
the struct ghes and register then enable the event.
Signed-off-by: James Morse <james.morse@arm.com>
---
arch/arm64/include/asm/fixmap.h | 4 +++
drivers/firmware/arm_sdei.c | 75 +++++++++++++++++++++++++++++++++++++++++
include/linux/arm_sdei.h | 5 +++
3 files changed, 84 insertions(+)
diff --git a/arch/arm64/include/asm/fixmap.h b/arch/arm64/include/asm/fixmap.h
index c3974517c2cb..e2b423a5feaf 100644
--- a/arch/arm64/include/asm/fixmap.h
+++ b/arch/arm64/include/asm/fixmap.h
@@ -58,6 +58,10 @@ enum fixed_addresses {
#ifdef CONFIG_ACPI_APEI_SEA
FIX_APEI_GHES_SEA,
#endif
+#ifdef CONFIG_ARM_SDE_INTERFACE
+ FIX_APEI_GHES_SDEI_NORMAL,
+ FIX_APEI_GHES_SDEI_CRITICAL,
+#endif
#endif /* CONFIG_ACPI_APEI_GHES */
#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
diff --git a/drivers/firmware/arm_sdei.c b/drivers/firmware/arm_sdei.c
index 1ea71640fdc2..9b6e140cf6cb 100644
--- a/drivers/firmware/arm_sdei.c
+++ b/drivers/firmware/arm_sdei.c
@@ -2,6 +2,7 @@
// Copyright (C) 2017 Arm Ltd.
#define pr_fmt(fmt) "sdei: " fmt
+#include <acpi/ghes.h>
#include <linux/acpi.h>
#include <linux/arm_sdei.h>
#include <linux/arm-smccc.h>
@@ -887,6 +888,80 @@ static void sdei_smccc_hvc(unsigned long function_id,
arm_smccc_hvc(function_id, arg0, arg1, arg2, arg3, arg4, 0, 0, res);
}
+#ifdef CONFIG_ACPI
+/* These stop private notifications using the fixmap entries simultaneously */
+static DEFINE_RAW_SPINLOCK(sdei_ghes_fixmap_lock_normal);
+static DEFINE_RAW_SPINLOCK(sdei_ghes_fixmap_lock_critical);
+
+int sdei_register_ghes(struct ghes *ghes, sdei_event_callback *cb)
+{
+ int err;
+ u32 event_num;
+ u64 result;
+
+ if (acpi_disabled)
+ return -EOPNOTSUPP;
+
+ event_num = ghes->generic->notify.vector;
+ if (event_num == 0) {
+ /*
+ * Event 0 is the reserved by the specification for
+ * SDEI_EVENT_SIGNAL.
+ */
+ return -EINVAL;
+ }
+
+ err = sdei_api_event_get_info(event_num, SDEI_EVENT_INFO_EV_PRIORITY,
+ &result);
+ if (err)
+ return err;
+
+ if (result == SDEI_EVENT_PRIORITY_CRITICAL) {
+ ghes->nmi_fixmap_lock = &sdei_ghes_fixmap_lock_critical;
+ ghes->fixmap_idx = FIX_APEI_GHES_SDEI_CRITICAL;
+ } else {
+ ghes->nmi_fixmap_lock = &sdei_ghes_fixmap_lock_normal;
+ ghes->fixmap_idx = FIX_APEI_GHES_SDEI_NORMAL;
+ }
+
+ err = sdei_event_register(event_num, cb, ghes);
+ if (!err)
+ err = sdei_event_enable(event_num);
+
+ return err;
+}
+
+int sdei_unregister_ghes(struct ghes *ghes)
+{
+ int i;
+ int err;
+ u32 event_num = ghes->generic->notify.vector;
+
+ might_sleep();
+
+ if (acpi_disabled)
+ return -EOPNOTSUPP;
+
+ /*
+ * The event may be running on another CPU. Disable it
+ * to stop new events, then try to unregister a few times.
+ */
+ err = sdei_event_disable(event_num);
+ if (err)
+ return err;
+
+ for (i = 0; i < 3; i++) {
+ err = sdei_event_unregister(event_num);
+ if (err != -EINPROGRESS)
+ break;
+
+ schedule();
+ }
+
+ return err;
+}
+#endif /* CONFIG_ACPI */
+
static int sdei_get_conduit(struct platform_device *pdev)
{
const char *method;
diff --git a/include/linux/arm_sdei.h b/include/linux/arm_sdei.h
index 942afbd544b7..5fdf799be026 100644
--- a/include/linux/arm_sdei.h
+++ b/include/linux/arm_sdei.h
@@ -11,6 +11,7 @@ enum sdei_conduit_types {
CONDUIT_HVC,
};
+#include <acpi/ghes.h>
#include <asm/sdei.h>
/* Arch code should override this to set the entry point from firmware... */
@@ -39,6 +40,10 @@ int sdei_event_unregister(u32 event_num);
int sdei_event_enable(u32 event_num);
int sdei_event_disable(u32 event_num);
+/* GHES register/unregister helpers */
+int sdei_register_ghes(struct ghes *ghes, sdei_event_callback *cb);
+int sdei_unregister_ghes(struct ghes *ghes);
+
#ifdef CONFIG_ARM_SDE_INTERFACE
/* For use by arch code when CPU hotplug notifiers are not appropriate. */
int sdei_mask_local_cpu(void);
--
2.15.1
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH 09/11] ACPI / APEI: Add support for the SDEI GHES Notification type
2018-02-15 18:55 ` James Morse
(?)
@ 2018-02-15 18:56 ` James Morse
-1 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-02-15 18:56 UTC (permalink / raw)
To: linux-acpi
Cc: kvmarm, linux-arm-kernel, linux-mm, Borislav Petkov,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
Naoya Horiguchi, Rafael Wysocki, Len Brown, Tony Luck,
Tyler Baicar, Dongjiu Geng, Xie XiuQi, Punit Agrawal,
James Morse
If the GHES notification type is SDEI, register the provided event
number and point the callback at ghes_sdei_callback().
Signed-off-by: James Morse <james.morse@arm.com>
---
drivers/acpi/apei/ghes.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++--
include/linux/arm_sdei.h | 3 +++
2 files changed, 67 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 280c0a58c700..5eaf0a772be7 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -25,6 +25,7 @@
* GNU General Public License for more details.
*/
+#include <linux/arm_sdei.h>
#include <linux/kernel.h>
#include <linux/moduleparam.h>
#include <linux/init.h>
@@ -59,7 +60,7 @@
#define GHES_PFX "GHES: "
-#if defined(CONFIG_HAVE_ACPI_APEI_NMI) || defined(CONFIG_ACPI_APEI_SEA)
+#if defined(CONFIG_HAVE_ACPI_APEI_NMI) || defined(CONFIG_ACPI_APEI_SEA) || defined(CONFIG_ARM_SDE_INTERFACE)
#define WANT_NMI_ESTATUS_QUEUE 1
#endif
@@ -753,7 +754,7 @@ static int _in_nmi_notify_one(struct ghes *ghes)
return ret;
}
-static int ghes_estatus_queue_notified(struct list_head *rcu_list)
+static int __maybe_unused ghes_estatus_queue_notified(struct list_head *rcu_list)
{
int ret = -ENOENT;
struct ghes *ghes;
@@ -1047,6 +1048,49 @@ static inline void ghes_nmi_add(struct ghes *ghes) { }
static inline void ghes_nmi_remove(struct ghes *ghes) { }
#endif /* CONFIG_HAVE_ACPI_APEI_NMI */
+static int ghes_sdei_callback(u32 event_num, struct pt_regs *regs, void *arg)
+{
+ struct ghes *ghes = arg;
+
+ if (!_in_nmi_notify_one(ghes)) {
+ if (IS_ENABLED(CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG))
+ irq_work_queue(&ghes_proc_irq_work);
+
+ return 0;
+ }
+
+ return -ENOENT;
+}
+
+static int apei_sdei_register_ghes(struct ghes *ghes)
+{
+ int err = -EINVAL;
+
+ if (IS_ENABLED(CONFIG_ARM_SDE_INTERFACE)) {
+ ghes_estatus_queue_grow_pool(ghes);
+
+ err = sdei_register_ghes(ghes, ghes_sdei_callback);
+ if (err)
+ ghes_estatus_queue_shrink_pool(ghes);
+ }
+
+ return err;
+}
+
+static int apei_sdei_unregister_ghes(struct ghes *ghes)
+{
+ int err = -EINVAL;
+
+ if (IS_ENABLED(CONFIG_ARM_SDE_INTERFACE)) {
+ err = sdei_unregister_ghes(ghes);
+
+ if (!err)
+ ghes_estatus_queue_shrink_pool(ghes);
+ }
+
+ return err;
+}
+
static int ghes_probe(struct platform_device *ghes_dev)
{
struct acpi_hest_generic *generic;
@@ -1081,6 +1125,13 @@ static int ghes_probe(struct platform_device *ghes_dev)
goto err;
}
break;
+ case ACPI_HEST_NOTIFY_SOFTWARE_DELEGATED:
+ if (!IS_ENABLED(CONFIG_ARM_SDE_INTERFACE)) {
+ pr_warn(GHES_PFX "Generic hardware error source: %d notified via SDE Interface is not supported!\n",
+ generic->header.source_id);
+ goto err;
+ }
+ break;
case ACPI_HEST_NOTIFY_LOCAL:
pr_warning(GHES_PFX "Generic hardware error source: %d notified via local interrupt is not supported!\n",
generic->header.source_id);
@@ -1154,6 +1205,11 @@ static int ghes_probe(struct platform_device *ghes_dev)
case ACPI_HEST_NOTIFY_NMI:
ghes_nmi_add(ghes);
break;
+ case ACPI_HEST_NOTIFY_SOFTWARE_DELEGATED:
+ rc = apei_sdei_register_ghes(ghes);
+ if (rc)
+ goto err_edac_unreg;
+ break;
default:
BUG();
}
@@ -1175,6 +1231,7 @@ err:
static int ghes_remove(struct platform_device *ghes_dev)
{
+ int rc;
struct ghes *ghes;
struct acpi_hest_generic *generic;
@@ -1207,6 +1264,11 @@ static int ghes_remove(struct platform_device *ghes_dev)
case ACPI_HEST_NOTIFY_NMI:
ghes_nmi_remove(ghes);
break;
+ case ACPI_HEST_NOTIFY_SOFTWARE_DELEGATED:
+ rc = apei_sdei_unregister_ghes(ghes);
+ if (rc)
+ return rc;
+ break;
default:
BUG();
break;
diff --git a/include/linux/arm_sdei.h b/include/linux/arm_sdei.h
index 5fdf799be026..f49063ca206d 100644
--- a/include/linux/arm_sdei.h
+++ b/include/linux/arm_sdei.h
@@ -12,7 +12,10 @@ enum sdei_conduit_types {
};
#include <acpi/ghes.h>
+
+#ifdef CONFIG_ARM_SDE_INTERFACE
#include <asm/sdei.h>
+#endif
/* Arch code should override this to set the entry point from firmware... */
#ifndef sdei_arch_get_entry_point
--
2.15.1
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH 09/11] ACPI / APEI: Add support for the SDEI GHES Notification type
@ 2018-02-15 18:56 ` James Morse
0 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-02-15 18:56 UTC (permalink / raw)
To: linux-acpi
Cc: kvmarm, linux-arm-kernel, linux-mm, Borislav Petkov,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
Naoya Horiguchi, Rafael Wysocki, Len Brown, Tony Luck,
Tyler Baicar, Dongjiu Geng, Xie XiuQi, Punit Agrawal,
James Morse
If the GHES notification type is SDEI, register the provided event
number and point the callback at ghes_sdei_callback().
Signed-off-by: James Morse <james.morse@arm.com>
---
drivers/acpi/apei/ghes.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++--
include/linux/arm_sdei.h | 3 +++
2 files changed, 67 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 280c0a58c700..5eaf0a772be7 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -25,6 +25,7 @@
* GNU General Public License for more details.
*/
+#include <linux/arm_sdei.h>
#include <linux/kernel.h>
#include <linux/moduleparam.h>
#include <linux/init.h>
@@ -59,7 +60,7 @@
#define GHES_PFX "GHES: "
-#if defined(CONFIG_HAVE_ACPI_APEI_NMI) || defined(CONFIG_ACPI_APEI_SEA)
+#if defined(CONFIG_HAVE_ACPI_APEI_NMI) || defined(CONFIG_ACPI_APEI_SEA) || defined(CONFIG_ARM_SDE_INTERFACE)
#define WANT_NMI_ESTATUS_QUEUE 1
#endif
@@ -753,7 +754,7 @@ static int _in_nmi_notify_one(struct ghes *ghes)
return ret;
}
-static int ghes_estatus_queue_notified(struct list_head *rcu_list)
+static int __maybe_unused ghes_estatus_queue_notified(struct list_head *rcu_list)
{
int ret = -ENOENT;
struct ghes *ghes;
@@ -1047,6 +1048,49 @@ static inline void ghes_nmi_add(struct ghes *ghes) { }
static inline void ghes_nmi_remove(struct ghes *ghes) { }
#endif /* CONFIG_HAVE_ACPI_APEI_NMI */
+static int ghes_sdei_callback(u32 event_num, struct pt_regs *regs, void *arg)
+{
+ struct ghes *ghes = arg;
+
+ if (!_in_nmi_notify_one(ghes)) {
+ if (IS_ENABLED(CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG))
+ irq_work_queue(&ghes_proc_irq_work);
+
+ return 0;
+ }
+
+ return -ENOENT;
+}
+
+static int apei_sdei_register_ghes(struct ghes *ghes)
+{
+ int err = -EINVAL;
+
+ if (IS_ENABLED(CONFIG_ARM_SDE_INTERFACE)) {
+ ghes_estatus_queue_grow_pool(ghes);
+
+ err = sdei_register_ghes(ghes, ghes_sdei_callback);
+ if (err)
+ ghes_estatus_queue_shrink_pool(ghes);
+ }
+
+ return err;
+}
+
+static int apei_sdei_unregister_ghes(struct ghes *ghes)
+{
+ int err = -EINVAL;
+
+ if (IS_ENABLED(CONFIG_ARM_SDE_INTERFACE)) {
+ err = sdei_unregister_ghes(ghes);
+
+ if (!err)
+ ghes_estatus_queue_shrink_pool(ghes);
+ }
+
+ return err;
+}
+
static int ghes_probe(struct platform_device *ghes_dev)
{
struct acpi_hest_generic *generic;
@@ -1081,6 +1125,13 @@ static int ghes_probe(struct platform_device *ghes_dev)
goto err;
}
break;
+ case ACPI_HEST_NOTIFY_SOFTWARE_DELEGATED:
+ if (!IS_ENABLED(CONFIG_ARM_SDE_INTERFACE)) {
+ pr_warn(GHES_PFX "Generic hardware error source: %d notified via SDE Interface is not supported!\n",
+ generic->header.source_id);
+ goto err;
+ }
+ break;
case ACPI_HEST_NOTIFY_LOCAL:
pr_warning(GHES_PFX "Generic hardware error source: %d notified via local interrupt is not supported!\n",
generic->header.source_id);
@@ -1154,6 +1205,11 @@ static int ghes_probe(struct platform_device *ghes_dev)
case ACPI_HEST_NOTIFY_NMI:
ghes_nmi_add(ghes);
break;
+ case ACPI_HEST_NOTIFY_SOFTWARE_DELEGATED:
+ rc = apei_sdei_register_ghes(ghes);
+ if (rc)
+ goto err_edac_unreg;
+ break;
default:
BUG();
}
@@ -1175,6 +1231,7 @@ err:
static int ghes_remove(struct platform_device *ghes_dev)
{
+ int rc;
struct ghes *ghes;
struct acpi_hest_generic *generic;
@@ -1207,6 +1264,11 @@ static int ghes_remove(struct platform_device *ghes_dev)
case ACPI_HEST_NOTIFY_NMI:
ghes_nmi_remove(ghes);
break;
+ case ACPI_HEST_NOTIFY_SOFTWARE_DELEGATED:
+ rc = apei_sdei_unregister_ghes(ghes);
+ if (rc)
+ return rc;
+ break;
default:
BUG();
break;
diff --git a/include/linux/arm_sdei.h b/include/linux/arm_sdei.h
index 5fdf799be026..f49063ca206d 100644
--- a/include/linux/arm_sdei.h
+++ b/include/linux/arm_sdei.h
@@ -12,7 +12,10 @@ enum sdei_conduit_types {
};
#include <acpi/ghes.h>
+
+#ifdef CONFIG_ARM_SDE_INTERFACE
#include <asm/sdei.h>
+#endif
/* Arch code should override this to set the entry point from firmware... */
#ifndef sdei_arch_get_entry_point
--
2.15.1
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH 09/11] ACPI / APEI: Add support for the SDEI GHES Notification type
@ 2018-02-15 18:56 ` James Morse
0 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-02-15 18:56 UTC (permalink / raw)
To: linux-arm-kernel
If the GHES notification type is SDEI, register the provided event
number and point the callback at ghes_sdei_callback().
Signed-off-by: James Morse <james.morse@arm.com>
---
drivers/acpi/apei/ghes.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++--
include/linux/arm_sdei.h | 3 +++
2 files changed, 67 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 280c0a58c700..5eaf0a772be7 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -25,6 +25,7 @@
* GNU General Public License for more details.
*/
+#include <linux/arm_sdei.h>
#include <linux/kernel.h>
#include <linux/moduleparam.h>
#include <linux/init.h>
@@ -59,7 +60,7 @@
#define GHES_PFX "GHES: "
-#if defined(CONFIG_HAVE_ACPI_APEI_NMI) || defined(CONFIG_ACPI_APEI_SEA)
+#if defined(CONFIG_HAVE_ACPI_APEI_NMI) || defined(CONFIG_ACPI_APEI_SEA) || defined(CONFIG_ARM_SDE_INTERFACE)
#define WANT_NMI_ESTATUS_QUEUE 1
#endif
@@ -753,7 +754,7 @@ static int _in_nmi_notify_one(struct ghes *ghes)
return ret;
}
-static int ghes_estatus_queue_notified(struct list_head *rcu_list)
+static int __maybe_unused ghes_estatus_queue_notified(struct list_head *rcu_list)
{
int ret = -ENOENT;
struct ghes *ghes;
@@ -1047,6 +1048,49 @@ static inline void ghes_nmi_add(struct ghes *ghes) { }
static inline void ghes_nmi_remove(struct ghes *ghes) { }
#endif /* CONFIG_HAVE_ACPI_APEI_NMI */
+static int ghes_sdei_callback(u32 event_num, struct pt_regs *regs, void *arg)
+{
+ struct ghes *ghes = arg;
+
+ if (!_in_nmi_notify_one(ghes)) {
+ if (IS_ENABLED(CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG))
+ irq_work_queue(&ghes_proc_irq_work);
+
+ return 0;
+ }
+
+ return -ENOENT;
+}
+
+static int apei_sdei_register_ghes(struct ghes *ghes)
+{
+ int err = -EINVAL;
+
+ if (IS_ENABLED(CONFIG_ARM_SDE_INTERFACE)) {
+ ghes_estatus_queue_grow_pool(ghes);
+
+ err = sdei_register_ghes(ghes, ghes_sdei_callback);
+ if (err)
+ ghes_estatus_queue_shrink_pool(ghes);
+ }
+
+ return err;
+}
+
+static int apei_sdei_unregister_ghes(struct ghes *ghes)
+{
+ int err = -EINVAL;
+
+ if (IS_ENABLED(CONFIG_ARM_SDE_INTERFACE)) {
+ err = sdei_unregister_ghes(ghes);
+
+ if (!err)
+ ghes_estatus_queue_shrink_pool(ghes);
+ }
+
+ return err;
+}
+
static int ghes_probe(struct platform_device *ghes_dev)
{
struct acpi_hest_generic *generic;
@@ -1081,6 +1125,13 @@ static int ghes_probe(struct platform_device *ghes_dev)
goto err;
}
break;
+ case ACPI_HEST_NOTIFY_SOFTWARE_DELEGATED:
+ if (!IS_ENABLED(CONFIG_ARM_SDE_INTERFACE)) {
+ pr_warn(GHES_PFX "Generic hardware error source: %d notified via SDE Interface is not supported!\n",
+ generic->header.source_id);
+ goto err;
+ }
+ break;
case ACPI_HEST_NOTIFY_LOCAL:
pr_warning(GHES_PFX "Generic hardware error source: %d notified via local interrupt is not supported!\n",
generic->header.source_id);
@@ -1154,6 +1205,11 @@ static int ghes_probe(struct platform_device *ghes_dev)
case ACPI_HEST_NOTIFY_NMI:
ghes_nmi_add(ghes);
break;
+ case ACPI_HEST_NOTIFY_SOFTWARE_DELEGATED:
+ rc = apei_sdei_register_ghes(ghes);
+ if (rc)
+ goto err_edac_unreg;
+ break;
default:
BUG();
}
@@ -1175,6 +1231,7 @@ err:
static int ghes_remove(struct platform_device *ghes_dev)
{
+ int rc;
struct ghes *ghes;
struct acpi_hest_generic *generic;
@@ -1207,6 +1264,11 @@ static int ghes_remove(struct platform_device *ghes_dev)
case ACPI_HEST_NOTIFY_NMI:
ghes_nmi_remove(ghes);
break;
+ case ACPI_HEST_NOTIFY_SOFTWARE_DELEGATED:
+ rc = apei_sdei_unregister_ghes(ghes);
+ if (rc)
+ return rc;
+ break;
default:
BUG();
break;
diff --git a/include/linux/arm_sdei.h b/include/linux/arm_sdei.h
index 5fdf799be026..f49063ca206d 100644
--- a/include/linux/arm_sdei.h
+++ b/include/linux/arm_sdei.h
@@ -12,7 +12,10 @@ enum sdei_conduit_types {
};
#include <acpi/ghes.h>
+
+#ifdef CONFIG_ARM_SDE_INTERFACE
#include <asm/sdei.h>
+#endif
/* Arch code should override this to set the entry point from firmware... */
#ifndef sdei_arch_get_entry_point
--
2.15.1
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH 10/11] mm/memory-failure: increase queued recovery work's priority
2018-02-15 18:55 ` James Morse
(?)
@ 2018-02-15 18:56 ` James Morse
-1 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-02-15 18:56 UTC (permalink / raw)
To: linux-acpi
Cc: kvmarm, linux-arm-kernel, linux-mm, Borislav Petkov,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
Naoya Horiguchi, Rafael Wysocki, Len Brown, Tony Luck,
Tyler Baicar, Dongjiu Geng, Xie XiuQi, Punit Agrawal,
James Morse
arm64 can take an NMI-like error notification when user-space steps in
some corrupt memory. APEI's GHES code will call memory_failure_queue()
to schedule the recovery work. We then return to user-space, possibly
taking the fault again.
Currently the arch code unconditionally signals user-space from this
path, so we don't get stuck in this loop, but the affected process
never benefits from memory_failure()s recovery work. To fix this we
need to know the recovery work will run before we get back to user-space.
Increase the priority of the recovery work by scheduling it on the
system_highpri_wq, then try to bump the current task off this CPU
so that the recover work starts immediately.
Reported-by: Xie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: James Morse <james.morse@arm.com>
CC: Xie XiuQi <xiexiuqi@huawei.com>
CC: gengdongjiu <gengdongjiu@huawei.com>
---
mm/memory-failure.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index 4b80ccee4535..14f44d841e8b 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -55,6 +55,7 @@
#include <linux/hugetlb.h>
#include <linux/memory_hotplug.h>
#include <linux/mm_inline.h>
+#include <linux/preempt.h>
#include <linux/kfifo.h>
#include <linux/ratelimit.h>
#include "internal.h"
@@ -1319,6 +1320,7 @@ static DEFINE_PER_CPU(struct memory_failure_cpu, memory_failure_cpu);
*/
void memory_failure_queue(unsigned long pfn, int flags)
{
+ int cpu = smp_processor_id();
struct memory_failure_cpu *mf_cpu;
unsigned long proc_flags;
struct memory_failure_entry entry = {
@@ -1328,11 +1330,14 @@ void memory_failure_queue(unsigned long pfn, int flags)
mf_cpu = &get_cpu_var(memory_failure_cpu);
spin_lock_irqsave(&mf_cpu->lock, proc_flags);
- if (kfifo_put(&mf_cpu->fifo, entry))
- schedule_work_on(smp_processor_id(), &mf_cpu->work);
- else
+ if (kfifo_put(&mf_cpu->fifo, entry)) {
+ queue_work_on(cpu, system_highpri_wq, &mf_cpu->work);
+ set_tsk_need_resched(current);
+ preempt_set_need_resched();
+ } else {
pr_err("Memory failure: buffer overflow when queuing memory failure at %#lx\n",
pfn);
+ }
spin_unlock_irqrestore(&mf_cpu->lock, proc_flags);
put_cpu_var(memory_failure_cpu);
}
--
2.15.1
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH 10/11] mm/memory-failure: increase queued recovery work's priority
@ 2018-02-15 18:56 ` James Morse
0 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-02-15 18:56 UTC (permalink / raw)
To: linux-acpi
Cc: kvmarm, linux-arm-kernel, linux-mm, Borislav Petkov,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
Naoya Horiguchi, Rafael Wysocki, Len Brown, Tony Luck,
Tyler Baicar, Dongjiu Geng, Xie XiuQi, Punit Agrawal,
James Morse
arm64 can take an NMI-like error notification when user-space steps in
some corrupt memory. APEI's GHES code will call memory_failure_queue()
to schedule the recovery work. We then return to user-space, possibly
taking the fault again.
Currently the arch code unconditionally signals user-space from this
path, so we don't get stuck in this loop, but the affected process
never benefits from memory_failure()s recovery work. To fix this we
need to know the recovery work will run before we get back to user-space.
Increase the priority of the recovery work by scheduling it on the
system_highpri_wq, then try to bump the current task off this CPU
so that the recover work starts immediately.
Reported-by: Xie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: James Morse <james.morse@arm.com>
CC: Xie XiuQi <xiexiuqi@huawei.com>
CC: gengdongjiu <gengdongjiu@huawei.com>
---
mm/memory-failure.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index 4b80ccee4535..14f44d841e8b 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -55,6 +55,7 @@
#include <linux/hugetlb.h>
#include <linux/memory_hotplug.h>
#include <linux/mm_inline.h>
+#include <linux/preempt.h>
#include <linux/kfifo.h>
#include <linux/ratelimit.h>
#include "internal.h"
@@ -1319,6 +1320,7 @@ static DEFINE_PER_CPU(struct memory_failure_cpu, memory_failure_cpu);
*/
void memory_failure_queue(unsigned long pfn, int flags)
{
+ int cpu = smp_processor_id();
struct memory_failure_cpu *mf_cpu;
unsigned long proc_flags;
struct memory_failure_entry entry = {
@@ -1328,11 +1330,14 @@ void memory_failure_queue(unsigned long pfn, int flags)
mf_cpu = &get_cpu_var(memory_failure_cpu);
spin_lock_irqsave(&mf_cpu->lock, proc_flags);
- if (kfifo_put(&mf_cpu->fifo, entry))
- schedule_work_on(smp_processor_id(), &mf_cpu->work);
- else
+ if (kfifo_put(&mf_cpu->fifo, entry)) {
+ queue_work_on(cpu, system_highpri_wq, &mf_cpu->work);
+ set_tsk_need_resched(current);
+ preempt_set_need_resched();
+ } else {
pr_err("Memory failure: buffer overflow when queuing memory failure at %#lx\n",
pfn);
+ }
spin_unlock_irqrestore(&mf_cpu->lock, proc_flags);
put_cpu_var(memory_failure_cpu);
}
--
2.15.1
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH 10/11] mm/memory-failure: increase queued recovery work's priority
@ 2018-02-15 18:56 ` James Morse
0 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-02-15 18:56 UTC (permalink / raw)
To: linux-arm-kernel
arm64 can take an NMI-like error notification when user-space steps in
some corrupt memory. APEI's GHES code will call memory_failure_queue()
to schedule the recovery work. We then return to user-space, possibly
taking the fault again.
Currently the arch code unconditionally signals user-space from this
path, so we don't get stuck in this loop, but the affected process
never benefits from memory_failure()s recovery work. To fix this we
need to know the recovery work will run before we get back to user-space.
Increase the priority of the recovery work by scheduling it on the
system_highpri_wq, then try to bump the current task off this CPU
so that the recover work starts immediately.
Reported-by: Xie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: James Morse <james.morse@arm.com>
CC: Xie XiuQi <xiexiuqi@huawei.com>
CC: gengdongjiu <gengdongjiu@huawei.com>
---
mm/memory-failure.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index 4b80ccee4535..14f44d841e8b 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -55,6 +55,7 @@
#include <linux/hugetlb.h>
#include <linux/memory_hotplug.h>
#include <linux/mm_inline.h>
+#include <linux/preempt.h>
#include <linux/kfifo.h>
#include <linux/ratelimit.h>
#include "internal.h"
@@ -1319,6 +1320,7 @@ static DEFINE_PER_CPU(struct memory_failure_cpu, memory_failure_cpu);
*/
void memory_failure_queue(unsigned long pfn, int flags)
{
+ int cpu = smp_processor_id();
struct memory_failure_cpu *mf_cpu;
unsigned long proc_flags;
struct memory_failure_entry entry = {
@@ -1328,11 +1330,14 @@ void memory_failure_queue(unsigned long pfn, int flags)
mf_cpu = &get_cpu_var(memory_failure_cpu);
spin_lock_irqsave(&mf_cpu->lock, proc_flags);
- if (kfifo_put(&mf_cpu->fifo, entry))
- schedule_work_on(smp_processor_id(), &mf_cpu->work);
- else
+ if (kfifo_put(&mf_cpu->fifo, entry)) {
+ queue_work_on(cpu, system_highpri_wq, &mf_cpu->work);
+ set_tsk_need_resched(current);
+ preempt_set_need_resched();
+ } else {
pr_err("Memory failure: buffer overflow when queuing memory failure at %#lx\n",
pfn);
+ }
spin_unlock_irqrestore(&mf_cpu->lock, proc_flags);
put_cpu_var(memory_failure_cpu);
}
--
2.15.1
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH 11/11] arm64: acpi: Make apei_claim_sea() synchronise with APEI's irq work
2018-02-15 18:55 ` James Morse
@ 2018-02-15 18:56 ` James Morse
-1 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-02-15 18:56 UTC (permalink / raw)
To: linux-acpi
Cc: kvmarm, linux-arm-kernel, linux-mm, Borislav Petkov,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
Naoya Horiguchi, Rafael Wysocki, Len Brown, Tony Luck,
Tyler Baicar, Dongjiu Geng, Xie XiuQi, Punit Agrawal,
James Morse
APEI is unable to do all of its error handling work in nmi-context, so
it defers non-fatal work onto the irq_work queue. arch_irq_work_raise()
sends an IPI to the calling cpu, but we can't guarantee this will be
taken before we return.
Unless we interrupted a context with irqs-masked, we can call
irq_work_run() to do the work now. Otherwise return -EINPROGRESS to
indicate ghes_notify_sea() found some work to do, but it hasn't
finished yet.
With this we can take apei_claim_sea() returning '0' to mean this
external-abort was also notification of a firmware-first RAS error,
and that APEI has processed the CPER records.
Signed-off-by: James Morse <james.morse@arm.com>
---
arch/arm64/kernel/acpi.c | 19 +++++++++++++++++++
arch/arm64/mm/fault.c | 9 ++++-----
2 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 6a4823a3eb5e..a51a7abd98e0 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -22,6 +22,7 @@
#include <linux/init.h>
#include <linux/irq.h>
#include <linux/irqdomain.h>
+#include <linux/irq_work.h>
#include <linux/memblock.h>
#include <linux/of_fdt.h>
#include <linux/smp.h>
@@ -275,10 +276,14 @@ int apei_claim_sea(struct pt_regs *regs)
{
int err = -ENOENT;
unsigned long current_flags = arch_local_save_flags();
+ unsigned long interrupted_flags = current_flags;
if (!IS_ENABLED(CONFIG_ACPI_APEI_SEA))
return err;
+ if (regs)
+ interrupted_flags = regs->pstate;
+
/*
* APEI expects an NMI-like notification to always be called
* in NMI context.
@@ -287,6 +292,20 @@ int apei_claim_sea(struct pt_regs *regs)
nmi_enter();
err = ghes_notify_sea();
nmi_exit();
+
+ /*
+ * APEI NMI-like notifications are deferred to irq_work. Unless
+ * we interrupted irqs-masked code, we can do that now.
+ */
+ if (!err) {
+ if (!arch_irqs_disabled_flags(interrupted_flags)) {
+ local_daif_restore(DAIF_PROCCTX_NOIRQ);
+ irq_work_run();
+ } else {
+ err = -EINPROGRESS;
+ }
+ }
+
local_daif_restore(current_flags);
return err;
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 8cbbd9a5ec7d..e218e291a17a 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -580,11 +580,10 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
inf->name, esr, addr);
if (IS_ENABLED(CONFIG_ACPI_APEI_SEA)) {
- /*
- * Return value ignored as we rely on signal merging.
- * Future patches will make this more robust.
- */
- apei_claim_sea(regs);
+ if (apei_claim_sea(regs) == 0) {
+ /* APEI claimed this as a firmware-first notification */
+ return 0;
+ }
}
info.si_signo = SIGBUS;
--
2.15.1
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH 11/11] arm64: acpi: Make apei_claim_sea() synchronise with APEI's irq work
@ 2018-02-15 18:56 ` James Morse
0 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-02-15 18:56 UTC (permalink / raw)
To: linux-arm-kernel
APEI is unable to do all of its error handling work in nmi-context, so
it defers non-fatal work onto the irq_work queue. arch_irq_work_raise()
sends an IPI to the calling cpu, but we can't guarantee this will be
taken before we return.
Unless we interrupted a context with irqs-masked, we can call
irq_work_run() to do the work now. Otherwise return -EINPROGRESS to
indicate ghes_notify_sea() found some work to do, but it hasn't
finished yet.
With this we can take apei_claim_sea() returning '0' to mean this
external-abort was also notification of a firmware-first RAS error,
and that APEI has processed the CPER records.
Signed-off-by: James Morse <james.morse@arm.com>
---
arch/arm64/kernel/acpi.c | 19 +++++++++++++++++++
arch/arm64/mm/fault.c | 9 ++++-----
2 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 6a4823a3eb5e..a51a7abd98e0 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -22,6 +22,7 @@
#include <linux/init.h>
#include <linux/irq.h>
#include <linux/irqdomain.h>
+#include <linux/irq_work.h>
#include <linux/memblock.h>
#include <linux/of_fdt.h>
#include <linux/smp.h>
@@ -275,10 +276,14 @@ int apei_claim_sea(struct pt_regs *regs)
{
int err = -ENOENT;
unsigned long current_flags = arch_local_save_flags();
+ unsigned long interrupted_flags = current_flags;
if (!IS_ENABLED(CONFIG_ACPI_APEI_SEA))
return err;
+ if (regs)
+ interrupted_flags = regs->pstate;
+
/*
* APEI expects an NMI-like notification to always be called
* in NMI context.
@@ -287,6 +292,20 @@ int apei_claim_sea(struct pt_regs *regs)
nmi_enter();
err = ghes_notify_sea();
nmi_exit();
+
+ /*
+ * APEI NMI-like notifications are deferred to irq_work. Unless
+ * we interrupted irqs-masked code, we can do that now.
+ */
+ if (!err) {
+ if (!arch_irqs_disabled_flags(interrupted_flags)) {
+ local_daif_restore(DAIF_PROCCTX_NOIRQ);
+ irq_work_run();
+ } else {
+ err = -EINPROGRESS;
+ }
+ }
+
local_daif_restore(current_flags);
return err;
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 8cbbd9a5ec7d..e218e291a17a 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -580,11 +580,10 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
inf->name, esr, addr);
if (IS_ENABLED(CONFIG_ACPI_APEI_SEA)) {
- /*
- * Return value ignored as we rely on signal merging.
- * Future patches will make this more robust.
- */
- apei_claim_sea(regs);
+ if (apei_claim_sea(regs) == 0) {
+ /* APEI claimed this as a firmware-first notification */
+ return 0;
+ }
}
info.si_signo = SIGBUS;
--
2.15.1
^ permalink raw reply related [flat|nested] 94+ messages in thread
* Re: [PATCH 00/11] APEI in_nmi() rework and arm64 SDEI wire-up
2018-02-15 18:55 ` James Morse
(?)
@ 2018-02-19 21:05 ` Borislav Petkov
-1 siblings, 0 replies; 94+ messages in thread
From: Borislav Petkov @ 2018-02-19 21:05 UTC (permalink / raw)
To: James Morse
Cc: Rafael Wysocki, Tony Luck, Xie XiuQi, linux-mm, Marc Zyngier,
Catalin Marinas, Tyler Baicar, Will Deacon, Dongjiu Geng,
linux-acpi, Punit Agrawal, linux-arm-kernel, Naoya Horiguchi,
kvmarm, Christoffer Dall, Len Brown
On Thu, Feb 15, 2018 at 06:55:55PM +0000, James Morse wrote:
> Hello!
>
> The aim of this series is to wire arm64's SDEI into APEI.
>
> What's SDEI? Its ARM's "Software Delegated Exception Interface" [0]. It's
> used by firmware to tell the OS about firmware-first RAS events.
>
> These Software exceptions can interrupt anything, so I describe them as
> NMI-like. They aren't the only NMI-like way to notify the OS about
> firmware-first RAS events, the ACPI spec also defines 'NOTFIY_SEA' and
> 'NOTIFY_SEI'.
>
> (Acronyms: SEA, Synchronous External Abort. The CPU requested some memory,
> but the owner of that memory said no. These are always synchronous with the
> instruction that caused them. SEI, System-Error Interrupt, commonly called
> SError. This is an asynchronous external abort, the memory-owner didn't say no
> at the right point. Collectively these things are called external-aborts
> How is firmware involved? It traps these and re-injects them into the kernel
> once its written the CPER records).
Thank you about those! This is how people should write 0/N introductory
messages with fancy new abbreviations.
:-)
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 00/11] APEI in_nmi() rework and arm64 SDEI wire-up
@ 2018-02-19 21:05 ` Borislav Petkov
0 siblings, 0 replies; 94+ messages in thread
From: Borislav Petkov @ 2018-02-19 21:05 UTC (permalink / raw)
To: James Morse
Cc: linux-acpi, kvmarm, linux-arm-kernel, linux-mm, Christoffer Dall,
Marc Zyngier, Catalin Marinas, Will Deacon, Naoya Horiguchi,
Rafael Wysocki, Len Brown, Tony Luck, Tyler Baicar, Dongjiu Geng,
Xie XiuQi, Punit Agrawal
On Thu, Feb 15, 2018 at 06:55:55PM +0000, James Morse wrote:
> Hello!
>
> The aim of this series is to wire arm64's SDEI into APEI.
>
> What's SDEI? Its ARM's "Software Delegated Exception Interface" [0]. It's
> used by firmware to tell the OS about firmware-first RAS events.
>
> These Software exceptions can interrupt anything, so I describe them as
> NMI-like. They aren't the only NMI-like way to notify the OS about
> firmware-first RAS events, the ACPI spec also defines 'NOTFIY_SEA' and
> 'NOTIFY_SEI'.
>
> (Acronyms: SEA, Synchronous External Abort. The CPU requested some memory,
> but the owner of that memory said no. These are always synchronous with the
> instruction that caused them. SEI, System-Error Interrupt, commonly called
> SError. This is an asynchronous external abort, the memory-owner didn't say no
> at the right point. Collectively these things are called external-aborts
> How is firmware involved? It traps these and re-injects them into the kernel
> once its written the CPER records).
Thank you about those! This is how people should write 0/N introductory
messages with fancy new abbreviations.
:-)
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH 00/11] APEI in_nmi() rework and arm64 SDEI wire-up
@ 2018-02-19 21:05 ` Borislav Petkov
0 siblings, 0 replies; 94+ messages in thread
From: Borislav Petkov @ 2018-02-19 21:05 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Feb 15, 2018 at 06:55:55PM +0000, James Morse wrote:
> Hello!
>
> The aim of this series is to wire arm64's SDEI into APEI.
>
> What's SDEI? Its ARM's "Software Delegated Exception Interface" [0]. It's
> used by firmware to tell the OS about firmware-first RAS events.
>
> These Software exceptions can interrupt anything, so I describe them as
> NMI-like. They aren't the only NMI-like way to notify the OS about
> firmware-first RAS events, the ACPI spec also defines 'NOTFIY_SEA' and
> 'NOTIFY_SEI'.
>
> (Acronyms: SEA, Synchronous External Abort. The CPU requested some memory,
> but the owner of that memory said no. These are always synchronous with the
> instruction that caused them. SEI, System-Error Interrupt, commonly called
> SError. This is an asynchronous external abort, the memory-owner didn't say no
> at the right point. Collectively these things are called external-aborts
> How is firmware involved? It traps these and re-injects them into the kernel
> once its written the CPER records).
Thank you about those! This is how people should write 0/N introductory
messages with fancy new abbreviations.
:-)
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 01/11] ACPI / APEI: Move the estatus queue code up, and under its own ifdef
2018-02-15 18:55 ` James Morse
(?)
@ 2018-02-20 18:26 ` Punit Agrawal
-1 siblings, 0 replies; 94+ messages in thread
From: Punit Agrawal @ 2018-02-20 18:26 UTC (permalink / raw)
To: James Morse
Cc: Rafael Wysocki, Tony Luck, linux-mm, Marc Zyngier,
Catalin Marinas, Tyler Baicar, Will Deacon, Dongjiu Geng,
linux-acpi, Borislav Petkov, linux-arm-kernel, Naoya Horiguchi,
kvmarm, Len Brown
Hi James,
A couple of nitpicks below.
James Morse <james.morse@arm.com> writes:
> To support asynchronous NMI-like notifications on arm64 we need to use
> the estatus-queue. These patches refactor it to allow multiple APEI
> notification types to use it.
>
> First we move the estatus-queue code higher in the file so that any
> notify_foo() handler can make user of it.
^
use
>
> This patch moves code around ... and makes the following trivial change:
> Freshen the dated comment above ghes_estatus_llist. printk() is no
> longer the issue, its the helpers like memory_failure_queue() that
> still aren't nmi safe.
>
> Signed-off-by: James Morse <james.morse@arm.com>
> ---
> drivers/acpi/apei/ghes.c | 267 ++++++++++++++++++++++++-----------------------
> 1 file changed, 139 insertions(+), 128 deletions(-)
>
> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
> index 1efefe919555..e42b587c509b 100644
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
> @@ -545,6 +545,16 @@ static int ghes_print_estatus(const char *pfx,
> return 0;
> }
>
> +static void __ghes_panic(struct ghes *ghes)
> +{
> + __ghes_print_estatus(KERN_EMERG, ghes->generic, ghes->estatus);
> +
> + /* reboot to log the error! */
> + if (!panic_timeout)
> + panic_timeout = ghes_panic_timeout;
> + panic("Fatal hardware error!");
> +}
> +
> /*
> * GHES error status reporting throttle, to report more kinds of
> * errors, instead of just most frequently occurred errors.
> @@ -672,6 +682,135 @@ static void ghes_estatus_cache_add(
> rcu_read_unlock();
> }
>
> +#ifdef CONFIG_HAVE_ACPI_APEI_NMI
> +/*
> + * While printk() now has an in_nmi() path, the handling for CPER records
> + * does not. For example, memory_failure_queue() takes spinlocks and calls
> + * schedule_work_on().
> + *
> + * So in any NMI-like handler, we allocate required memory from lock-less
> + * memory allocator (ghes_estatus_pool), save estatus into it, put them into
> + * lock-less list (ghes_estatus_llist), then delay printk into IRQ context via
> + * irq_work (ghes_proc_irq_work). ghes_estatus_size_request record
> + * required pool size by all NMI error source.
I am not sure it is worth keeping specific references to printk
around. As you're refreshing the comment, I'd suggest replacing the
above reference with "...processing of error status reported by the
NMI..." or something similar.
Thanks,
Punit
[...]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 01/11] ACPI / APEI: Move the estatus queue code up, and under its own ifdef
@ 2018-02-20 18:26 ` Punit Agrawal
0 siblings, 0 replies; 94+ messages in thread
From: Punit Agrawal @ 2018-02-20 18:26 UTC (permalink / raw)
To: James Morse
Cc: linux-acpi, kvmarm, linux-arm-kernel, linux-mm, Borislav Petkov,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
Naoya Horiguchi, Rafael Wysocki, Len Brown, Tony Luck,
Tyler Baicar, Dongjiu Geng, Xie XiuQi
Hi James,
A couple of nitpicks below.
James Morse <james.morse@arm.com> writes:
> To support asynchronous NMI-like notifications on arm64 we need to use
> the estatus-queue. These patches refactor it to allow multiple APEI
> notification types to use it.
>
> First we move the estatus-queue code higher in the file so that any
> notify_foo() handler can make user of it.
^
use
>
> This patch moves code around ... and makes the following trivial change:
> Freshen the dated comment above ghes_estatus_llist. printk() is no
> longer the issue, its the helpers like memory_failure_queue() that
> still aren't nmi safe.
>
> Signed-off-by: James Morse <james.morse@arm.com>
> ---
> drivers/acpi/apei/ghes.c | 267 ++++++++++++++++++++++++-----------------------
> 1 file changed, 139 insertions(+), 128 deletions(-)
>
> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
> index 1efefe919555..e42b587c509b 100644
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
> @@ -545,6 +545,16 @@ static int ghes_print_estatus(const char *pfx,
> return 0;
> }
>
> +static void __ghes_panic(struct ghes *ghes)
> +{
> + __ghes_print_estatus(KERN_EMERG, ghes->generic, ghes->estatus);
> +
> + /* reboot to log the error! */
> + if (!panic_timeout)
> + panic_timeout = ghes_panic_timeout;
> + panic("Fatal hardware error!");
> +}
> +
> /*
> * GHES error status reporting throttle, to report more kinds of
> * errors, instead of just most frequently occurred errors.
> @@ -672,6 +682,135 @@ static void ghes_estatus_cache_add(
> rcu_read_unlock();
> }
>
> +#ifdef CONFIG_HAVE_ACPI_APEI_NMI
> +/*
> + * While printk() now has an in_nmi() path, the handling for CPER records
> + * does not. For example, memory_failure_queue() takes spinlocks and calls
> + * schedule_work_on().
> + *
> + * So in any NMI-like handler, we allocate required memory from lock-less
> + * memory allocator (ghes_estatus_pool), save estatus into it, put them into
> + * lock-less list (ghes_estatus_llist), then delay printk into IRQ context via
> + * irq_work (ghes_proc_irq_work). ghes_estatus_size_request record
> + * required pool size by all NMI error source.
I am not sure it is worth keeping specific references to printk
around. As you're refreshing the comment, I'd suggest replacing the
above reference with "...processing of error status reported by the
NMI..." or something similar.
Thanks,
Punit
[...]
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH 01/11] ACPI / APEI: Move the estatus queue code up, and under its own ifdef
@ 2018-02-20 18:26 ` Punit Agrawal
0 siblings, 0 replies; 94+ messages in thread
From: Punit Agrawal @ 2018-02-20 18:26 UTC (permalink / raw)
To: linux-arm-kernel
Hi James,
A couple of nitpicks below.
James Morse <james.morse@arm.com> writes:
> To support asynchronous NMI-like notifications on arm64 we need to use
> the estatus-queue. These patches refactor it to allow multiple APEI
> notification types to use it.
>
> First we move the estatus-queue code higher in the file so that any
> notify_foo() handler can make user of it.
^
use
>
> This patch moves code around ... and makes the following trivial change:
> Freshen the dated comment above ghes_estatus_llist. printk() is no
> longer the issue, its the helpers like memory_failure_queue() that
> still aren't nmi safe.
>
> Signed-off-by: James Morse <james.morse@arm.com>
> ---
> drivers/acpi/apei/ghes.c | 267 ++++++++++++++++++++++++-----------------------
> 1 file changed, 139 insertions(+), 128 deletions(-)
>
> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
> index 1efefe919555..e42b587c509b 100644
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
> @@ -545,6 +545,16 @@ static int ghes_print_estatus(const char *pfx,
> return 0;
> }
>
> +static void __ghes_panic(struct ghes *ghes)
> +{
> + __ghes_print_estatus(KERN_EMERG, ghes->generic, ghes->estatus);
> +
> + /* reboot to log the error! */
> + if (!panic_timeout)
> + panic_timeout = ghes_panic_timeout;
> + panic("Fatal hardware error!");
> +}
> +
> /*
> * GHES error status reporting throttle, to report more kinds of
> * errors, instead of just most frequently occurred errors.
> @@ -672,6 +682,135 @@ static void ghes_estatus_cache_add(
> rcu_read_unlock();
> }
>
> +#ifdef CONFIG_HAVE_ACPI_APEI_NMI
> +/*
> + * While printk() now has an in_nmi() path, the handling for CPER records
> + * does not. For example, memory_failure_queue() takes spinlocks and calls
> + * schedule_work_on().
> + *
> + * So in any NMI-like handler, we allocate required memory from lock-less
> + * memory allocator (ghes_estatus_pool), save estatus into it, put them into
> + * lock-less list (ghes_estatus_llist), then delay printk into IRQ context via
> + * irq_work (ghes_proc_irq_work). ghes_estatus_size_request record
> + * required pool size by all NMI error source.
I am not sure it is worth keeping specific references to printk
around. As you're refreshing the comment, I'd suggest replacing the
above reference with "...processing of error status reported by the
NMI..." or something similar.
Thanks,
Punit
[...]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code
2018-02-15 18:55 ` James Morse
(?)
@ 2018-02-20 18:26 ` Punit Agrawal
-1 siblings, 0 replies; 94+ messages in thread
From: Punit Agrawal @ 2018-02-20 18:26 UTC (permalink / raw)
To: James Morse
Cc: Rafael Wysocki, Tony Luck, linux-mm, Marc Zyngier,
Catalin Marinas, Tyler Baicar, Will Deacon, Dongjiu Geng,
linux-acpi, Borislav Petkov, linux-arm-kernel, Naoya Horiguchi,
kvmarm, Len Brown
A few of typos and comments below.
James Morse <james.morse@arm.com> writes:
> To support asynchronous NMI-like notifications on arm64 we need to use
> the estatus-queue. These patches refactor it to allow multiple APEI
> notification types to use it.
>
> Refactor the estatus queue's pool grow/shrink code and notification
> routine from NOTIFY_NMI's handlers. This will allow another notification
> method to use the estatus queue without duplicating this code.
>
> This patch adds rcu_read_lock()/rcu_read_unlock() around the list
> list_for_each_entry_rcu() walker. These aren't strictly necessary as
> the whole nmi_enter/nmi_exit() window is a spooky RCU read-side
> critical section.
>
> Keep the oops_begin() call for x86, arm64 doesn't have one of these,
> and APEI is the only thing outside arch code calling this..
>
> The existing ghes_estatus_pool_shrink() is folded into the new
> ghes_estatus_queue_shrink_pool() as only the queue uses it.
>
> _in_nmi_notify_one() is separate from the rcu-list walker for a later
> caller that doesn't need to walk a list.
>
> Signed-off-by: James Morse <james.morse@arm.com>
> ---
> drivers/acpi/apei/ghes.c | 103 +++++++++++++++++++++++++++++++----------------
> 1 file changed, 68 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
> index e42b587c509b..d3cc5bd5b496 100644
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
> @@ -749,6 +749,54 @@ static void __process_error(struct ghes *ghes)
> #endif
> }
>
> +static int _in_nmi_notify_one(struct ghes *ghes)
> +{
> + int sev;
> + int ret = -ENOENT;
If ret is initialised to 0 ...
> +
> + if (ghes_read_estatus(ghes, 1)) {
> + ghes_clear_estatus(ghes);
> + return ret;
and return -ENOENT here...
> + } else {
> + ret = 0;
> + }
... then the else block can be dropped.
> +
> + sev = ghes_severity(ghes->estatus->error_severity);
> + if (sev >= GHES_SEV_PANIC) {
> +#ifdef CONFIG_X86
> + oops_begin();
> +#endif
Can you use IS_ENABLED() here as well?
> + ghes_print_queued_estatus();
> + __ghes_panic(ghes);
> + }
> +
> + if (!(ghes->flags & GHES_TO_CLEAR))
> + return ret;
> +
> + __process_error(ghes);
> + ghes_clear_estatus(ghes);
> +
> + return ret;
> +}
> +
> +static int ghes_estatus_queue_notified(struct list_head *rcu_list)
> +{
> + int ret = -ENOENT;
> + struct ghes *ghes;
> +
> + rcu_read_lock();
> + list_for_each_entry_rcu(ghes, rcu_list, list) {
> + if (!_in_nmi_notify_one(ghes))
> + ret = 0;
> + }
> + rcu_read_unlock();
> +
> + if (IS_ENABLED(CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG) && ret == 0)
> + irq_work_queue(&ghes_proc_irq_work);
> +
> + return ret;
> +}
> +
> static unsigned long ghes_esource_prealloc_size(
> const struct acpi_hest_generic *generic)
> {
> @@ -764,11 +812,24 @@ static unsigned long ghes_esource_prealloc_size(
> return prealloc_size;
> }
>
> -static void ghes_estatus_pool_shrink(unsigned long len)
> +/* After removing a queue user, we can shrink to pool */
^
the
Thanks,
Punit
> +static void ghes_estatus_queue_shrink_pool(struct ghes *ghes)
> {
> + unsigned long len;
> +
> + len = ghes_esource_prealloc_size(ghes->generic);
> ghes_estatus_pool_size_request -= PAGE_ALIGN(len);
> }
>
[...]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code
@ 2018-02-20 18:26 ` Punit Agrawal
0 siblings, 0 replies; 94+ messages in thread
From: Punit Agrawal @ 2018-02-20 18:26 UTC (permalink / raw)
To: James Morse
Cc: linux-acpi, kvmarm, linux-arm-kernel, linux-mm, Borislav Petkov,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
Naoya Horiguchi, Rafael Wysocki, Len Brown, Tony Luck,
Tyler Baicar, Dongjiu Geng, Xie XiuQi
A few of typos and comments below.
James Morse <james.morse@arm.com> writes:
> To support asynchronous NMI-like notifications on arm64 we need to use
> the estatus-queue. These patches refactor it to allow multiple APEI
> notification types to use it.
>
> Refactor the estatus queue's pool grow/shrink code and notification
> routine from NOTIFY_NMI's handlers. This will allow another notification
> method to use the estatus queue without duplicating this code.
>
> This patch adds rcu_read_lock()/rcu_read_unlock() around the list
> list_for_each_entry_rcu() walker. These aren't strictly necessary as
> the whole nmi_enter/nmi_exit() window is a spooky RCU read-side
> critical section.
>
> Keep the oops_begin() call for x86, arm64 doesn't have one of these,
> and APEI is the only thing outside arch code calling this..
>
> The existing ghes_estatus_pool_shrink() is folded into the new
> ghes_estatus_queue_shrink_pool() as only the queue uses it.
>
> _in_nmi_notify_one() is separate from the rcu-list walker for a later
> caller that doesn't need to walk a list.
>
> Signed-off-by: James Morse <james.morse@arm.com>
> ---
> drivers/acpi/apei/ghes.c | 103 +++++++++++++++++++++++++++++++----------------
> 1 file changed, 68 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
> index e42b587c509b..d3cc5bd5b496 100644
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
> @@ -749,6 +749,54 @@ static void __process_error(struct ghes *ghes)
> #endif
> }
>
> +static int _in_nmi_notify_one(struct ghes *ghes)
> +{
> + int sev;
> + int ret = -ENOENT;
If ret is initialised to 0 ...
> +
> + if (ghes_read_estatus(ghes, 1)) {
> + ghes_clear_estatus(ghes);
> + return ret;
and return -ENOENT here...
> + } else {
> + ret = 0;
> + }
... then the else block can be dropped.
> +
> + sev = ghes_severity(ghes->estatus->error_severity);
> + if (sev >= GHES_SEV_PANIC) {
> +#ifdef CONFIG_X86
> + oops_begin();
> +#endif
Can you use IS_ENABLED() here as well?
> + ghes_print_queued_estatus();
> + __ghes_panic(ghes);
> + }
> +
> + if (!(ghes->flags & GHES_TO_CLEAR))
> + return ret;
> +
> + __process_error(ghes);
> + ghes_clear_estatus(ghes);
> +
> + return ret;
> +}
> +
> +static int ghes_estatus_queue_notified(struct list_head *rcu_list)
> +{
> + int ret = -ENOENT;
> + struct ghes *ghes;
> +
> + rcu_read_lock();
> + list_for_each_entry_rcu(ghes, rcu_list, list) {
> + if (!_in_nmi_notify_one(ghes))
> + ret = 0;
> + }
> + rcu_read_unlock();
> +
> + if (IS_ENABLED(CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG) && ret == 0)
> + irq_work_queue(&ghes_proc_irq_work);
> +
> + return ret;
> +}
> +
> static unsigned long ghes_esource_prealloc_size(
> const struct acpi_hest_generic *generic)
> {
> @@ -764,11 +812,24 @@ static unsigned long ghes_esource_prealloc_size(
> return prealloc_size;
> }
>
> -static void ghes_estatus_pool_shrink(unsigned long len)
> +/* After removing a queue user, we can shrink to pool */
^
the
Thanks,
Punit
> +static void ghes_estatus_queue_shrink_pool(struct ghes *ghes)
> {
> + unsigned long len;
> +
> + len = ghes_esource_prealloc_size(ghes->generic);
> ghes_estatus_pool_size_request -= PAGE_ALIGN(len);
> }
>
[...]
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code
@ 2018-02-20 18:26 ` Punit Agrawal
0 siblings, 0 replies; 94+ messages in thread
From: Punit Agrawal @ 2018-02-20 18:26 UTC (permalink / raw)
To: linux-arm-kernel
A few of typos and comments below.
James Morse <james.morse@arm.com> writes:
> To support asynchronous NMI-like notifications on arm64 we need to use
> the estatus-queue. These patches refactor it to allow multiple APEI
> notification types to use it.
>
> Refactor the estatus queue's pool grow/shrink code and notification
> routine from NOTIFY_NMI's handlers. This will allow another notification
> method to use the estatus queue without duplicating this code.
>
> This patch adds rcu_read_lock()/rcu_read_unlock() around the list
> list_for_each_entry_rcu() walker. These aren't strictly necessary as
> the whole nmi_enter/nmi_exit() window is a spooky RCU read-side
> critical section.
>
> Keep the oops_begin() call for x86, arm64 doesn't have one of these,
> and APEI is the only thing outside arch code calling this..
>
> The existing ghes_estatus_pool_shrink() is folded into the new
> ghes_estatus_queue_shrink_pool() as only the queue uses it.
>
> _in_nmi_notify_one() is separate from the rcu-list walker for a later
> caller that doesn't need to walk a list.
>
> Signed-off-by: James Morse <james.morse@arm.com>
> ---
> drivers/acpi/apei/ghes.c | 103 +++++++++++++++++++++++++++++++----------------
> 1 file changed, 68 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
> index e42b587c509b..d3cc5bd5b496 100644
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
> @@ -749,6 +749,54 @@ static void __process_error(struct ghes *ghes)
> #endif
> }
>
> +static int _in_nmi_notify_one(struct ghes *ghes)
> +{
> + int sev;
> + int ret = -ENOENT;
If ret is initialised to 0 ...
> +
> + if (ghes_read_estatus(ghes, 1)) {
> + ghes_clear_estatus(ghes);
> + return ret;
and return -ENOENT here...
> + } else {
> + ret = 0;
> + }
... then the else block can be dropped.
> +
> + sev = ghes_severity(ghes->estatus->error_severity);
> + if (sev >= GHES_SEV_PANIC) {
> +#ifdef CONFIG_X86
> + oops_begin();
> +#endif
Can you use IS_ENABLED() here as well?
> + ghes_print_queued_estatus();
> + __ghes_panic(ghes);
> + }
> +
> + if (!(ghes->flags & GHES_TO_CLEAR))
> + return ret;
> +
> + __process_error(ghes);
> + ghes_clear_estatus(ghes);
> +
> + return ret;
> +}
> +
> +static int ghes_estatus_queue_notified(struct list_head *rcu_list)
> +{
> + int ret = -ENOENT;
> + struct ghes *ghes;
> +
> + rcu_read_lock();
> + list_for_each_entry_rcu(ghes, rcu_list, list) {
> + if (!_in_nmi_notify_one(ghes))
> + ret = 0;
> + }
> + rcu_read_unlock();
> +
> + if (IS_ENABLED(CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG) && ret == 0)
> + irq_work_queue(&ghes_proc_irq_work);
> +
> + return ret;
> +}
> +
> static unsigned long ghes_esource_prealloc_size(
> const struct acpi_hest_generic *generic)
> {
> @@ -764,11 +812,24 @@ static unsigned long ghes_esource_prealloc_size(
> return prealloc_size;
> }
>
> -static void ghes_estatus_pool_shrink(unsigned long len)
> +/* After removing a queue user, we can shrink to pool */
^
the
Thanks,
Punit
> +static void ghes_estatus_queue_shrink_pool(struct ghes *ghes)
> {
> + unsigned long len;
> +
> + len = ghes_esource_prealloc_size(ghes->generic);
> ghes_estatus_pool_size_request -= PAGE_ALIGN(len);
> }
>
[...]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 05/11] arm64: KVM/mm: Move SEA handling behind a single 'claim' interface
2018-02-15 18:56 ` James Morse
(?)
@ 2018-02-20 18:30 ` Punit Agrawal
-1 siblings, 0 replies; 94+ messages in thread
From: Punit Agrawal @ 2018-02-20 18:30 UTC (permalink / raw)
To: James Morse
Cc: Rafael Wysocki, Tony Luck, Xie XiuQi, linux-mm, Marc Zyngier,
Catalin Marinas, Tyler Baicar, Will Deacon, Dongjiu Geng,
linux-acpi, Borislav Petkov, linux-arm-kernel, Naoya Horiguchi,
kvmarm, Christoffer Dall, Len Brown
One typo in the commit log otherwise looks good.
James Morse <james.morse@arm.com> writes:
> To split up APEIs in_nmi() path, we need the nmi-like callers to always
> be in_nmi(). Add a helper to do the work and claim the notification.
>
> When KVM or the arch code takes an exception that might be a RAS
> notification, it asks the APEI firmware-first code whether it wants
> to claim the exception. We can then go on to see if (a future)
> kernel-first mechanism wants to claim the notification, before
> falling through to the existing default behaviour.
>
> The NOTIFY_SEA code was merged before we had multiple, possibly
> interacting, NMI-like notifications and the need to consider kernel
> first in the future. Make the 'claiming' behaviour explicit.
>
> As we're restructuring the APEI code to allow multiple NMI-like
> notifications, any notification that might interrupt interrupts-masked
> code must always be wrapped in nmi_enter()/nmi_exit(). This allows APEI
> to use in_nmi() so choose between the raw/regular spinlock routines.
^
to
Thanks,
Punit
>
> We mask SError over this window to prevent an asynchronous RAS error
> arriving and tripping 'nmi_enter()'s BUG_ON(in_nmi()).
>
> Signed-off-by: James Morse <james.morse@arm.com>
> CC: Tyler Baicar <tbaicar@codeaurora.org>
> ---
> Why does apei_claim_sea() take a pt_regs? This gets used later to take
> APEI by the hand through NMI->IRQ context, depending on what we
> interrupted.
>
> arch/arm64/include/asm/acpi.h | 3 +++
> arch/arm64/include/asm/daifflags.h | 1 +
> arch/arm64/include/asm/kvm_ras.h | 20 +++++++++++++++++++-
> arch/arm64/kernel/acpi.c | 30 ++++++++++++++++++++++++++++++
> arch/arm64/mm/fault.c | 31 +++++++------------------------
> 5 files changed, 60 insertions(+), 25 deletions(-)
>
[...]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 05/11] arm64: KVM/mm: Move SEA handling behind a single 'claim' interface
@ 2018-02-20 18:30 ` Punit Agrawal
0 siblings, 0 replies; 94+ messages in thread
From: Punit Agrawal @ 2018-02-20 18:30 UTC (permalink / raw)
To: James Morse
Cc: linux-acpi, kvmarm, linux-arm-kernel, linux-mm, Borislav Petkov,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
Naoya Horiguchi, Rafael Wysocki, Len Brown, Tony Luck,
Tyler Baicar, Dongjiu Geng, Xie XiuQi
One typo in the commit log otherwise looks good.
James Morse <james.morse@arm.com> writes:
> To split up APEIs in_nmi() path, we need the nmi-like callers to always
> be in_nmi(). Add a helper to do the work and claim the notification.
>
> When KVM or the arch code takes an exception that might be a RAS
> notification, it asks the APEI firmware-first code whether it wants
> to claim the exception. We can then go on to see if (a future)
> kernel-first mechanism wants to claim the notification, before
> falling through to the existing default behaviour.
>
> The NOTIFY_SEA code was merged before we had multiple, possibly
> interacting, NMI-like notifications and the need to consider kernel
> first in the future. Make the 'claiming' behaviour explicit.
>
> As we're restructuring the APEI code to allow multiple NMI-like
> notifications, any notification that might interrupt interrupts-masked
> code must always be wrapped in nmi_enter()/nmi_exit(). This allows APEI
> to use in_nmi() so choose between the raw/regular spinlock routines.
^
to
Thanks,
Punit
>
> We mask SError over this window to prevent an asynchronous RAS error
> arriving and tripping 'nmi_enter()'s BUG_ON(in_nmi()).
>
> Signed-off-by: James Morse <james.morse@arm.com>
> CC: Tyler Baicar <tbaicar@codeaurora.org>
> ---
> Why does apei_claim_sea() take a pt_regs? This gets used later to take
> APEI by the hand through NMI->IRQ context, depending on what we
> interrupted.
>
> arch/arm64/include/asm/acpi.h | 3 +++
> arch/arm64/include/asm/daifflags.h | 1 +
> arch/arm64/include/asm/kvm_ras.h | 20 +++++++++++++++++++-
> arch/arm64/kernel/acpi.c | 30 ++++++++++++++++++++++++++++++
> arch/arm64/mm/fault.c | 31 +++++++------------------------
> 5 files changed, 60 insertions(+), 25 deletions(-)
>
[...]
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH 05/11] arm64: KVM/mm: Move SEA handling behind a single 'claim' interface
@ 2018-02-20 18:30 ` Punit Agrawal
0 siblings, 0 replies; 94+ messages in thread
From: Punit Agrawal @ 2018-02-20 18:30 UTC (permalink / raw)
To: linux-arm-kernel
One typo in the commit log otherwise looks good.
James Morse <james.morse@arm.com> writes:
> To split up APEIs in_nmi() path, we need the nmi-like callers to always
> be in_nmi(). Add a helper to do the work and claim the notification.
>
> When KVM or the arch code takes an exception that might be a RAS
> notification, it asks the APEI firmware-first code whether it wants
> to claim the exception. We can then go on to see if (a future)
> kernel-first mechanism wants to claim the notification, before
> falling through to the existing default behaviour.
>
> The NOTIFY_SEA code was merged before we had multiple, possibly
> interacting, NMI-like notifications and the need to consider kernel
> first in the future. Make the 'claiming' behaviour explicit.
>
> As we're restructuring the APEI code to allow multiple NMI-like
> notifications, any notification that might interrupt interrupts-masked
> code must always be wrapped in nmi_enter()/nmi_exit(). This allows APEI
> to use in_nmi() so choose between the raw/regular spinlock routines.
^
to
Thanks,
Punit
>
> We mask SError over this window to prevent an asynchronous RAS error
> arriving and tripping 'nmi_enter()'s BUG_ON(in_nmi()).
>
> Signed-off-by: James Morse <james.morse@arm.com>
> CC: Tyler Baicar <tbaicar@codeaurora.org>
> ---
> Why does apei_claim_sea() take a pt_regs? This gets used later to take
> APEI by the hand through NMI->IRQ context, depending on what we
> interrupted.
>
> arch/arm64/include/asm/acpi.h | 3 +++
> arch/arm64/include/asm/daifflags.h | 1 +
> arch/arm64/include/asm/kvm_ras.h | 20 +++++++++++++++++++-
> arch/arm64/kernel/acpi.c | 30 ++++++++++++++++++++++++++++++
> arch/arm64/mm/fault.c | 31 +++++++------------------------
> 5 files changed, 60 insertions(+), 25 deletions(-)
>
[...]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 08/11] firmware: arm_sdei: Add ACPI GHES registration helper
2018-02-15 18:56 ` James Morse
(?)
@ 2018-02-20 18:31 ` Punit Agrawal
-1 siblings, 0 replies; 94+ messages in thread
From: Punit Agrawal @ 2018-02-20 18:31 UTC (permalink / raw)
To: James Morse
Cc: Rafael Wysocki, Tony Luck, Xie XiuQi, linux-mm, Marc Zyngier,
Catalin Marinas, Tyler Baicar, Will Deacon, Dongjiu Geng,
linux-acpi, Borislav Petkov, linux-arm-kernel, Naoya Horiguchi,
kvmarm, Christoffer Dall, Len Brown
Hi James,
One typo below.
James Morse <james.morse@arm.com> writes:
> APEI's Generic Hardware Error Source structures do not describe
> whether the SDEI event is shared or private, as this information is
> discoverable via the API.
>
> GHES needs to know whether an event is normal or critical to avoid
> sharing locks or fixmap entries.
>
> Add a helper to ask firmware for this information so it can initialise
> the struct ghes and register then enable the event.
>
> Signed-off-by: James Morse <james.morse@arm.com>
> ---
> arch/arm64/include/asm/fixmap.h | 4 +++
> drivers/firmware/arm_sdei.c | 75 +++++++++++++++++++++++++++++++++++++++++
> include/linux/arm_sdei.h | 5 +++
> 3 files changed, 84 insertions(+)
>
> diff --git a/arch/arm64/include/asm/fixmap.h b/arch/arm64/include/asm/fixmap.h
> index c3974517c2cb..e2b423a5feaf 100644
> --- a/arch/arm64/include/asm/fixmap.h
> +++ b/arch/arm64/include/asm/fixmap.h
> @@ -58,6 +58,10 @@ enum fixed_addresses {
> #ifdef CONFIG_ACPI_APEI_SEA
> FIX_APEI_GHES_SEA,
> #endif
> +#ifdef CONFIG_ARM_SDE_INTERFACE
> + FIX_APEI_GHES_SDEI_NORMAL,
> + FIX_APEI_GHES_SDEI_CRITICAL,
> +#endif
> #endif /* CONFIG_ACPI_APEI_GHES */
>
> #ifdef CONFIG_UNMAP_KERNEL_AT_EL0
> diff --git a/drivers/firmware/arm_sdei.c b/drivers/firmware/arm_sdei.c
> index 1ea71640fdc2..9b6e140cf6cb 100644
> --- a/drivers/firmware/arm_sdei.c
> +++ b/drivers/firmware/arm_sdei.c
> @@ -2,6 +2,7 @@
> // Copyright (C) 2017 Arm Ltd.
> #define pr_fmt(fmt) "sdei: " fmt
>
> +#include <acpi/ghes.h>
> #include <linux/acpi.h>
> #include <linux/arm_sdei.h>
> #include <linux/arm-smccc.h>
> @@ -887,6 +888,80 @@ static void sdei_smccc_hvc(unsigned long function_id,
> arm_smccc_hvc(function_id, arg0, arg1, arg2, arg3, arg4, 0, 0, res);
> }
>
> +#ifdef CONFIG_ACPI
> +/* These stop private notifications using the fixmap entries simultaneously */
> +static DEFINE_RAW_SPINLOCK(sdei_ghes_fixmap_lock_normal);
> +static DEFINE_RAW_SPINLOCK(sdei_ghes_fixmap_lock_critical);
> +
> +int sdei_register_ghes(struct ghes *ghes, sdei_event_callback *cb)
> +{
> + int err;
> + u32 event_num;
> + u64 result;
> +
> + if (acpi_disabled)
> + return -EOPNOTSUPP;
> +
> + event_num = ghes->generic->notify.vector;
> + if (event_num == 0) {
> + /*
> + * Event 0 is the reserved by the specification for
^
Typo.
Thanks,
Punit
> + * SDEI_EVENT_SIGNAL.
> + */
> + return -EINVAL;
> + }
> +
> + err = sdei_api_event_get_info(event_num, SDEI_EVENT_INFO_EV_PRIORITY,
> + &result);
> + if (err)
> + return err;
> +
> + if (result == SDEI_EVENT_PRIORITY_CRITICAL) {
> + ghes->nmi_fixmap_lock = &sdei_ghes_fixmap_lock_critical;
> + ghes->fixmap_idx = FIX_APEI_GHES_SDEI_CRITICAL;
> + } else {
> + ghes->nmi_fixmap_lock = &sdei_ghes_fixmap_lock_normal;
> + ghes->fixmap_idx = FIX_APEI_GHES_SDEI_NORMAL;
> + }
> +
> + err = sdei_event_register(event_num, cb, ghes);
> + if (!err)
> + err = sdei_event_enable(event_num);
> +
> + return err;
> +}
> +
[...]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 08/11] firmware: arm_sdei: Add ACPI GHES registration helper
@ 2018-02-20 18:31 ` Punit Agrawal
0 siblings, 0 replies; 94+ messages in thread
From: Punit Agrawal @ 2018-02-20 18:31 UTC (permalink / raw)
To: James Morse
Cc: linux-acpi, kvmarm, linux-arm-kernel, linux-mm, Borislav Petkov,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
Naoya Horiguchi, Rafael Wysocki, Len Brown, Tony Luck,
Tyler Baicar, Dongjiu Geng, Xie XiuQi
Hi James,
One typo below.
James Morse <james.morse@arm.com> writes:
> APEI's Generic Hardware Error Source structures do not describe
> whether the SDEI event is shared or private, as this information is
> discoverable via the API.
>
> GHES needs to know whether an event is normal or critical to avoid
> sharing locks or fixmap entries.
>
> Add a helper to ask firmware for this information so it can initialise
> the struct ghes and register then enable the event.
>
> Signed-off-by: James Morse <james.morse@arm.com>
> ---
> arch/arm64/include/asm/fixmap.h | 4 +++
> drivers/firmware/arm_sdei.c | 75 +++++++++++++++++++++++++++++++++++++++++
> include/linux/arm_sdei.h | 5 +++
> 3 files changed, 84 insertions(+)
>
> diff --git a/arch/arm64/include/asm/fixmap.h b/arch/arm64/include/asm/fixmap.h
> index c3974517c2cb..e2b423a5feaf 100644
> --- a/arch/arm64/include/asm/fixmap.h
> +++ b/arch/arm64/include/asm/fixmap.h
> @@ -58,6 +58,10 @@ enum fixed_addresses {
> #ifdef CONFIG_ACPI_APEI_SEA
> FIX_APEI_GHES_SEA,
> #endif
> +#ifdef CONFIG_ARM_SDE_INTERFACE
> + FIX_APEI_GHES_SDEI_NORMAL,
> + FIX_APEI_GHES_SDEI_CRITICAL,
> +#endif
> #endif /* CONFIG_ACPI_APEI_GHES */
>
> #ifdef CONFIG_UNMAP_KERNEL_AT_EL0
> diff --git a/drivers/firmware/arm_sdei.c b/drivers/firmware/arm_sdei.c
> index 1ea71640fdc2..9b6e140cf6cb 100644
> --- a/drivers/firmware/arm_sdei.c
> +++ b/drivers/firmware/arm_sdei.c
> @@ -2,6 +2,7 @@
> // Copyright (C) 2017 Arm Ltd.
> #define pr_fmt(fmt) "sdei: " fmt
>
> +#include <acpi/ghes.h>
> #include <linux/acpi.h>
> #include <linux/arm_sdei.h>
> #include <linux/arm-smccc.h>
> @@ -887,6 +888,80 @@ static void sdei_smccc_hvc(unsigned long function_id,
> arm_smccc_hvc(function_id, arg0, arg1, arg2, arg3, arg4, 0, 0, res);
> }
>
> +#ifdef CONFIG_ACPI
> +/* These stop private notifications using the fixmap entries simultaneously */
> +static DEFINE_RAW_SPINLOCK(sdei_ghes_fixmap_lock_normal);
> +static DEFINE_RAW_SPINLOCK(sdei_ghes_fixmap_lock_critical);
> +
> +int sdei_register_ghes(struct ghes *ghes, sdei_event_callback *cb)
> +{
> + int err;
> + u32 event_num;
> + u64 result;
> +
> + if (acpi_disabled)
> + return -EOPNOTSUPP;
> +
> + event_num = ghes->generic->notify.vector;
> + if (event_num == 0) {
> + /*
> + * Event 0 is the reserved by the specification for
^
Typo.
Thanks,
Punit
> + * SDEI_EVENT_SIGNAL.
> + */
> + return -EINVAL;
> + }
> +
> + err = sdei_api_event_get_info(event_num, SDEI_EVENT_INFO_EV_PRIORITY,
> + &result);
> + if (err)
> + return err;
> +
> + if (result == SDEI_EVENT_PRIORITY_CRITICAL) {
> + ghes->nmi_fixmap_lock = &sdei_ghes_fixmap_lock_critical;
> + ghes->fixmap_idx = FIX_APEI_GHES_SDEI_CRITICAL;
> + } else {
> + ghes->nmi_fixmap_lock = &sdei_ghes_fixmap_lock_normal;
> + ghes->fixmap_idx = FIX_APEI_GHES_SDEI_NORMAL;
> + }
> +
> + err = sdei_event_register(event_num, cb, ghes);
> + if (!err)
> + err = sdei_event_enable(event_num);
> +
> + return err;
> +}
> +
[...]
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH 08/11] firmware: arm_sdei: Add ACPI GHES registration helper
@ 2018-02-20 18:31 ` Punit Agrawal
0 siblings, 0 replies; 94+ messages in thread
From: Punit Agrawal @ 2018-02-20 18:31 UTC (permalink / raw)
To: linux-arm-kernel
Hi James,
One typo below.
James Morse <james.morse@arm.com> writes:
> APEI's Generic Hardware Error Source structures do not describe
> whether the SDEI event is shared or private, as this information is
> discoverable via the API.
>
> GHES needs to know whether an event is normal or critical to avoid
> sharing locks or fixmap entries.
>
> Add a helper to ask firmware for this information so it can initialise
> the struct ghes and register then enable the event.
>
> Signed-off-by: James Morse <james.morse@arm.com>
> ---
> arch/arm64/include/asm/fixmap.h | 4 +++
> drivers/firmware/arm_sdei.c | 75 +++++++++++++++++++++++++++++++++++++++++
> include/linux/arm_sdei.h | 5 +++
> 3 files changed, 84 insertions(+)
>
> diff --git a/arch/arm64/include/asm/fixmap.h b/arch/arm64/include/asm/fixmap.h
> index c3974517c2cb..e2b423a5feaf 100644
> --- a/arch/arm64/include/asm/fixmap.h
> +++ b/arch/arm64/include/asm/fixmap.h
> @@ -58,6 +58,10 @@ enum fixed_addresses {
> #ifdef CONFIG_ACPI_APEI_SEA
> FIX_APEI_GHES_SEA,
> #endif
> +#ifdef CONFIG_ARM_SDE_INTERFACE
> + FIX_APEI_GHES_SDEI_NORMAL,
> + FIX_APEI_GHES_SDEI_CRITICAL,
> +#endif
> #endif /* CONFIG_ACPI_APEI_GHES */
>
> #ifdef CONFIG_UNMAP_KERNEL_AT_EL0
> diff --git a/drivers/firmware/arm_sdei.c b/drivers/firmware/arm_sdei.c
> index 1ea71640fdc2..9b6e140cf6cb 100644
> --- a/drivers/firmware/arm_sdei.c
> +++ b/drivers/firmware/arm_sdei.c
> @@ -2,6 +2,7 @@
> // Copyright (C) 2017 Arm Ltd.
> #define pr_fmt(fmt) "sdei: " fmt
>
> +#include <acpi/ghes.h>
> #include <linux/acpi.h>
> #include <linux/arm_sdei.h>
> #include <linux/arm-smccc.h>
> @@ -887,6 +888,80 @@ static void sdei_smccc_hvc(unsigned long function_id,
> arm_smccc_hvc(function_id, arg0, arg1, arg2, arg3, arg4, 0, 0, res);
> }
>
> +#ifdef CONFIG_ACPI
> +/* These stop private notifications using the fixmap entries simultaneously */
> +static DEFINE_RAW_SPINLOCK(sdei_ghes_fixmap_lock_normal);
> +static DEFINE_RAW_SPINLOCK(sdei_ghes_fixmap_lock_critical);
> +
> +int sdei_register_ghes(struct ghes *ghes, sdei_event_callback *cb)
> +{
> + int err;
> + u32 event_num;
> + u64 result;
> +
> + if (acpi_disabled)
> + return -EOPNOTSUPP;
> +
> + event_num = ghes->generic->notify.vector;
> + if (event_num == 0) {
> + /*
> + * Event 0 is the reserved by the specification for
^
Typo.
Thanks,
Punit
> + * SDEI_EVENT_SIGNAL.
> + */
> + return -EINVAL;
> + }
> +
> + err = sdei_api_event_get_info(event_num, SDEI_EVENT_INFO_EV_PRIORITY,
> + &result);
> + if (err)
> + return err;
> +
> + if (result == SDEI_EVENT_PRIORITY_CRITICAL) {
> + ghes->nmi_fixmap_lock = &sdei_ghes_fixmap_lock_critical;
> + ghes->fixmap_idx = FIX_APEI_GHES_SDEI_CRITICAL;
> + } else {
> + ghes->nmi_fixmap_lock = &sdei_ghes_fixmap_lock_normal;
> + ghes->fixmap_idx = FIX_APEI_GHES_SDEI_NORMAL;
> + }
> +
> + err = sdei_event_register(event_num, cb, ghes);
> + if (!err)
> + err = sdei_event_enable(event_num);
> +
> + return err;
> +}
> +
[...]
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 00/11] APEI in_nmi() rework and arm64 SDEI wire-up
2018-02-15 18:55 ` James Morse
(?)
@ 2018-02-20 18:42 ` Punit Agrawal
-1 siblings, 0 replies; 94+ messages in thread
From: Punit Agrawal @ 2018-02-20 18:42 UTC (permalink / raw)
To: James Morse
Cc: Rafael Wysocki, Tony Luck, Xie XiuQi, linux-mm, Marc Zyngier,
Catalin Marinas, Tyler Baicar, Will Deacon, Dongjiu Geng,
linux-acpi, Borislav Petkov, linux-arm-kernel, Naoya Horiguchi,
kvmarm, Christoffer Dall, Len Brown
James Morse <james.morse@arm.com> writes:
> Hello!
Hi
>
> The aim of this series is to wire arm64's SDEI into APEI.
>
[...]
>
> Trees... The changes outside APEI are tiny, but there will be some changes
> to how arch/arm64/mm/fault.c generates signals, affecting do_sea() that will
> cause conflicts with patch 5.
All but the last patch applied cleanly on v4.16-rc2 for me.
Other than the comments I've already sent the patches look good to me.
FWIW,
Reviewed-by: Punit Agrawal <punit.agrawal@arm.com>
Thanks,
Punit
>
>
> Thanks,
>
> James
>
> [0] http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf
>
> James Morse (11):
> ACPI / APEI: Move the estatus queue code up, and under its own ifdef
> ACPI / APEI: Generalise the estatus queue's add/remove and notify code
> ACPI / APEI: Switch NOTIFY_SEA to use the estatus queue
> KVM: arm/arm64: Add kvm_ras.h to collect kvm specific RAS plumbing
> arm64: KVM/mm: Move SEA handling behind a single 'claim' interface
> ACPI / APEI: Make the fixmap_idx per-ghes to allow multiple in_nmi()
> users
> ACPI / APEI: Split fixmap pages for arm64 NMI-like notifications
> firmware: arm_sdei: Add ACPI GHES registration helper
> ACPI / APEI: Add support for the SDEI GHES Notification type
> mm/memory-failure: increase queued recovery work's priority
> arm64: acpi: Make apei_claim_sea() synchronise with APEI's irq work
>
> arch/arm/include/asm/kvm_ras.h | 14 +
> arch/arm/include/asm/system_misc.h | 5 -
> arch/arm64/include/asm/acpi.h | 3 +
> arch/arm64/include/asm/daifflags.h | 1 +
> arch/arm64/include/asm/fixmap.h | 8 +-
> arch/arm64/include/asm/kvm_ras.h | 29 ++
> arch/arm64/include/asm/system_misc.h | 2 -
> arch/arm64/kernel/acpi.c | 49 ++++
> arch/arm64/mm/fault.c | 30 +-
> drivers/acpi/apei/ghes.c | 533 ++++++++++++++++++++---------------
> drivers/firmware/arm_sdei.c | 75 +++++
> include/acpi/ghes.h | 5 +
> include/linux/arm_sdei.h | 8 +
> mm/memory-failure.c | 11 +-
> virt/kvm/arm/mmu.c | 4 +-
> 15 files changed, 517 insertions(+), 260 deletions(-)
> create mode 100644 arch/arm/include/asm/kvm_ras.h
> create mode 100644 arch/arm64/include/asm/kvm_ras.h
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 00/11] APEI in_nmi() rework and arm64 SDEI wire-up
@ 2018-02-20 18:42 ` Punit Agrawal
0 siblings, 0 replies; 94+ messages in thread
From: Punit Agrawal @ 2018-02-20 18:42 UTC (permalink / raw)
To: James Morse
Cc: linux-acpi, kvmarm, linux-arm-kernel, linux-mm, Borislav Petkov,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
Naoya Horiguchi, Rafael Wysocki, Len Brown, Tony Luck,
Tyler Baicar, Dongjiu Geng, Xie XiuQi
James Morse <james.morse@arm.com> writes:
> Hello!
Hi
>
> The aim of this series is to wire arm64's SDEI into APEI.
>
[...]
>
> Trees... The changes outside APEI are tiny, but there will be some changes
> to how arch/arm64/mm/fault.c generates signals, affecting do_sea() that will
> cause conflicts with patch 5.
All but the last patch applied cleanly on v4.16-rc2 for me.
Other than the comments I've already sent the patches look good to me.
FWIW,
Reviewed-by: Punit Agrawal <punit.agrawal@arm.com>
Thanks,
Punit
>
>
> Thanks,
>
> James
>
> [0] http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf
>
> James Morse (11):
> ACPI / APEI: Move the estatus queue code up, and under its own ifdef
> ACPI / APEI: Generalise the estatus queue's add/remove and notify code
> ACPI / APEI: Switch NOTIFY_SEA to use the estatus queue
> KVM: arm/arm64: Add kvm_ras.h to collect kvm specific RAS plumbing
> arm64: KVM/mm: Move SEA handling behind a single 'claim' interface
> ACPI / APEI: Make the fixmap_idx per-ghes to allow multiple in_nmi()
> users
> ACPI / APEI: Split fixmap pages for arm64 NMI-like notifications
> firmware: arm_sdei: Add ACPI GHES registration helper
> ACPI / APEI: Add support for the SDEI GHES Notification type
> mm/memory-failure: increase queued recovery work's priority
> arm64: acpi: Make apei_claim_sea() synchronise with APEI's irq work
>
> arch/arm/include/asm/kvm_ras.h | 14 +
> arch/arm/include/asm/system_misc.h | 5 -
> arch/arm64/include/asm/acpi.h | 3 +
> arch/arm64/include/asm/daifflags.h | 1 +
> arch/arm64/include/asm/fixmap.h | 8 +-
> arch/arm64/include/asm/kvm_ras.h | 29 ++
> arch/arm64/include/asm/system_misc.h | 2 -
> arch/arm64/kernel/acpi.c | 49 ++++
> arch/arm64/mm/fault.c | 30 +-
> drivers/acpi/apei/ghes.c | 533 ++++++++++++++++++++---------------
> drivers/firmware/arm_sdei.c | 75 +++++
> include/acpi/ghes.h | 5 +
> include/linux/arm_sdei.h | 8 +
> mm/memory-failure.c | 11 +-
> virt/kvm/arm/mmu.c | 4 +-
> 15 files changed, 517 insertions(+), 260 deletions(-)
> create mode 100644 arch/arm/include/asm/kvm_ras.h
> create mode 100644 arch/arm64/include/asm/kvm_ras.h
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH 00/11] APEI in_nmi() rework and arm64 SDEI wire-up
@ 2018-02-20 18:42 ` Punit Agrawal
0 siblings, 0 replies; 94+ messages in thread
From: Punit Agrawal @ 2018-02-20 18:42 UTC (permalink / raw)
To: linux-arm-kernel
James Morse <james.morse@arm.com> writes:
> Hello!
Hi
>
> The aim of this series is to wire arm64's SDEI into APEI.
>
[...]
>
> Trees... The changes outside APEI are tiny, but there will be some changes
> to how arch/arm64/mm/fault.c generates signals, affecting do_sea() that will
> cause conflicts with patch 5.
All but the last patch applied cleanly on v4.16-rc2 for me.
Other than the comments I've already sent the patches look good to me.
FWIW,
Reviewed-by: Punit Agrawal <punit.agrawal@arm.com>
Thanks,
Punit
>
>
> Thanks,
>
> James
>
> [0] http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf
>
> James Morse (11):
> ACPI / APEI: Move the estatus queue code up, and under its own ifdef
> ACPI / APEI: Generalise the estatus queue's add/remove and notify code
> ACPI / APEI: Switch NOTIFY_SEA to use the estatus queue
> KVM: arm/arm64: Add kvm_ras.h to collect kvm specific RAS plumbing
> arm64: KVM/mm: Move SEA handling behind a single 'claim' interface
> ACPI / APEI: Make the fixmap_idx per-ghes to allow multiple in_nmi()
> users
> ACPI / APEI: Split fixmap pages for arm64 NMI-like notifications
> firmware: arm_sdei: Add ACPI GHES registration helper
> ACPI / APEI: Add support for the SDEI GHES Notification type
> mm/memory-failure: increase queued recovery work's priority
> arm64: acpi: Make apei_claim_sea() synchronise with APEI's irq work
>
> arch/arm/include/asm/kvm_ras.h | 14 +
> arch/arm/include/asm/system_misc.h | 5 -
> arch/arm64/include/asm/acpi.h | 3 +
> arch/arm64/include/asm/daifflags.h | 1 +
> arch/arm64/include/asm/fixmap.h | 8 +-
> arch/arm64/include/asm/kvm_ras.h | 29 ++
> arch/arm64/include/asm/system_misc.h | 2 -
> arch/arm64/kernel/acpi.c | 49 ++++
> arch/arm64/mm/fault.c | 30 +-
> drivers/acpi/apei/ghes.c | 533 ++++++++++++++++++++---------------
> drivers/firmware/arm_sdei.c | 75 +++++
> include/acpi/ghes.h | 5 +
> include/linux/arm_sdei.h | 8 +
> mm/memory-failure.c | 11 +-
> virt/kvm/arm/mmu.c | 4 +-
> 15 files changed, 517 insertions(+), 260 deletions(-)
> create mode 100644 arch/arm/include/asm/kvm_ras.h
> create mode 100644 arch/arm64/include/asm/kvm_ras.h
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 01/11] ACPI / APEI: Move the estatus queue code up, and under its own ifdef
2018-02-15 18:55 ` James Morse
(?)
@ 2018-02-20 19:28 ` Borislav Petkov
-1 siblings, 0 replies; 94+ messages in thread
From: Borislav Petkov @ 2018-02-20 19:28 UTC (permalink / raw)
To: James Morse
Cc: Rafael Wysocki, Tony Luck, Xie XiuQi, linux-mm, Marc Zyngier,
Catalin Marinas, Tyler Baicar, Will Deacon, Dongjiu Geng,
linux-acpi, Punit Agrawal, linux-arm-kernel, Naoya Horiguchi,
kvmarm, Christoffer Dall, Len Brown
On Thu, Feb 15, 2018 at 06:55:56PM +0000, James Morse wrote:
> +#ifdef CONFIG_HAVE_ACPI_APEI_NMI
> +/*
> + * While printk() now has an in_nmi() path, the handling for CPER records
> + * does not. For example, memory_failure_queue() takes spinlocks and calls
> + * schedule_work_on().
> + *
> + * So in any NMI-like handler, we allocate required memory from lock-less
> + * memory allocator (ghes_estatus_pool), save estatus into it, put them into
> + * lock-less list (ghes_estatus_llist), then delay printk into IRQ context via
> + * irq_work (ghes_proc_irq_work). ghes_estatus_size_request record
> + * required pool size by all NMI error source.
Since you're touching this, pls correct the grammar too, while at it,
and correct them into proper sentences. Also, end function names with
"()". Also the "we" pronoun and tense sounds funny - let's make it
passive.
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 01/11] ACPI / APEI: Move the estatus queue code up, and under its own ifdef
@ 2018-02-20 19:28 ` Borislav Petkov
0 siblings, 0 replies; 94+ messages in thread
From: Borislav Petkov @ 2018-02-20 19:28 UTC (permalink / raw)
To: James Morse
Cc: linux-acpi, kvmarm, linux-arm-kernel, linux-mm, Christoffer Dall,
Marc Zyngier, Catalin Marinas, Will Deacon, Naoya Horiguchi,
Rafael Wysocki, Len Brown, Tony Luck, Tyler Baicar, Dongjiu Geng,
Xie XiuQi, Punit Agrawal
On Thu, Feb 15, 2018 at 06:55:56PM +0000, James Morse wrote:
> +#ifdef CONFIG_HAVE_ACPI_APEI_NMI
> +/*
> + * While printk() now has an in_nmi() path, the handling for CPER records
> + * does not. For example, memory_failure_queue() takes spinlocks and calls
> + * schedule_work_on().
> + *
> + * So in any NMI-like handler, we allocate required memory from lock-less
> + * memory allocator (ghes_estatus_pool), save estatus into it, put them into
> + * lock-less list (ghes_estatus_llist), then delay printk into IRQ context via
> + * irq_work (ghes_proc_irq_work). ghes_estatus_size_request record
> + * required pool size by all NMI error source.
Since you're touching this, pls correct the grammar too, while at it,
and correct them into proper sentences. Also, end function names with
"()". Also the "we" pronoun and tense sounds funny - let's make it
passive.
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH 01/11] ACPI / APEI: Move the estatus queue code up, and under its own ifdef
@ 2018-02-20 19:28 ` Borislav Petkov
0 siblings, 0 replies; 94+ messages in thread
From: Borislav Petkov @ 2018-02-20 19:28 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Feb 15, 2018 at 06:55:56PM +0000, James Morse wrote:
> +#ifdef CONFIG_HAVE_ACPI_APEI_NMI
> +/*
> + * While printk() now has an in_nmi() path, the handling for CPER records
> + * does not. For example, memory_failure_queue() takes spinlocks and calls
> + * schedule_work_on().
> + *
> + * So in any NMI-like handler, we allocate required memory from lock-less
> + * memory allocator (ghes_estatus_pool), save estatus into it, put them into
> + * lock-less list (ghes_estatus_llist), then delay printk into IRQ context via
> + * irq_work (ghes_proc_irq_work). ghes_estatus_size_request record
> + * required pool size by all NMI error source.
Since you're touching this, pls correct the grammar too, while at it,
and correct them into proper sentences. Also, end function names with
"()". Also the "we" pronoun and tense sounds funny - let's make it
passive.
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 06/11] ACPI / APEI: Make the fixmap_idx per-ghes to allow multiple in_nmi() users
2018-02-15 18:56 ` James Morse
(?)
@ 2018-02-20 21:18 ` Tyler Baicar
-1 siblings, 0 replies; 94+ messages in thread
From: Tyler Baicar @ 2018-02-20 21:18 UTC (permalink / raw)
To: James Morse
Cc: Rafael Wysocki, Tony Luck, Punit Agrawal, linux-mm, Marc Zyngier,
Catalin Marinas, Xie XiuQi, Will Deacon, Dongjiu Geng,
linux-acpi, Borislav Petkov, linux-arm-kernel, Naoya Horiguchi,
kvmarm, Christoffer Dall, Len Brown
Hey James,
On 2/15/2018 1:56 PM, James Morse wrote:
> Arm64 has multiple NMI-like notifications, but GHES only has one
> in_nmi() path. The interactions between these multiple NMI-like
> notifications is, unclear.
>
> Split this single path up by moving the fixmap idx and lock into
> the struct ghes. Each notification's init function can consider
> which other notifications it masks and can share a fixmap_idx with.
> This lets us merge the two ghes_ioremap_pfn_* flavours.
>
> Two lock pointers are provided, but only one will be used by
> ghes_copy_tofrom_phys(), depending on in_nmi(). This means any
> notification that might arrive as an NMI must always be wrapped in
> nmi_enter()/nmi_exit().
>
> The double-underscore version of fix_to_virt() is used because
> the index to be mapped can't be tested against the end of the
> enum at compile time.
>
> Signed-off-by: James Morse <james.morse@arm.com>
> ---
> @@ -303,13 +278,11 @@ static void ghes_copy_tofrom_phys(void *buffer, u64 paddr, u32 len,
>
> while (len > 0) {
> offset = paddr - (paddr & PAGE_MASK);
> - if (in_nmi) {
> - raw_spin_lock(&ghes_ioremap_lock_nmi);
> - vaddr = ghes_ioremap_pfn_nmi(paddr >> PAGE_SHIFT);
> - } else {
> - spin_lock_irqsave(&ghes_ioremap_lock_irq, flags);
> - vaddr = ghes_ioremap_pfn_irq(paddr >> PAGE_SHIFT);
> - }
> + if (in_nmi)
> + raw_spin_lock(ghes->nmi_fixmap_lock);
> + else
> + spin_lock_irqsave(ghes->fixmap_lock, flags);
This locking is resulting in a NULL pointer dereference for me during boot time.
I removed the ghes_proc() call
from ghes_probe() and then when triggering errors and going through ghes_proc()
the NULL pointer dereference
no longer happens. That makes me think that this is dependent on something that
is not setup before
ghes_probe() is happening. Any ideas?
[ 10.747323] Unable to handle kernel NULL pointer dereference at virtual
address 00000000
[ 10.755121] Mem abort info:
[ 10.757898] ESR = 0x96000005
[ 10.760937] Exception class = DABT (current EL), IL = 32 bits
[ 10.766839] SET = 0, FnV = 0
[ 10.769877] EA = 0, S1PTW = 0
[ 10.773002] Data abort info:
[ 10.775867] ISV = 0, ISS = 0x00000005
[ 10.779686] CM = 0, WnR = 0
[ 10.782638] [0000000000000000] user address but active_mm is swapper
[ 10.788976] Internal error: Oops: 96000005 [#1] SMP
[ 10.793839] CPU: 8 PID: 1 Comm: swapper/0 Not tainted 4.16.0-rc2 #37
[ 10.800173] Hardware name: Qualcomm Qualcomm Centriq(TM) 2400 Development
Platform
[ 10.813975] pstate: 60400085 (nZCv daIf +PAN -UAO)
[ 10.818756] pc : _raw_spin_lock_irqsave+0x24/0x60
[ 10.823441] lr : ghes_copy_tofrom_phys+0x170/0x178
[ 10.828211] sp : ffff8017c6b03aa0
[ 10.831509] x29: ffff8017c6b03aa0 x28: 0000000000010000
[ 10.836804] x27: ffff000009a14cb8 x26: 0000000000000001
[ 10.842099] x25: 0000000000000000 x24: 0000000000001000
[ 10.847395] x23: ffff8017cab91000 x22: ffff80178be70c80
[ 10.852690] x21: 0000000000811000 x20: 0000000000000014
[ 10.857985] x19: 0000000000000000 x18: ffffffffffffffff
[ 10.863280] x17: 0000000000000005 x16: 0000000000000000
[ 10.868575] x15: ffff000009a85b08 x14: ffff8017cab8f91c
[ 10.873870] x13: ffff8017cab8f18a x12: 0000000000000030
[ 10.879165] x11: 0101010101010101 x10: ffff8017effb19d8
[ 10.884461] x9 : 0000000000000000 x8 : ffff80178be33800
[ 10.889756] x7 : 0000000000000040 x6 : 0000000000000040
[ 10.895051] x5 : 0000000000810008 x4 : 0000000000000001
[ 10.900346] x3 : 0000000000000014 x2 : 0000000000811000
[ 10.905641] x1 : ffff8017cab91000 x0 : 0000000000000000
[ 10.910937] Process swapper/0 (pid: 1, stack limit = 0x00000000ab1500d0)
[ 10.917621] Call trace:
[ 10.920052] _raw_spin_lock_irqsave+0x24/0x60
[ 10.924392] ghes_copy_tofrom_phys+0x170/0x178
[ 10.928819] ghes_read_estatus+0xa4/0x188
[ 10.932813] ghes_proc+0x3c/0x190
[ 10.936111] ghes_probe+0x294/0x4c8
[ 10.939585] platform_drv_probe+0x60/0xc8
[ 10.943576] driver_probe_device+0x22c/0x310
[ 10.947829] __driver_attach+0xbc/0xc0
[ 10.951564] bus_for_each_dev+0x78/0xe0
[ 10.955381] driver_attach+0x30/0x40
[ 10.958941] bus_add_driver+0x110/0x228
[ 10.962760] driver_register+0x68/0x100
[ 10.966579] __platform_driver_register+0x54/0x60
[ 10.971269] ghes_init+0xbc/0x158
[ 10.974566] do_one_initcall+0xa8/0x14c
[ 10.978385] kernel_init_freeable+0x190/0x230
[ 10.982725] kernel_init+0x18/0x110
[ 10.986199] ret_from_fork+0x10/0x1c
[ 10.989757] Code: d503201f d53b4220 d50342df f9800271 (885ffe61)
[ 10.995856] ---[ end trace 6546810a8d401c9a ]---
[ 11.000463] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b
Thanks,
Tyler
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 06/11] ACPI / APEI: Make the fixmap_idx per-ghes to allow multiple in_nmi() users
@ 2018-02-20 21:18 ` Tyler Baicar
0 siblings, 0 replies; 94+ messages in thread
From: Tyler Baicar @ 2018-02-20 21:18 UTC (permalink / raw)
To: James Morse
Cc: linux-acpi, kvmarm, linux-arm-kernel, linux-mm, Borislav Petkov,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
Naoya Horiguchi, Rafael Wysocki, Len Brown, Tony Luck,
Dongjiu Geng, Xie XiuQi, Punit Agrawal
Hey James,
On 2/15/2018 1:56 PM, James Morse wrote:
> Arm64 has multiple NMI-like notifications, but GHES only has one
> in_nmi() path. The interactions between these multiple NMI-like
> notifications is, unclear.
>
> Split this single path up by moving the fixmap idx and lock into
> the struct ghes. Each notification's init function can consider
> which other notifications it masks and can share a fixmap_idx with.
> This lets us merge the two ghes_ioremap_pfn_* flavours.
>
> Two lock pointers are provided, but only one will be used by
> ghes_copy_tofrom_phys(), depending on in_nmi(). This means any
> notification that might arrive as an NMI must always be wrapped in
> nmi_enter()/nmi_exit().
>
> The double-underscore version of fix_to_virt() is used because
> the index to be mapped can't be tested against the end of the
> enum at compile time.
>
> Signed-off-by: James Morse <james.morse@arm.com>
> ---
> @@ -303,13 +278,11 @@ static void ghes_copy_tofrom_phys(void *buffer, u64 paddr, u32 len,
>
> while (len > 0) {
> offset = paddr - (paddr & PAGE_MASK);
> - if (in_nmi) {
> - raw_spin_lock(&ghes_ioremap_lock_nmi);
> - vaddr = ghes_ioremap_pfn_nmi(paddr >> PAGE_SHIFT);
> - } else {
> - spin_lock_irqsave(&ghes_ioremap_lock_irq, flags);
> - vaddr = ghes_ioremap_pfn_irq(paddr >> PAGE_SHIFT);
> - }
> + if (in_nmi)
> + raw_spin_lock(ghes->nmi_fixmap_lock);
> + else
> + spin_lock_irqsave(ghes->fixmap_lock, flags);
This locking is resulting in a NULL pointer dereference for me during boot time.
I removed the ghes_proc() call
from ghes_probe() and then when triggering errors and going through ghes_proc()
the NULL pointer dereference
no longer happens. That makes me think that this is dependent on something that
is not setup before
ghes_probe() is happening. Any ideas?
[A A 10.747323] Unable to handle kernel NULL pointer dereference at virtual
address 00000000
[A A 10.755121] Mem abort info:
[A A 10.757898]A A ESR = 0x96000005
[A A 10.760937]A A Exception class = DABT (current EL), IL = 32 bits
[A A 10.766839]A A SET = 0, FnV = 0
[A A 10.769877]A A EA = 0, S1PTW = 0
[A A 10.773002] Data abort info:
[A A 10.775867]A A ISV = 0, ISS = 0x00000005
[A A 10.779686]A A CM = 0, WnR = 0
[A A 10.782638] [0000000000000000] user address but active_mm is swapper
[A A 10.788976] Internal error: Oops: 96000005 [#1] SMP
[A A 10.793839] CPU: 8 PID: 1 Comm: swapper/0 Not tainted 4.16.0-rc2 #37
[A A 10.800173] Hardware name: Qualcomm Qualcomm Centriq(TM) 2400 Development
Platform
[A A 10.813975] pstate: 60400085 (nZCv daIf +PAN -UAO)
[A A 10.818756] pc : _raw_spin_lock_irqsave+0x24/0x60
[A A 10.823441] lr : ghes_copy_tofrom_phys+0x170/0x178
[A A 10.828211] sp : ffff8017c6b03aa0
[A A 10.831509] x29: ffff8017c6b03aa0 x28: 0000000000010000
[A A 10.836804] x27: ffff000009a14cb8 x26: 0000000000000001
[A A 10.842099] x25: 0000000000000000 x24: 0000000000001000
[A A 10.847395] x23: ffff8017cab91000 x22: ffff80178be70c80
[A A 10.852690] x21: 0000000000811000 x20: 0000000000000014
[A A 10.857985] x19: 0000000000000000 x18: ffffffffffffffff
[A A 10.863280] x17: 0000000000000005 x16: 0000000000000000
[A A 10.868575] x15: ffff000009a85b08 x14: ffff8017cab8f91c
[A A 10.873870] x13: ffff8017cab8f18a x12: 0000000000000030
[A A 10.879165] x11: 0101010101010101 x10: ffff8017effb19d8
[A A 10.884461] x9 : 0000000000000000 x8 : ffff80178be33800
[A A 10.889756] x7 : 0000000000000040 x6 : 0000000000000040
[A A 10.895051] x5 : 0000000000810008 x4 : 0000000000000001
[A A 10.900346] x3 : 0000000000000014 x2 : 0000000000811000
[A A 10.905641] x1 : ffff8017cab91000 x0 : 0000000000000000
[A A 10.910937] Process swapper/0 (pid: 1, stack limit = 0x00000000ab1500d0)
[A A 10.917621] Call trace:
[A A 10.920052]A _raw_spin_lock_irqsave+0x24/0x60
[A A 10.924392]A ghes_copy_tofrom_phys+0x170/0x178
[A A 10.928819]A ghes_read_estatus+0xa4/0x188
[A A 10.932813]A ghes_proc+0x3c/0x190
[A A 10.936111]A ghes_probe+0x294/0x4c8
[A A 10.939585]A platform_drv_probe+0x60/0xc8
[A A 10.943576]A driver_probe_device+0x22c/0x310
[A A 10.947829]A __driver_attach+0xbc/0xc0
[A A 10.951564]A bus_for_each_dev+0x78/0xe0
[A A 10.955381]A driver_attach+0x30/0x40
[A A 10.958941]A bus_add_driver+0x110/0x228
[A A 10.962760]A driver_register+0x68/0x100
[A A 10.966579]A __platform_driver_register+0x54/0x60
[A A 10.971269]A ghes_init+0xbc/0x158
[A A 10.974566]A do_one_initcall+0xa8/0x14c
[A A 10.978385]A kernel_init_freeable+0x190/0x230
[A A 10.982725]A kernel_init+0x18/0x110
[A A 10.986199]A ret_from_fork+0x10/0x1c
[A A 10.989757] Code: d503201f d53b4220 d50342df f9800271 (885ffe61)
[A A 10.995856] ---[ end trace 6546810a8d401c9a ]---
[A A 11.000463] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b
Thanks,
Tyler
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH 06/11] ACPI / APEI: Make the fixmap_idx per-ghes to allow multiple in_nmi() users
@ 2018-02-20 21:18 ` Tyler Baicar
0 siblings, 0 replies; 94+ messages in thread
From: Tyler Baicar @ 2018-02-20 21:18 UTC (permalink / raw)
To: linux-arm-kernel
Hey James,
On 2/15/2018 1:56 PM, James Morse wrote:
> Arm64 has multiple NMI-like notifications, but GHES only has one
> in_nmi() path. The interactions between these multiple NMI-like
> notifications is, unclear.
>
> Split this single path up by moving the fixmap idx and lock into
> the struct ghes. Each notification's init function can consider
> which other notifications it masks and can share a fixmap_idx with.
> This lets us merge the two ghes_ioremap_pfn_* flavours.
>
> Two lock pointers are provided, but only one will be used by
> ghes_copy_tofrom_phys(), depending on in_nmi(). This means any
> notification that might arrive as an NMI must always be wrapped in
> nmi_enter()/nmi_exit().
>
> The double-underscore version of fix_to_virt() is used because
> the index to be mapped can't be tested against the end of the
> enum at compile time.
>
> Signed-off-by: James Morse <james.morse@arm.com>
> ---
> @@ -303,13 +278,11 @@ static void ghes_copy_tofrom_phys(void *buffer, u64 paddr, u32 len,
>
> while (len > 0) {
> offset = paddr - (paddr & PAGE_MASK);
> - if (in_nmi) {
> - raw_spin_lock(&ghes_ioremap_lock_nmi);
> - vaddr = ghes_ioremap_pfn_nmi(paddr >> PAGE_SHIFT);
> - } else {
> - spin_lock_irqsave(&ghes_ioremap_lock_irq, flags);
> - vaddr = ghes_ioremap_pfn_irq(paddr >> PAGE_SHIFT);
> - }
> + if (in_nmi)
> + raw_spin_lock(ghes->nmi_fixmap_lock);
> + else
> + spin_lock_irqsave(ghes->fixmap_lock, flags);
This locking is resulting in a NULL pointer dereference for me during boot time.
I removed the ghes_proc() call
from ghes_probe() and then when triggering errors and going through ghes_proc()
the NULL pointer dereference
no longer happens. That makes me think that this is dependent on something that
is not setup before
ghes_probe() is happening. Any ideas?
[?? 10.747323] Unable to handle kernel NULL pointer dereference at virtual
address 00000000
[?? 10.755121] Mem abort info:
[?? 10.757898]?? ESR = 0x96000005
[?? 10.760937]?? Exception class = DABT (current EL), IL = 32 bits
[?? 10.766839]?? SET = 0, FnV = 0
[?? 10.769877]?? EA = 0, S1PTW = 0
[?? 10.773002] Data abort info:
[?? 10.775867]?? ISV = 0, ISS = 0x00000005
[?? 10.779686]?? CM = 0, WnR = 0
[?? 10.782638] [0000000000000000] user address but active_mm is swapper
[?? 10.788976] Internal error: Oops: 96000005 [#1] SMP
[?? 10.793839] CPU: 8 PID: 1 Comm: swapper/0 Not tainted 4.16.0-rc2 #37
[?? 10.800173] Hardware name: Qualcomm Qualcomm Centriq(TM) 2400 Development
Platform
[?? 10.813975] pstate: 60400085 (nZCv daIf +PAN -UAO)
[?? 10.818756] pc : _raw_spin_lock_irqsave+0x24/0x60
[?? 10.823441] lr : ghes_copy_tofrom_phys+0x170/0x178
[?? 10.828211] sp : ffff8017c6b03aa0
[?? 10.831509] x29: ffff8017c6b03aa0 x28: 0000000000010000
[?? 10.836804] x27: ffff000009a14cb8 x26: 0000000000000001
[?? 10.842099] x25: 0000000000000000 x24: 0000000000001000
[?? 10.847395] x23: ffff8017cab91000 x22: ffff80178be70c80
[?? 10.852690] x21: 0000000000811000 x20: 0000000000000014
[?? 10.857985] x19: 0000000000000000 x18: ffffffffffffffff
[?? 10.863280] x17: 0000000000000005 x16: 0000000000000000
[?? 10.868575] x15: ffff000009a85b08 x14: ffff8017cab8f91c
[?? 10.873870] x13: ffff8017cab8f18a x12: 0000000000000030
[?? 10.879165] x11: 0101010101010101 x10: ffff8017effb19d8
[?? 10.884461] x9 : 0000000000000000 x8 : ffff80178be33800
[?? 10.889756] x7 : 0000000000000040 x6 : 0000000000000040
[?? 10.895051] x5 : 0000000000810008 x4 : 0000000000000001
[?? 10.900346] x3 : 0000000000000014 x2 : 0000000000811000
[?? 10.905641] x1 : ffff8017cab91000 x0 : 0000000000000000
[?? 10.910937] Process swapper/0 (pid: 1, stack limit = 0x00000000ab1500d0)
[?? 10.917621] Call trace:
[?? 10.920052]? _raw_spin_lock_irqsave+0x24/0x60
[?? 10.924392]? ghes_copy_tofrom_phys+0x170/0x178
[?? 10.928819]? ghes_read_estatus+0xa4/0x188
[?? 10.932813]? ghes_proc+0x3c/0x190
[?? 10.936111]? ghes_probe+0x294/0x4c8
[?? 10.939585]? platform_drv_probe+0x60/0xc8
[?? 10.943576]? driver_probe_device+0x22c/0x310
[?? 10.947829]? __driver_attach+0xbc/0xc0
[?? 10.951564]? bus_for_each_dev+0x78/0xe0
[?? 10.955381]? driver_attach+0x30/0x40
[?? 10.958941]? bus_add_driver+0x110/0x228
[?? 10.962760]? driver_register+0x68/0x100
[?? 10.966579]? __platform_driver_register+0x54/0x60
[?? 10.971269]? ghes_init+0xbc/0x158
[?? 10.974566]? do_one_initcall+0xa8/0x14c
[?? 10.978385]? kernel_init_freeable+0x190/0x230
[?? 10.982725]? kernel_init+0x18/0x110
[?? 10.986199]? ret_from_fork+0x10/0x1c
[?? 10.989757] Code: d503201f d53b4220 d50342df f9800271 (885ffe61)
[?? 10.995856] ---[ end trace 6546810a8d401c9a ]---
[?? 11.000463] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b
Thanks,
Tyler
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 06/11] ACPI / APEI: Make the fixmap_idx per-ghes to allow multiple in_nmi() users
2018-02-20 21:18 ` Tyler Baicar
(?)
@ 2018-02-22 17:47 ` James Morse
-1 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-02-22 17:47 UTC (permalink / raw)
To: Tyler Baicar
Cc: Rafael Wysocki, Tony Luck, Punit Agrawal, linux-mm, Marc Zyngier,
Catalin Marinas, Xie XiuQi, Will Deacon, Dongjiu Geng,
linux-acpi, Borislav Petkov, linux-arm-kernel, Naoya Horiguchi,
kvmarm, Christoffer Dall, Len Brown
Hi Tyler
Thanks for taking a look!
On 20/02/18 21:18, Tyler Baicar wrote:
> On 2/15/2018 1:56 PM, James Morse wrote:
>> Arm64 has multiple NMI-like notifications, but GHES only has one
>> in_nmi() path. The interactions between these multiple NMI-like
>> notifications is, unclear.
>>
>> Split this single path up by moving the fixmap idx and lock into
>> the struct ghes. Each notification's init function can consider
>> which other notifications it masks and can share a fixmap_idx with.
>> This lets us merge the two ghes_ioremap_pfn_* flavours.
>>
>> Two lock pointers are provided, but only one will be used by
>> ghes_copy_tofrom_phys(), depending on in_nmi(). This means any
>> notification that might arrive as an NMI must always be wrapped in
>> nmi_enter()/nmi_exit().
>>
>> The double-underscore version of fix_to_virt() is used because
>> the index to be mapped can't be tested against the end of the
>> enum at compile time.
>> @@ -303,13 +278,11 @@ static void ghes_copy_tofrom_phys(void *buffer, u64
>> paddr, u32 len,
>> while (len > 0) {
>> offset = paddr - (paddr & PAGE_MASK);
>> - if (in_nmi) {
>> - raw_spin_lock(&ghes_ioremap_lock_nmi);
>> - vaddr = ghes_ioremap_pfn_nmi(paddr >> PAGE_SHIFT);
>> - } else {
>> - spin_lock_irqsave(&ghes_ioremap_lock_irq, flags);
>> - vaddr = ghes_ioremap_pfn_irq(paddr >> PAGE_SHIFT);
>> - }
>> + if (in_nmi)
>> + raw_spin_lock(ghes->nmi_fixmap_lock);
>> + else
>> + spin_lock_irqsave(ghes->fixmap_lock, flags);
> This locking is resulting in a NULL pointer dereference for me during boot time.
> I removed the ghes_proc() call
> from ghes_probe() and then when triggering errors and going through ghes_proc()
> the NULL pointer dereference
> no longer happens. That makes me think that this is dependent on something that
> is not setup before
> ghes_probe() is happening. Any ideas?
Gah, One of the things I've tried to enforce is that notifications that happen
in_nmi() always happen in_nmi(): but that isn't the case for this first
ghes_proc() call, which always happens in process context.
Why didn't this happen to me? I'm assuming your GHES has work to do prior to
probing, but I waited for it to finish booting before generating test events.
The smallest fix is to have an irq/nmi fixmap and lock. This probe time call
would always use the irq fixmap and lock, and can be safely interrupted by an
NMI. Its only the NMI notifications interacting that we need to worry about as
they can't be masked.
Thanks!
James
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 06/11] ACPI / APEI: Make the fixmap_idx per-ghes to allow multiple in_nmi() users
@ 2018-02-22 17:47 ` James Morse
0 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-02-22 17:47 UTC (permalink / raw)
To: Tyler Baicar
Cc: linux-acpi, kvmarm, linux-arm-kernel, linux-mm, Borislav Petkov,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
Naoya Horiguchi, Rafael Wysocki, Len Brown, Tony Luck,
Dongjiu Geng, Xie XiuQi, Punit Agrawal
Hi Tyler
Thanks for taking a look!
On 20/02/18 21:18, Tyler Baicar wrote:
> On 2/15/2018 1:56 PM, James Morse wrote:
>> Arm64 has multiple NMI-like notifications, but GHES only has one
>> in_nmi() path. The interactions between these multiple NMI-like
>> notifications is, unclear.
>>
>> Split this single path up by moving the fixmap idx and lock into
>> the struct ghes. Each notification's init function can consider
>> which other notifications it masks and can share a fixmap_idx with.
>> This lets us merge the two ghes_ioremap_pfn_* flavours.
>>
>> Two lock pointers are provided, but only one will be used by
>> ghes_copy_tofrom_phys(), depending on in_nmi(). This means any
>> notification that might arrive as an NMI must always be wrapped in
>> nmi_enter()/nmi_exit().
>>
>> The double-underscore version of fix_to_virt() is used because
>> the index to be mapped can't be tested against the end of the
>> enum at compile time.
>> @@ -303,13 +278,11 @@ static void ghes_copy_tofrom_phys(void *buffer, u64
>> paddr, u32 len,
>> while (len > 0) {
>> offset = paddr - (paddr & PAGE_MASK);
>> - if (in_nmi) {
>> - raw_spin_lock(&ghes_ioremap_lock_nmi);
>> - vaddr = ghes_ioremap_pfn_nmi(paddr >> PAGE_SHIFT);
>> - } else {
>> - spin_lock_irqsave(&ghes_ioremap_lock_irq, flags);
>> - vaddr = ghes_ioremap_pfn_irq(paddr >> PAGE_SHIFT);
>> - }
>> + if (in_nmi)
>> + raw_spin_lock(ghes->nmi_fixmap_lock);
>> + else
>> + spin_lock_irqsave(ghes->fixmap_lock, flags);
> This locking is resulting in a NULL pointer dereference for me during boot time.
> I removed the ghes_proc() call
> from ghes_probe() and then when triggering errors and going through ghes_proc()
> the NULL pointer dereference
> no longer happens. That makes me think that this is dependent on something that
> is not setup before
> ghes_probe() is happening. Any ideas?
Gah, One of the things I've tried to enforce is that notifications that happen
in_nmi() always happen in_nmi(): but that isn't the case for this first
ghes_proc() call, which always happens in process context.
Why didn't this happen to me? I'm assuming your GHES has work to do prior to
probing, but I waited for it to finish booting before generating test events.
The smallest fix is to have an irq/nmi fixmap and lock. This probe time call
would always use the irq fixmap and lock, and can be safely interrupted by an
NMI. Its only the NMI notifications interacting that we need to worry about as
they can't be masked.
Thanks!
James
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH 06/11] ACPI / APEI: Make the fixmap_idx per-ghes to allow multiple in_nmi() users
@ 2018-02-22 17:47 ` James Morse
0 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-02-22 17:47 UTC (permalink / raw)
To: linux-arm-kernel
Hi Tyler
Thanks for taking a look!
On 20/02/18 21:18, Tyler Baicar wrote:
> On 2/15/2018 1:56 PM, James Morse wrote:
>> Arm64 has multiple NMI-like notifications, but GHES only has one
>> in_nmi() path. The interactions between these multiple NMI-like
>> notifications is, unclear.
>>
>> Split this single path up by moving the fixmap idx and lock into
>> the struct ghes. Each notification's init function can consider
>> which other notifications it masks and can share a fixmap_idx with.
>> This lets us merge the two ghes_ioremap_pfn_* flavours.
>>
>> Two lock pointers are provided, but only one will be used by
>> ghes_copy_tofrom_phys(), depending on in_nmi(). This means any
>> notification that might arrive as an NMI must always be wrapped in
>> nmi_enter()/nmi_exit().
>>
>> The double-underscore version of fix_to_virt() is used because
>> the index to be mapped can't be tested against the end of the
>> enum at compile time.
>> @@ -303,13 +278,11 @@ static void ghes_copy_tofrom_phys(void *buffer, u64
>> paddr, u32 len,
>> while (len > 0) {
>> offset = paddr - (paddr & PAGE_MASK);
>> - if (in_nmi) {
>> - raw_spin_lock(&ghes_ioremap_lock_nmi);
>> - vaddr = ghes_ioremap_pfn_nmi(paddr >> PAGE_SHIFT);
>> - } else {
>> - spin_lock_irqsave(&ghes_ioremap_lock_irq, flags);
>> - vaddr = ghes_ioremap_pfn_irq(paddr >> PAGE_SHIFT);
>> - }
>> + if (in_nmi)
>> + raw_spin_lock(ghes->nmi_fixmap_lock);
>> + else
>> + spin_lock_irqsave(ghes->fixmap_lock, flags);
> This locking is resulting in a NULL pointer dereference for me during boot time.
> I removed the ghes_proc() call
> from ghes_probe() and then when triggering errors and going through ghes_proc()
> the NULL pointer dereference
> no longer happens. That makes me think that this is dependent on something that
> is not setup before
> ghes_probe() is happening. Any ideas?
Gah, One of the things I've tried to enforce is that notifications that happen
in_nmi() always happen in_nmi(): but that isn't the case for this first
ghes_proc() call, which always happens in process context.
Why didn't this happen to me? I'm assuming your GHES has work to do prior to
probing, but I waited for it to finish booting before generating test events.
The smallest fix is to have an irq/nmi fixmap and lock. This probe time call
would always use the irq fixmap and lock, and can be safely interrupted by an
NMI. Its only the NMI notifications interacting that we need to worry about as
they can't be masked.
Thanks!
James
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 01/11] ACPI / APEI: Move the estatus queue code up, and under its own ifdef
2018-02-20 19:28 ` Borislav Petkov
(?)
@ 2018-02-23 18:02 ` James Morse
-1 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-02-23 18:02 UTC (permalink / raw)
To: Borislav Petkov
Cc: Rafael Wysocki, Tony Luck, Xie XiuQi, linux-mm, Marc Zyngier,
Catalin Marinas, Tyler Baicar, Will Deacon, Dongjiu Geng,
linux-acpi, Punit Agrawal, linux-arm-kernel, Naoya Horiguchi,
kvmarm, Christoffer Dall, Len Brown
Hi Borislav,
On 20/02/18 19:28, Borislav Petkov wrote:
> On Thu, Feb 15, 2018 at 06:55:56PM +0000, James Morse wrote:
>> +#ifdef CONFIG_HAVE_ACPI_APEI_NMI
>> +/*
>> + * While printk() now has an in_nmi() path, the handling for CPER records
>> + * does not. For example, memory_failure_queue() takes spinlocks and calls
>> + * schedule_work_on().
>> + *
>> + * So in any NMI-like handler, we allocate required memory from lock-less
>> + * memory allocator (ghes_estatus_pool), save estatus into it, put them into
>> + * lock-less list (ghes_estatus_llist), then delay printk into IRQ context via
>> + * irq_work (ghes_proc_irq_work). ghes_estatus_size_request record
>> + * required pool size by all NMI error source.
>
> Since you're touching this, pls correct the grammar too, while at it,
> and correct them into proper sentences.
> Also, end function names with "()".
> Also the "we" pronoun and tense sounds funny - let's make it passive.
Sure. I reckon your English grammar is better than mine, is this better?:
| In any NMI-like handler, memory from ghes_estatus_pool is used to save
| estatus, and added to the ghes_estatus_llist. irq_work_queue() causes
| ghes_proc_in_irq() to run in IRQ context where each estatus in
| ghes_estatus_llist are processed. Each NMI-like error source must grow
| the ghes_estatus_pool to ensure memory is available.
Thanks,
James
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 01/11] ACPI / APEI: Move the estatus queue code up, and under its own ifdef
@ 2018-02-23 18:02 ` James Morse
0 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-02-23 18:02 UTC (permalink / raw)
To: Borislav Petkov
Cc: linux-acpi, kvmarm, linux-arm-kernel, linux-mm, Christoffer Dall,
Marc Zyngier, Catalin Marinas, Will Deacon, Naoya Horiguchi,
Rafael Wysocki, Len Brown, Tony Luck, Tyler Baicar, Dongjiu Geng,
Xie XiuQi, Punit Agrawal
Hi Borislav,
On 20/02/18 19:28, Borislav Petkov wrote:
> On Thu, Feb 15, 2018 at 06:55:56PM +0000, James Morse wrote:
>> +#ifdef CONFIG_HAVE_ACPI_APEI_NMI
>> +/*
>> + * While printk() now has an in_nmi() path, the handling for CPER records
>> + * does not. For example, memory_failure_queue() takes spinlocks and calls
>> + * schedule_work_on().
>> + *
>> + * So in any NMI-like handler, we allocate required memory from lock-less
>> + * memory allocator (ghes_estatus_pool), save estatus into it, put them into
>> + * lock-less list (ghes_estatus_llist), then delay printk into IRQ context via
>> + * irq_work (ghes_proc_irq_work). ghes_estatus_size_request record
>> + * required pool size by all NMI error source.
>
> Since you're touching this, pls correct the grammar too, while at it,
> and correct them into proper sentences.
> Also, end function names with "()".
> Also the "we" pronoun and tense sounds funny - let's make it passive.
Sure. I reckon your English grammar is better than mine, is this better?:
| In any NMI-like handler, memory from ghes_estatus_pool is used to save
| estatus, and added to the ghes_estatus_llist. irq_work_queue() causes
| ghes_proc_in_irq() to run in IRQ context where each estatus in
| ghes_estatus_llist are processed. Each NMI-like error source must grow
| the ghes_estatus_pool to ensure memory is available.
Thanks,
James
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH 01/11] ACPI / APEI: Move the estatus queue code up, and under its own ifdef
@ 2018-02-23 18:02 ` James Morse
0 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-02-23 18:02 UTC (permalink / raw)
To: linux-arm-kernel
Hi Borislav,
On 20/02/18 19:28, Borislav Petkov wrote:
> On Thu, Feb 15, 2018 at 06:55:56PM +0000, James Morse wrote:
>> +#ifdef CONFIG_HAVE_ACPI_APEI_NMI
>> +/*
>> + * While printk() now has an in_nmi() path, the handling for CPER records
>> + * does not. For example, memory_failure_queue() takes spinlocks and calls
>> + * schedule_work_on().
>> + *
>> + * So in any NMI-like handler, we allocate required memory from lock-less
>> + * memory allocator (ghes_estatus_pool), save estatus into it, put them into
>> + * lock-less list (ghes_estatus_llist), then delay printk into IRQ context via
>> + * irq_work (ghes_proc_irq_work). ghes_estatus_size_request record
>> + * required pool size by all NMI error source.
>
> Since you're touching this, pls correct the grammar too, while at it,
> and correct them into proper sentences.
> Also, end function names with "()".
> Also the "we" pronoun and tense sounds funny - let's make it passive.
Sure. I reckon your English grammar is better than mine, is this better?:
| In any NMI-like handler, memory from ghes_estatus_pool is used to save
| estatus, and added to the ghes_estatus_llist. irq_work_queue() causes
| ghes_proc_in_irq() to run in IRQ context where each estatus in
| ghes_estatus_llist are processed. Each NMI-like error source must grow
| the ghes_estatus_pool to ensure memory is available.
Thanks,
James
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 01/11] ACPI / APEI: Move the estatus queue code up, and under its own ifdef
2018-02-23 18:02 ` James Morse
(?)
@ 2018-02-23 18:07 ` Borislav Petkov
-1 siblings, 0 replies; 94+ messages in thread
From: Borislav Petkov @ 2018-02-23 18:07 UTC (permalink / raw)
To: James Morse
Cc: Rafael Wysocki, Tony Luck, Xie XiuQi, linux-mm, Marc Zyngier,
Catalin Marinas, Tyler Baicar, Will Deacon, Dongjiu Geng,
linux-acpi, Punit Agrawal, linux-arm-kernel, Naoya Horiguchi,
kvmarm, Christoffer Dall, Len Brown
On Fri, Feb 23, 2018 at 06:02:21PM +0000, James Morse wrote:
> Sure. I reckon your English grammar is better than mine, is this better?:
Bah, you must be joking :-)
> | In any NMI-like handler, memory from ghes_estatus_pool is used to save
> | estatus, and added to the ghes_estatus_llist. irq_work_queue() causes
> | ghes_proc_in_irq() to run in IRQ context where each estatus in
> | ghes_estatus_llist are processed. Each NMI-like error source must grow
s/are/is/ reads better to me, for some reason :)
> | the ghes_estatus_pool to ensure memory is available.
Other than that, yap, much better!
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 01/11] ACPI / APEI: Move the estatus queue code up, and under its own ifdef
@ 2018-02-23 18:07 ` Borislav Petkov
0 siblings, 0 replies; 94+ messages in thread
From: Borislav Petkov @ 2018-02-23 18:07 UTC (permalink / raw)
To: James Morse
Cc: linux-acpi, kvmarm, linux-arm-kernel, linux-mm, Christoffer Dall,
Marc Zyngier, Catalin Marinas, Will Deacon, Naoya Horiguchi,
Rafael Wysocki, Len Brown, Tony Luck, Tyler Baicar, Dongjiu Geng,
Xie XiuQi, Punit Agrawal
On Fri, Feb 23, 2018 at 06:02:21PM +0000, James Morse wrote:
> Sure. I reckon your English grammar is better than mine, is this better?:
Bah, you must be joking :-)
> | In any NMI-like handler, memory from ghes_estatus_pool is used to save
> | estatus, and added to the ghes_estatus_llist. irq_work_queue() causes
> | ghes_proc_in_irq() to run in IRQ context where each estatus in
> | ghes_estatus_llist are processed. Each NMI-like error source must grow
s/are/is/ reads better to me, for some reason :)
> | the ghes_estatus_pool to ensure memory is available.
Other than that, yap, much better!
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH 01/11] ACPI / APEI: Move the estatus queue code up, and under its own ifdef
@ 2018-02-23 18:07 ` Borislav Petkov
0 siblings, 0 replies; 94+ messages in thread
From: Borislav Petkov @ 2018-02-23 18:07 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Feb 23, 2018 at 06:02:21PM +0000, James Morse wrote:
> Sure. I reckon your English grammar is better than mine, is this better?:
Bah, you must be joking :-)
> | In any NMI-like handler, memory from ghes_estatus_pool is used to save
> | estatus, and added to the ghes_estatus_llist. irq_work_queue() causes
> | ghes_proc_in_irq() to run in IRQ context where each estatus in
> | ghes_estatus_llist are processed. Each NMI-like error source must grow
s/are/is/ reads better to me, for some reason :)
> | the ghes_estatus_pool to ensure memory is available.
Other than that, yap, much better!
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code
2018-02-20 18:26 ` Punit Agrawal
(?)
@ 2018-02-23 18:21 ` James Morse
-1 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-02-23 18:21 UTC (permalink / raw)
To: Punit Agrawal
Cc: Rafael Wysocki, Tony Luck, Xie XiuQi, linux-mm, Marc Zyngier,
Catalin Marinas, Tyler Baicar, Will Deacon, Dongjiu Geng,
linux-acpi, Borislav Petkov, linux-arm-kernel, Naoya Horiguchi,
kvmarm, Christoffer Dall, Len Brown
Hi Punit,
On 20/02/18 18:26, Punit Agrawal wrote:
> James Morse <james.morse@arm.com> writes:
>
>> To support asynchronous NMI-like notifications on arm64 we need to use
>> the estatus-queue. These patches refactor it to allow multiple APEI
>> notification types to use it.
>>
>> Refactor the estatus queue's pool grow/shrink code and notification
>> routine from NOTIFY_NMI's handlers. This will allow another notification
>> method to use the estatus queue without duplicating this code.
>>
>> This patch adds rcu_read_lock()/rcu_read_unlock() around the list
>> list_for_each_entry_rcu() walker. These aren't strictly necessary as
>> the whole nmi_enter/nmi_exit() window is a spooky RCU read-side
>> critical section.
>>
>> Keep the oops_begin() call for x86, arm64 doesn't have one of these,
>> and APEI is the only thing outside arch code calling this..
>>
>> The existing ghes_estatus_pool_shrink() is folded into the new
>> ghes_estatus_queue_shrink_pool() as only the queue uses it.
>>
>> _in_nmi_notify_one() is separate from the rcu-list walker for a later
>> caller that doesn't need to walk a list.
>> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
>> index e42b587c509b..d3cc5bd5b496 100644
>> --- a/drivers/acpi/apei/ghes.c
>> +++ b/drivers/acpi/apei/ghes.c
>> @@ -749,6 +749,54 @@ static void __process_error(struct ghes *ghes)
>> #endif
>> }
>>
>> +static int _in_nmi_notify_one(struct ghes *ghes)
>> +{
>> + int sev;
>> + int ret = -ENOENT;
>
> If ret is initialised to 0 ...
>
>> +
>> + if (ghes_read_estatus(ghes, 1)) {
>> + ghes_clear_estatus(ghes);
>> + return ret;
>
> and return -ENOENT here...
>
>> + } else {
>> + ret = 0;
>> + }
>
> ... then the else block can be dropped.
Good point, this happened because I was trying to keep the same shape as the
existing notify_nmi() code as far as possible.
>> +
>> + sev = ghes_severity(ghes->estatus->error_severity);
>> + if (sev >= GHES_SEV_PANIC) {
>> +#ifdef CONFIG_X86
>> + oops_begin();
>> +#endif
>
> Can you use IS_ENABLED() here as well?
I didn't think that would build without an empty declaration for arm64, I
assumed it would generate an implicit-declaration-of warning. But, I've tried
it, and evidently today's toolchain does dead-code elimination before generating
implicit-declaration-of warnings...
I'd prefer to leave this (ugly as it is), to avoid warnings on a different
version of the compiler.
Thanks,
James
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code
@ 2018-02-23 18:21 ` James Morse
0 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-02-23 18:21 UTC (permalink / raw)
To: Punit Agrawal
Cc: linux-acpi, kvmarm, linux-arm-kernel, linux-mm, Borislav Petkov,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
Naoya Horiguchi, Rafael Wysocki, Len Brown, Tony Luck,
Tyler Baicar, Dongjiu Geng, Xie XiuQi
Hi Punit,
On 20/02/18 18:26, Punit Agrawal wrote:
> James Morse <james.morse@arm.com> writes:
>
>> To support asynchronous NMI-like notifications on arm64 we need to use
>> the estatus-queue. These patches refactor it to allow multiple APEI
>> notification types to use it.
>>
>> Refactor the estatus queue's pool grow/shrink code and notification
>> routine from NOTIFY_NMI's handlers. This will allow another notification
>> method to use the estatus queue without duplicating this code.
>>
>> This patch adds rcu_read_lock()/rcu_read_unlock() around the list
>> list_for_each_entry_rcu() walker. These aren't strictly necessary as
>> the whole nmi_enter/nmi_exit() window is a spooky RCU read-side
>> critical section.
>>
>> Keep the oops_begin() call for x86, arm64 doesn't have one of these,
>> and APEI is the only thing outside arch code calling this..
>>
>> The existing ghes_estatus_pool_shrink() is folded into the new
>> ghes_estatus_queue_shrink_pool() as only the queue uses it.
>>
>> _in_nmi_notify_one() is separate from the rcu-list walker for a later
>> caller that doesn't need to walk a list.
>> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
>> index e42b587c509b..d3cc5bd5b496 100644
>> --- a/drivers/acpi/apei/ghes.c
>> +++ b/drivers/acpi/apei/ghes.c
>> @@ -749,6 +749,54 @@ static void __process_error(struct ghes *ghes)
>> #endif
>> }
>>
>> +static int _in_nmi_notify_one(struct ghes *ghes)
>> +{
>> + int sev;
>> + int ret = -ENOENT;
>
> If ret is initialised to 0 ...
>
>> +
>> + if (ghes_read_estatus(ghes, 1)) {
>> + ghes_clear_estatus(ghes);
>> + return ret;
>
> and return -ENOENT here...
>
>> + } else {
>> + ret = 0;
>> + }
>
> ... then the else block can be dropped.
Good point, this happened because I was trying to keep the same shape as the
existing notify_nmi() code as far as possible.
>> +
>> + sev = ghes_severity(ghes->estatus->error_severity);
>> + if (sev >= GHES_SEV_PANIC) {
>> +#ifdef CONFIG_X86
>> + oops_begin();
>> +#endif
>
> Can you use IS_ENABLED() here as well?
I didn't think that would build without an empty declaration for arm64, I
assumed it would generate an implicit-declaration-of warning. But, I've tried
it, and evidently today's toolchain does dead-code elimination before generating
implicit-declaration-of warnings...
I'd prefer to leave this (ugly as it is), to avoid warnings on a different
version of the compiler.
Thanks,
James
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code
@ 2018-02-23 18:21 ` James Morse
0 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-02-23 18:21 UTC (permalink / raw)
To: linux-arm-kernel
Hi Punit,
On 20/02/18 18:26, Punit Agrawal wrote:
> James Morse <james.morse@arm.com> writes:
>
>> To support asynchronous NMI-like notifications on arm64 we need to use
>> the estatus-queue. These patches refactor it to allow multiple APEI
>> notification types to use it.
>>
>> Refactor the estatus queue's pool grow/shrink code and notification
>> routine from NOTIFY_NMI's handlers. This will allow another notification
>> method to use the estatus queue without duplicating this code.
>>
>> This patch adds rcu_read_lock()/rcu_read_unlock() around the list
>> list_for_each_entry_rcu() walker. These aren't strictly necessary as
>> the whole nmi_enter/nmi_exit() window is a spooky RCU read-side
>> critical section.
>>
>> Keep the oops_begin() call for x86, arm64 doesn't have one of these,
>> and APEI is the only thing outside arch code calling this..
>>
>> The existing ghes_estatus_pool_shrink() is folded into the new
>> ghes_estatus_queue_shrink_pool() as only the queue uses it.
>>
>> _in_nmi_notify_one() is separate from the rcu-list walker for a later
>> caller that doesn't need to walk a list.
>> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
>> index e42b587c509b..d3cc5bd5b496 100644
>> --- a/drivers/acpi/apei/ghes.c
>> +++ b/drivers/acpi/apei/ghes.c
>> @@ -749,6 +749,54 @@ static void __process_error(struct ghes *ghes)
>> #endif
>> }
>>
>> +static int _in_nmi_notify_one(struct ghes *ghes)
>> +{
>> + int sev;
>> + int ret = -ENOENT;
>
> If ret is initialised to 0 ...
>
>> +
>> + if (ghes_read_estatus(ghes, 1)) {
>> + ghes_clear_estatus(ghes);
>> + return ret;
>
> and return -ENOENT here...
>
>> + } else {
>> + ret = 0;
>> + }
>
> ... then the else block can be dropped.
Good point, this happened because I was trying to keep the same shape as the
existing notify_nmi() code as far as possible.
>> +
>> + sev = ghes_severity(ghes->estatus->error_severity);
>> + if (sev >= GHES_SEV_PANIC) {
>> +#ifdef CONFIG_X86
>> + oops_begin();
>> +#endif
>
> Can you use IS_ENABLED() here as well?
I didn't think that would build without an empty declaration for arm64, I
assumed it would generate an implicit-declaration-of warning. But, I've tried
it, and evidently today's toolchain does dead-code elimination before generating
implicit-declaration-of warnings...
I'd prefer to leave this (ugly as it is), to avoid warnings on a different
version of the compiler.
Thanks,
James
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code
2018-02-15 18:55 ` James Morse
(?)
@ 2018-03-01 15:01 ` Borislav Petkov
-1 siblings, 0 replies; 94+ messages in thread
From: Borislav Petkov @ 2018-03-01 15:01 UTC (permalink / raw)
To: James Morse
Cc: Rafael Wysocki, Tony Luck, Xie XiuQi, linux-mm, Marc Zyngier,
Catalin Marinas, Tyler Baicar, Will Deacon, Dongjiu Geng,
linux-acpi, Punit Agrawal, linux-arm-kernel, Naoya Horiguchi,
kvmarm, Christoffer Dall, Len Brown
On Thu, Feb 15, 2018 at 06:55:57PM +0000, James Morse wrote:
> Keep the oops_begin() call for x86,
That oops_begin() in generic code is such a layering violation, grrr.
> arm64 doesn't have one of these,
> and APEI is the only thing outside arch code calling this..
So looking at:
arch/arm/kernel/traps.c:die()
it does call oops_begin() ... oops_end() just like the x86 version of
die().
I'm wondering if we could move the code to do die() in a prepatch? My
assumption is that all the arches should have die()... A quick grep does
show a bunch of other arches having die()...
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code
@ 2018-03-01 15:01 ` Borislav Petkov
0 siblings, 0 replies; 94+ messages in thread
From: Borislav Petkov @ 2018-03-01 15:01 UTC (permalink / raw)
To: James Morse
Cc: linux-acpi, kvmarm, linux-arm-kernel, linux-mm, Christoffer Dall,
Marc Zyngier, Catalin Marinas, Will Deacon, Naoya Horiguchi,
Rafael Wysocki, Len Brown, Tony Luck, Tyler Baicar, Dongjiu Geng,
Xie XiuQi, Punit Agrawal
On Thu, Feb 15, 2018 at 06:55:57PM +0000, James Morse wrote:
> Keep the oops_begin() call for x86,
That oops_begin() in generic code is such a layering violation, grrr.
> arm64 doesn't have one of these,
> and APEI is the only thing outside arch code calling this..
So looking at:
arch/arm/kernel/traps.c:die()
it does call oops_begin() ... oops_end() just like the x86 version of
die().
I'm wondering if we could move the code to do die() in a prepatch? My
assumption is that all the arches should have die()... A quick grep does
show a bunch of other arches having die()...
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code
@ 2018-03-01 15:01 ` Borislav Petkov
0 siblings, 0 replies; 94+ messages in thread
From: Borislav Petkov @ 2018-03-01 15:01 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Feb 15, 2018 at 06:55:57PM +0000, James Morse wrote:
> Keep the oops_begin() call for x86,
That oops_begin() in generic code is such a layering violation, grrr.
> arm64 doesn't have one of these,
> and APEI is the only thing outside arch code calling this..
So looking at:
arch/arm/kernel/traps.c:die()
it does call oops_begin() ... oops_end() just like the x86 version of
die().
I'm wondering if we could move the code to do die() in a prepatch? My
assumption is that all the arches should have die()... A quick grep does
show a bunch of other arches having die()...
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code
2018-03-01 15:01 ` Borislav Petkov
(?)
@ 2018-03-01 18:06 ` Punit Agrawal
-1 siblings, 0 replies; 94+ messages in thread
From: Punit Agrawal @ 2018-03-01 18:06 UTC (permalink / raw)
To: Borislav Petkov
Cc: Rafael Wysocki, Tony Luck, Xie XiuQi, linux-mm, Marc Zyngier,
Catalin Marinas, Tyler Baicar, Will Deacon, Dongjiu Geng,
linux-acpi, James Morse, linux-arm-kernel, Naoya Horiguchi,
kvmarm, Christoffer Dall, Len Brown
Hi Borislav,
Borislav Petkov <bp@alien8.de> writes:
> On Thu, Feb 15, 2018 at 06:55:57PM +0000, James Morse wrote:
>> Keep the oops_begin() call for x86,
>
> That oops_begin() in generic code is such a layering violation, grrr.
>
>> arm64 doesn't have one of these,
>> and APEI is the only thing outside arch code calling this..
>
> So looking at:
>
> arch/arm/kernel/traps.c:die()
>
> it does call oops_begin() ... oops_end() just like the x86 version of
> die().
You're looking at support for the 32-bit ARM systems. The 64-bit support
lives in arch/arm64 and the die() there doesn't contain an
oops_begin()/oops_end(). But the lack of oops_begin() on arm64 doesn't
really matter here.
>
> I'm wondering if we could move the code to do die() in a prepatch? My
> assumption is that all the arches should have die()... A quick grep does
> show a bunch of other arches having die()...
One issue I see with calling die() is that it is defined in different
includes across various architectures, (e.g., include/asm/kdebug.h for
x86, include/asm/system_misc.h in arm64, etc.)
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code
@ 2018-03-01 18:06 ` Punit Agrawal
0 siblings, 0 replies; 94+ messages in thread
From: Punit Agrawal @ 2018-03-01 18:06 UTC (permalink / raw)
To: Borislav Petkov
Cc: James Morse, linux-acpi, kvmarm, linux-arm-kernel, linux-mm,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
Naoya Horiguchi, Rafael Wysocki, Len Brown, Tony Luck,
Tyler Baicar, Dongjiu Geng, Xie XiuQi
Hi Borislav,
Borislav Petkov <bp@alien8.de> writes:
> On Thu, Feb 15, 2018 at 06:55:57PM +0000, James Morse wrote:
>> Keep the oops_begin() call for x86,
>
> That oops_begin() in generic code is such a layering violation, grrr.
>
>> arm64 doesn't have one of these,
>> and APEI is the only thing outside arch code calling this..
>
> So looking at:
>
> arch/arm/kernel/traps.c:die()
>
> it does call oops_begin() ... oops_end() just like the x86 version of
> die().
You're looking at support for the 32-bit ARM systems. The 64-bit support
lives in arch/arm64 and the die() there doesn't contain an
oops_begin()/oops_end(). But the lack of oops_begin() on arm64 doesn't
really matter here.
>
> I'm wondering if we could move the code to do die() in a prepatch? My
> assumption is that all the arches should have die()... A quick grep does
> show a bunch of other arches having die()...
One issue I see with calling die() is that it is defined in different
includes across various architectures, (e.g., include/asm/kdebug.h for
x86, include/asm/system_misc.h in arm64, etc.)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code
@ 2018-03-01 18:06 ` Punit Agrawal
0 siblings, 0 replies; 94+ messages in thread
From: Punit Agrawal @ 2018-03-01 18:06 UTC (permalink / raw)
To: linux-arm-kernel
Hi Borislav,
Borislav Petkov <bp@alien8.de> writes:
> On Thu, Feb 15, 2018 at 06:55:57PM +0000, James Morse wrote:
>> Keep the oops_begin() call for x86,
>
> That oops_begin() in generic code is such a layering violation, grrr.
>
>> arm64 doesn't have one of these,
>> and APEI is the only thing outside arch code calling this..
>
> So looking at:
>
> arch/arm/kernel/traps.c:die()
>
> it does call oops_begin() ... oops_end() just like the x86 version of
> die().
You're looking at support for the 32-bit ARM systems. The 64-bit support
lives in arch/arm64 and the die() there doesn't contain an
oops_begin()/oops_end(). But the lack of oops_begin() on arm64 doesn't
really matter here.
>
> I'm wondering if we could move the code to do die() in a prepatch? My
> assumption is that all the arches should have die()... A quick grep does
> show a bunch of other arches having die()...
One issue I see with calling die() is that it is defined in different
includes across various architectures, (e.g., include/asm/kdebug.h for
x86, include/asm/system_misc.h in arm64, etc.)
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code
2018-03-01 18:06 ` Punit Agrawal
(?)
@ 2018-03-01 22:35 ` Borislav Petkov
-1 siblings, 0 replies; 94+ messages in thread
From: Borislav Petkov @ 2018-03-01 22:35 UTC (permalink / raw)
To: Punit Agrawal
Cc: Rafael Wysocki, Tony Luck, Xie XiuQi, linux-mm, Marc Zyngier,
Catalin Marinas, Tyler Baicar, Will Deacon, Dongjiu Geng,
linux-acpi, James Morse, linux-arm-kernel, Naoya Horiguchi,
kvmarm, Christoffer Dall, Len Brown
On Thu, Mar 01, 2018 at 06:06:59PM +0000, Punit Agrawal wrote:
> You're looking at support for the 32-bit ARM systems.
I know. That's why I'm asking.
> The 64-bit support lives in arch/arm64 and the die() there doesn't
> contain an oops_begin()/oops_end(). But the lack of oops_begin() on
> arm64 doesn't really matter here.
Yap.
> One issue I see with calling die() is that it is defined in different
> includes across various architectures, (e.g., include/asm/kdebug.h for
> x86, include/asm/system_misc.h in arm64, etc.)
I don't think that's insurmountable.
The more important question is, can we do the same set of calls when
panic severity on all architectures which support APEI or should we have
arch-specific ghes_panic() callbacks or so.
As it is now, it would turn into a mess if we start with the ifdeffery
and the different requirements architectures might have...
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code
@ 2018-03-01 22:35 ` Borislav Petkov
0 siblings, 0 replies; 94+ messages in thread
From: Borislav Petkov @ 2018-03-01 22:35 UTC (permalink / raw)
To: Punit Agrawal
Cc: James Morse, linux-acpi, kvmarm, linux-arm-kernel, linux-mm,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
Naoya Horiguchi, Rafael Wysocki, Len Brown, Tony Luck,
Tyler Baicar, Dongjiu Geng, Xie XiuQi
On Thu, Mar 01, 2018 at 06:06:59PM +0000, Punit Agrawal wrote:
> You're looking at support for the 32-bit ARM systems.
I know. That's why I'm asking.
> The 64-bit support lives in arch/arm64 and the die() there doesn't
> contain an oops_begin()/oops_end(). But the lack of oops_begin() on
> arm64 doesn't really matter here.
Yap.
> One issue I see with calling die() is that it is defined in different
> includes across various architectures, (e.g., include/asm/kdebug.h for
> x86, include/asm/system_misc.h in arm64, etc.)
I don't think that's insurmountable.
The more important question is, can we do the same set of calls when
panic severity on all architectures which support APEI or should we have
arch-specific ghes_panic() callbacks or so.
As it is now, it would turn into a mess if we start with the ifdeffery
and the different requirements architectures might have...
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code
@ 2018-03-01 22:35 ` Borislav Petkov
0 siblings, 0 replies; 94+ messages in thread
From: Borislav Petkov @ 2018-03-01 22:35 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Mar 01, 2018 at 06:06:59PM +0000, Punit Agrawal wrote:
> You're looking at support for the 32-bit ARM systems.
I know. That's why I'm asking.
> The 64-bit support lives in arch/arm64 and the die() there doesn't
> contain an oops_begin()/oops_end(). But the lack of oops_begin() on
> arm64 doesn't really matter here.
Yap.
> One issue I see with calling die() is that it is defined in different
> includes across various architectures, (e.g., include/asm/kdebug.h for
> x86, include/asm/system_misc.h in arm64, etc.)
I don't think that's insurmountable.
The more important question is, can we do the same set of calls when
panic severity on all architectures which support APEI or should we have
arch-specific ghes_panic() callbacks or so.
As it is now, it would turn into a mess if we start with the ifdeffery
and the different requirements architectures might have...
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code
2018-03-01 22:35 ` Borislav Petkov
(?)
@ 2018-03-07 18:15 ` James Morse
-1 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-03-07 18:15 UTC (permalink / raw)
To: Borislav Petkov, Punit Agrawal
Cc: Rafael Wysocki, Tony Luck, Xie XiuQi, linux-mm, Marc Zyngier,
Catalin Marinas, Tyler Baicar, Will Deacon, Dongjiu Geng,
linux-acpi, linux-arm-kernel, Naoya Horiguchi, kvmarm,
Christoffer Dall, Len Brown
Hi Borislav, Punit,
On 01/03/18 22:35, Borislav Petkov wrote:
> On Thu, Mar 01, 2018 at 06:06:59PM +0000, Punit Agrawal wrote:
>> The 64-bit support lives in arch/arm64 and the die() there doesn't
>> contain an oops_begin()/oops_end(). But the lack of oops_begin() on
>> arm64 doesn't really matter here.
>> One issue I see with calling die() is that it is defined in different
>> includes across various architectures, (e.g., include/asm/kdebug.h for
>> x86, include/asm/system_misc.h in arm64, etc.)
>
> I don't think that's insurmountable.
I don't think die() helps us, its not quite the same as oops_begin()/panic(),
which means we're interpreting the APEI notification's severity differently,
depending on when we took it.
> The more important question is, can we do the same set of calls when
> panic severity on all architectures which support APEI or should we have
> arch-specific ghes_panic() callbacks or so.
I think the purpose of this oops_begin() is to ensure two CPUs calling
oops_begin() at the same time don't have their traces interleaved, unblanks the
screen and 'busts' any spinlocks printk() may need (console etc).
This code is called in_nmi(), printk() now supports this so it doesn't need its
locks busting.
When called in_nmi(), printk batches the messages into its per-cpu
printk_safe_seq_buf, which in our case is dumped by panic() using
printk_safe_flush_on_panic(). So provided we call panic(), the in_nmi() messages
from ghes.c are already batched, and printed behind panic()'s atomic_cmpxchg()
exclusion thing.
If your arm64 system has one of these futuristic 'screens', they get unblanked
when panic() calls console_verbose() and bust_spinlocks(1).
> As it is now, it would turn into a mess if we start with the ifdeffery
> and the different requirements architectures might have...
Today its just x86 and arm64. arm64 doesn't have a hook to do this. I'm happy to
add an empty declaration or leave it under an ifdef until someone complains
about any behaviour I missed!
Thanks,
James
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code
@ 2018-03-07 18:15 ` James Morse
0 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-03-07 18:15 UTC (permalink / raw)
To: Borislav Petkov, Punit Agrawal
Cc: linux-acpi, kvmarm, linux-arm-kernel, linux-mm, Christoffer Dall,
Marc Zyngier, Catalin Marinas, Will Deacon, Naoya Horiguchi,
Rafael Wysocki, Len Brown, Tony Luck, Tyler Baicar, Dongjiu Geng,
Xie XiuQi
Hi Borislav, Punit,
On 01/03/18 22:35, Borislav Petkov wrote:
> On Thu, Mar 01, 2018 at 06:06:59PM +0000, Punit Agrawal wrote:
>> The 64-bit support lives in arch/arm64 and the die() there doesn't
>> contain an oops_begin()/oops_end(). But the lack of oops_begin() on
>> arm64 doesn't really matter here.
>> One issue I see with calling die() is that it is defined in different
>> includes across various architectures, (e.g., include/asm/kdebug.h for
>> x86, include/asm/system_misc.h in arm64, etc.)
>
> I don't think that's insurmountable.
I don't think die() helps us, its not quite the same as oops_begin()/panic(),
which means we're interpreting the APEI notification's severity differently,
depending on when we took it.
> The more important question is, can we do the same set of calls when
> panic severity on all architectures which support APEI or should we have
> arch-specific ghes_panic() callbacks or so.
I think the purpose of this oops_begin() is to ensure two CPUs calling
oops_begin() at the same time don't have their traces interleaved, unblanks the
screen and 'busts' any spinlocks printk() may need (console etc).
This code is called in_nmi(), printk() now supports this so it doesn't need its
locks busting.
When called in_nmi(), printk batches the messages into its per-cpu
printk_safe_seq_buf, which in our case is dumped by panic() using
printk_safe_flush_on_panic(). So provided we call panic(), the in_nmi() messages
from ghes.c are already batched, and printed behind panic()'s atomic_cmpxchg()
exclusion thing.
If your arm64 system has one of these futuristic 'screens', they get unblanked
when panic() calls console_verbose() and bust_spinlocks(1).
> As it is now, it would turn into a mess if we start with the ifdeffery
> and the different requirements architectures might have...
Today its just x86 and arm64. arm64 doesn't have a hook to do this. I'm happy to
add an empty declaration or leave it under an ifdef until someone complains
about any behaviour I missed!
Thanks,
James
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code
@ 2018-03-07 18:15 ` James Morse
0 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-03-07 18:15 UTC (permalink / raw)
To: linux-arm-kernel
Hi Borislav, Punit,
On 01/03/18 22:35, Borislav Petkov wrote:
> On Thu, Mar 01, 2018 at 06:06:59PM +0000, Punit Agrawal wrote:
>> The 64-bit support lives in arch/arm64 and the die() there doesn't
>> contain an oops_begin()/oops_end(). But the lack of oops_begin() on
>> arm64 doesn't really matter here.
>> One issue I see with calling die() is that it is defined in different
>> includes across various architectures, (e.g., include/asm/kdebug.h for
>> x86, include/asm/system_misc.h in arm64, etc.)
>
> I don't think that's insurmountable.
I don't think die() helps us, its not quite the same as oops_begin()/panic(),
which means we're interpreting the APEI notification's severity differently,
depending on when we took it.
> The more important question is, can we do the same set of calls when
> panic severity on all architectures which support APEI or should we have
> arch-specific ghes_panic() callbacks or so.
I think the purpose of this oops_begin() is to ensure two CPUs calling
oops_begin() at the same time don't have their traces interleaved, unblanks the
screen and 'busts' any spinlocks printk() may need (console etc).
This code is called in_nmi(), printk() now supports this so it doesn't need its
locks busting.
When called in_nmi(), printk batches the messages into its per-cpu
printk_safe_seq_buf, which in our case is dumped by panic() using
printk_safe_flush_on_panic(). So provided we call panic(), the in_nmi() messages
from ghes.c are already batched, and printed behind panic()'s atomic_cmpxchg()
exclusion thing.
If your arm64 system has one of these futuristic 'screens', they get unblanked
when panic() calls console_verbose() and bust_spinlocks(1).
> As it is now, it would turn into a mess if we start with the ifdeffery
> and the different requirements architectures might have...
Today its just x86 and arm64. arm64 doesn't have a hook to do this. I'm happy to
add an empty declaration or leave it under an ifdef until someone complains
about any behaviour I missed!
Thanks,
James
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code
2018-03-07 18:15 ` James Morse
(?)
@ 2018-03-08 10:44 ` Borislav Petkov
-1 siblings, 0 replies; 94+ messages in thread
From: Borislav Petkov @ 2018-03-08 10:44 UTC (permalink / raw)
To: James Morse
Cc: Rafael Wysocki, Tony Luck, Xie XiuQi, linux-mm, Marc Zyngier,
Catalin Marinas, Punit Agrawal, Will Deacon, Tyler Baicar,
Dongjiu Geng, linux-acpi, linux-arm-kernel, Naoya Horiguchi,
kvmarm, Christoffer Dall, Len Brown
On Wed, Mar 07, 2018 at 06:15:02PM +0000, James Morse wrote:
> Today its just x86 and arm64. arm64 doesn't have a hook to do this. I'm happy to
> add an empty declaration or leave it under an ifdef until someone complains
> about any behaviour I missed!
So I did some more staring at the code and I think oops_begin() is
needed mainly, as you point out, to prevent two oops messages from
interleaving. And yap, the other stuff with printk() is not true anymore
because the commit which added oops_begin():
81e88fdc432a ("ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support")
still saw an NMI-unsafe printk. Which is long taken care of now.
So only the interleaving issue remains.
Which begs the question: how are you guys preventing the interleaving on
arm64? Because arch/arm64/kernel/traps.c:200 grabs the die_lock too, so
interleaving can happen on arm64 too, AFAICT.
And by that logic, you should technically grab that lock here too in
_in_nmi_notify_one().
Or?
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code
@ 2018-03-08 10:44 ` Borislav Petkov
0 siblings, 0 replies; 94+ messages in thread
From: Borislav Petkov @ 2018-03-08 10:44 UTC (permalink / raw)
To: James Morse
Cc: Punit Agrawal, linux-acpi, kvmarm, linux-arm-kernel, linux-mm,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
Naoya Horiguchi, Rafael Wysocki, Len Brown, Tony Luck,
Tyler Baicar, Dongjiu Geng, Xie XiuQi
On Wed, Mar 07, 2018 at 06:15:02PM +0000, James Morse wrote:
> Today its just x86 and arm64. arm64 doesn't have a hook to do this. I'm happy to
> add an empty declaration or leave it under an ifdef until someone complains
> about any behaviour I missed!
So I did some more staring at the code and I think oops_begin() is
needed mainly, as you point out, to prevent two oops messages from
interleaving. And yap, the other stuff with printk() is not true anymore
because the commit which added oops_begin():
81e88fdc432a ("ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support")
still saw an NMI-unsafe printk. Which is long taken care of now.
So only the interleaving issue remains.
Which begs the question: how are you guys preventing the interleaving on
arm64? Because arch/arm64/kernel/traps.c:200 grabs the die_lock too, so
interleaving can happen on arm64 too, AFAICT.
And by that logic, you should technically grab that lock here too in
_in_nmi_notify_one().
Or?
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code
@ 2018-03-08 10:44 ` Borislav Petkov
0 siblings, 0 replies; 94+ messages in thread
From: Borislav Petkov @ 2018-03-08 10:44 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Mar 07, 2018 at 06:15:02PM +0000, James Morse wrote:
> Today its just x86 and arm64. arm64 doesn't have a hook to do this. I'm happy to
> add an empty declaration or leave it under an ifdef until someone complains
> about any behaviour I missed!
So I did some more staring at the code and I think oops_begin() is
needed mainly, as you point out, to prevent two oops messages from
interleaving. And yap, the other stuff with printk() is not true anymore
because the commit which added oops_begin():
81e88fdc432a ("ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support")
still saw an NMI-unsafe printk. Which is long taken care of now.
So only the interleaving issue remains.
Which begs the question: how are you guys preventing the interleaving on
arm64? Because arch/arm64/kernel/traps.c:200 grabs the die_lock too, so
interleaving can happen on arm64 too, AFAICT.
And by that logic, you should technically grab that lock here too in
_in_nmi_notify_one().
Or?
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code
2018-03-08 10:44 ` Borislav Petkov
(?)
@ 2018-03-19 14:29 ` James Morse
-1 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-03-19 14:29 UTC (permalink / raw)
To: Borislav Petkov
Cc: Rafael Wysocki, Tony Luck, Xie XiuQi, linux-mm, Marc Zyngier,
Catalin Marinas, Punit Agrawal, Will Deacon, Tyler Baicar,
Dongjiu Geng, linux-acpi, linux-arm-kernel, Naoya Horiguchi,
kvmarm, Christoffer Dall, Len Brown
Hi Borislav,
On 08/03/18 10:44, Borislav Petkov wrote:
> On Wed, Mar 07, 2018 at 06:15:02PM +0000, James Morse wrote:
>> Today its just x86 and arm64. arm64 doesn't have a hook to do this. I'm happy to
>> add an empty declaration or leave it under an ifdef until someone complains
>> about any behaviour I missed!
>
> So I did some more staring at the code and I think oops_begin() is
> needed mainly, as you point out, to prevent two oops messages from
> interleaving. And yap, the other stuff with printk() is not true anymore
> because the commit which added oops_begin():
>
> 81e88fdc432a ("ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support")
>
> still saw an NMI-unsafe printk. Which is long taken care of now.
>
> So only the interleaving issue remains.
>
> Which begs the question: how are you guys preventing the interleaving on
> arm64? Because arch/arm64/kernel/traps.c:200 grabs the die_lock too, so
> interleaving can happen on arm64 too, AFAICT.
die() messages are stopped from interleaving with each other by that die_lock.
panic()s atomic_cmpxchg() then panic_smp_self_stop() means panic() is
first-past-the-post.
So our problem is interleaving of the two. The sequence is roughly:
1. oops_begin(); // I'm going to panic()
2. printk(some stuff);
3. panic();
Everything we print at (2) gets batched up by vprintk_nmi(), and is only printed
from (3) when we call printk_safe_flush_on_panic().
... and now I spot there are two calls to printk_safe_flush_on_panic(), one of
which happens before any smp_send_stop() calls.
This means we can get interleaving with panic() as we flush the printk_safe
buffer before smp_send_stop(), and even if we change that a remote CPU may
refuse to die. (Both x86 and arm64 have timeouts in their smp_send_stop() code).
> And by that logic, you should technically grab that lock here too in
> _in_nmi_notify_one().
I don't think the die_lock really helps here, do we really want to wait for a
remote CPU to finish printing an OOPs about user-space's bad memory accesses,
before we bring the machine down due to this system-wide fatal RAS error? The
presence of firmware-first means we know this error, and any other oops are
unrelated.
Grabbing the die_lock doesn't stop remote CPUs printing messages via a mechanism
other than die()/_in_nmi_notify_one(). I think oops_begin() is just plastering
over a problem. (how come this exclusion isn't done by oops_enter()/oops_exit()?)
Isn't oops_begin() trying to guarantee any messages printk()d by this CPU appear
'with' the subsequent panic()? I can't see any way to stop a remote CPU from
messing this up by printk()ing in a loop with interrupts masked, preventing us
from smp_send_stop()ing it, and making it difficult to take the lock.
I'd like to leave this under the x86-ifdef for now. For arm64 it would be an
APEI specific arch hook to stop the arch code from printing some messages,
meanwhile the rest of the kernel is unaffected. I suspect this sort of thing
really needs support from printk(). (maybe some printk() severity that mutes
other CPUs, or redirects them to the printk_safe buffer).
Thanks,
James
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code
@ 2018-03-19 14:29 ` James Morse
0 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-03-19 14:29 UTC (permalink / raw)
To: Borislav Petkov
Cc: Punit Agrawal, linux-acpi, kvmarm, linux-arm-kernel, linux-mm,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
Naoya Horiguchi, Rafael Wysocki, Len Brown, Tony Luck,
Tyler Baicar, Dongjiu Geng, Xie XiuQi
Hi Borislav,
On 08/03/18 10:44, Borislav Petkov wrote:
> On Wed, Mar 07, 2018 at 06:15:02PM +0000, James Morse wrote:
>> Today its just x86 and arm64. arm64 doesn't have a hook to do this. I'm happy to
>> add an empty declaration or leave it under an ifdef until someone complains
>> about any behaviour I missed!
>
> So I did some more staring at the code and I think oops_begin() is
> needed mainly, as you point out, to prevent two oops messages from
> interleaving. And yap, the other stuff with printk() is not true anymore
> because the commit which added oops_begin():
>
> 81e88fdc432a ("ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support")
>
> still saw an NMI-unsafe printk. Which is long taken care of now.
>
> So only the interleaving issue remains.
>
> Which begs the question: how are you guys preventing the interleaving on
> arm64? Because arch/arm64/kernel/traps.c:200 grabs the die_lock too, so
> interleaving can happen on arm64 too, AFAICT.
die() messages are stopped from interleaving with each other by that die_lock.
panic()s atomic_cmpxchg() then panic_smp_self_stop() means panic() is
first-past-the-post.
So our problem is interleaving of the two. The sequence is roughly:
1. oops_begin(); // I'm going to panic()
2. printk(some stuff);
3. panic();
Everything we print at (2) gets batched up by vprintk_nmi(), and is only printed
from (3) when we call printk_safe_flush_on_panic().
... and now I spot there are two calls to printk_safe_flush_on_panic(), one of
which happens before any smp_send_stop() calls.
This means we can get interleaving with panic() as we flush the printk_safe
buffer before smp_send_stop(), and even if we change that a remote CPU may
refuse to die. (Both x86 and arm64 have timeouts in their smp_send_stop() code).
> And by that logic, you should technically grab that lock here too in
> _in_nmi_notify_one().
I don't think the die_lock really helps here, do we really want to wait for a
remote CPU to finish printing an OOPs about user-space's bad memory accesses,
before we bring the machine down due to this system-wide fatal RAS error? The
presence of firmware-first means we know this error, and any other oops are
unrelated.
Grabbing the die_lock doesn't stop remote CPUs printing messages via a mechanism
other than die()/_in_nmi_notify_one(). I think oops_begin() is just plastering
over a problem. (how come this exclusion isn't done by oops_enter()/oops_exit()?)
Isn't oops_begin() trying to guarantee any messages printk()d by this CPU appear
'with' the subsequent panic()? I can't see any way to stop a remote CPU from
messing this up by printk()ing in a loop with interrupts masked, preventing us
from smp_send_stop()ing it, and making it difficult to take the lock.
I'd like to leave this under the x86-ifdef for now. For arm64 it would be an
APEI specific arch hook to stop the arch code from printing some messages,
meanwhile the rest of the kernel is unaffected. I suspect this sort of thing
really needs support from printk(). (maybe some printk() severity that mutes
other CPUs, or redirects them to the printk_safe buffer).
Thanks,
James
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code
@ 2018-03-19 14:29 ` James Morse
0 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-03-19 14:29 UTC (permalink / raw)
To: linux-arm-kernel
Hi Borislav,
On 08/03/18 10:44, Borislav Petkov wrote:
> On Wed, Mar 07, 2018 at 06:15:02PM +0000, James Morse wrote:
>> Today its just x86 and arm64. arm64 doesn't have a hook to do this. I'm happy to
>> add an empty declaration or leave it under an ifdef until someone complains
>> about any behaviour I missed!
>
> So I did some more staring at the code and I think oops_begin() is
> needed mainly, as you point out, to prevent two oops messages from
> interleaving. And yap, the other stuff with printk() is not true anymore
> because the commit which added oops_begin():
>
> 81e88fdc432a ("ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support")
>
> still saw an NMI-unsafe printk. Which is long taken care of now.
>
> So only the interleaving issue remains.
>
> Which begs the question: how are you guys preventing the interleaving on
> arm64? Because arch/arm64/kernel/traps.c:200 grabs the die_lock too, so
> interleaving can happen on arm64 too, AFAICT.
die() messages are stopped from interleaving with each other by that die_lock.
panic()s atomic_cmpxchg() then panic_smp_self_stop() means panic() is
first-past-the-post.
So our problem is interleaving of the two. The sequence is roughly:
1. oops_begin(); // I'm going to panic()
2. printk(some stuff);
3. panic();
Everything we print at (2) gets batched up by vprintk_nmi(), and is only printed
from (3) when we call printk_safe_flush_on_panic().
... and now I spot there are two calls to printk_safe_flush_on_panic(), one of
which happens before any smp_send_stop() calls.
This means we can get interleaving with panic() as we flush the printk_safe
buffer before smp_send_stop(), and even if we change that a remote CPU may
refuse to die. (Both x86 and arm64 have timeouts in their smp_send_stop() code).
> And by that logic, you should technically grab that lock here too in
> _in_nmi_notify_one().
I don't think the die_lock really helps here, do we really want to wait for a
remote CPU to finish printing an OOPs about user-space's bad memory accesses,
before we bring the machine down due to this system-wide fatal RAS error? The
presence of firmware-first means we know this error, and any other oops are
unrelated.
Grabbing the die_lock doesn't stop remote CPUs printing messages via a mechanism
other than die()/_in_nmi_notify_one(). I think oops_begin() is just plastering
over a problem. (how come this exclusion isn't done by oops_enter()/oops_exit()?)
Isn't oops_begin() trying to guarantee any messages printk()d by this CPU appear
'with' the subsequent panic()? I can't see any way to stop a remote CPU from
messing this up by printk()ing in a loop with interrupts masked, preventing us
from smp_send_stop()ing it, and making it difficult to take the lock.
I'd like to leave this under the x86-ifdef for now. For arm64 it would be an
APEI specific arch hook to stop the arch code from printing some messages,
meanwhile the rest of the kernel is unaffected. I suspect this sort of thing
really needs support from printk(). (maybe some printk() severity that mutes
other CPUs, or redirects them to the printk_safe buffer).
Thanks,
James
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code
2018-03-19 14:29 ` James Morse
(?)
@ 2018-03-27 17:25 ` Borislav Petkov
-1 siblings, 0 replies; 94+ messages in thread
From: Borislav Petkov @ 2018-03-27 17:25 UTC (permalink / raw)
To: James Morse
Cc: Rafael Wysocki, Tony Luck, Xie XiuQi, linux-mm, Marc Zyngier,
Catalin Marinas, Punit Agrawal, Will Deacon, Tyler Baicar,
Dongjiu Geng, linux-acpi, linux-arm-kernel, Naoya Horiguchi,
kvmarm, Christoffer Dall, Len Brown
Hi James,
On Mon, Mar 19, 2018 at 02:29:13PM +0000, James Morse wrote:
> I don't think the die_lock really helps here, do we really want to wait for a
> remote CPU to finish printing an OOPs about user-space's bad memory accesses,
> before we bring the machine down due to this system-wide fatal RAS error? The
> presence of firmware-first means we know this error, and any other oops are
> unrelated.
Hmm, now that you put it this way...
> I'd like to leave this under the x86-ifdef for now. For arm64 it would be an
> APEI specific arch hook to stop the arch code from printing some messages,
... I'm thinking we should ignore the whole serializing of oopses and
really dump that hw error ASAP. If it really is a fatal error, our main
and only goal is to get it out as fast as possible so that it has the
highest chance to appear on some screen or logging facility and thus the
system can be serviced successfully.
And the other oopses have lower prio.
Hmmm?
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code
@ 2018-03-27 17:25 ` Borislav Petkov
0 siblings, 0 replies; 94+ messages in thread
From: Borislav Petkov @ 2018-03-27 17:25 UTC (permalink / raw)
To: James Morse
Cc: Punit Agrawal, linux-acpi, kvmarm, linux-arm-kernel, linux-mm,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
Naoya Horiguchi, Rafael Wysocki, Len Brown, Tony Luck,
Tyler Baicar, Dongjiu Geng, Xie XiuQi
Hi James,
On Mon, Mar 19, 2018 at 02:29:13PM +0000, James Morse wrote:
> I don't think the die_lock really helps here, do we really want to wait for a
> remote CPU to finish printing an OOPs about user-space's bad memory accesses,
> before we bring the machine down due to this system-wide fatal RAS error? The
> presence of firmware-first means we know this error, and any other oops are
> unrelated.
Hmm, now that you put it this way...
> I'd like to leave this under the x86-ifdef for now. For arm64 it would be an
> APEI specific arch hook to stop the arch code from printing some messages,
... I'm thinking we should ignore the whole serializing of oopses and
really dump that hw error ASAP. If it really is a fatal error, our main
and only goal is to get it out as fast as possible so that it has the
highest chance to appear on some screen or logging facility and thus the
system can be serviced successfully.
And the other oopses have lower prio.
Hmmm?
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code
@ 2018-03-27 17:25 ` Borislav Petkov
0 siblings, 0 replies; 94+ messages in thread
From: Borislav Petkov @ 2018-03-27 17:25 UTC (permalink / raw)
To: linux-arm-kernel
Hi James,
On Mon, Mar 19, 2018 at 02:29:13PM +0000, James Morse wrote:
> I don't think the die_lock really helps here, do we really want to wait for a
> remote CPU to finish printing an OOPs about user-space's bad memory accesses,
> before we bring the machine down due to this system-wide fatal RAS error? The
> presence of firmware-first means we know this error, and any other oops are
> unrelated.
Hmm, now that you put it this way...
> I'd like to leave this under the x86-ifdef for now. For arm64 it would be an
> APEI specific arch hook to stop the arch code from printing some messages,
... I'm thinking we should ignore the whole serializing of oopses and
really dump that hw error ASAP. If it really is a fatal error, our main
and only goal is to get it out as fast as possible so that it has the
highest chance to appear on some screen or logging facility and thus the
system can be serviced successfully.
And the other oopses have lower prio.
Hmmm?
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code
2018-03-27 17:25 ` Borislav Petkov
(?)
@ 2018-03-28 16:30 ` James Morse
-1 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-03-28 16:30 UTC (permalink / raw)
To: Borislav Petkov
Cc: Rafael Wysocki, Tony Luck, Xie XiuQi, linux-mm, Marc Zyngier,
Catalin Marinas, Punit Agrawal, Will Deacon, Tyler Baicar,
Dongjiu Geng, linux-acpi, linux-arm-kernel, Naoya Horiguchi,
kvmarm, Christoffer Dall, Len Brown
Hi Borislav,
On 27/03/18 18:25, Borislav Petkov wrote:
> On Mon, Mar 19, 2018 at 02:29:13PM +0000, James Morse wrote:
>> I don't think the die_lock really helps here, do we really want to wait for a
>> remote CPU to finish printing an OOPs about user-space's bad memory accesses,
>> before we bring the machine down due to this system-wide fatal RAS error? The
>> presence of firmware-first means we know this error, and any other oops are
>> unrelated.
>
> Hmm, now that you put it this way...
>> I'd like to leave this under the x86-ifdef for now. For arm64 it would be an
>> APEI specific arch hook to stop the arch code from printing some messages,
>
> ... I'm thinking we should ignore the whole serializing of oopses and
> really dump that hw error ASAP. If it really is a fatal error, our main
> and only goal is to get it out as fast as possible so that it has the
> highest chance to appear on some screen or logging facility and thus the
> system can be serviced successfully.
>
> And the other oopses have lower prio.
> Hmmm?
Yes, I agree. With firmware-first we know that errors the firmware takes first,
then notifies by NMI causing us to panic() must be a higher priority than
another oops.
I'll add a patch[0] to v3 making this argument and removing the #ifdef'd
oops_begin().
Thanks,
James
[0]
-----------------%<-----------------
ACPI / APEI: don't wait to serialise with oops messages when panic()ing
oops_begin() exists to group printk() messages with the oops message
printed by die(). To reach this caller we know that platform firmware
took this error first, then notified the OS via NMI with a 'panic'
severity.
Don't wait for another CPU to release the die-lock before we can
panic(), our only goal is to print this fatal error and panic().
This code is always called in_nmi(), and since 42a0bb3f7138 ("printk/nmi:
generic solution for safe printk in NMI"), it has been safe to call
printk() from this context. Messages are batched in a per-cpu buffer
and printed via irq-work, or a call back from panic().
Signed-off-by: James Morse <james.morse@arm.com>
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 22f6ea5b9ad5..f348e6540960 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -34,7 +34,6 @@
#include <linux/interrupt.h>
#include <linux/timer.h>
#include <linux/cper.h>
-#include <linux/kdebug.h>
#include <linux/platform_device.h>
#include <linux/mutex.h>
#include <linux/ratelimit.h>
@@ -736,9 +735,6 @@ static int _in_nmi_notify_one(struct ghes *ghes)
sev = ghes_severity(ghes->estatus->error_severity);
if (sev >= GHES_SEV_PANIC) {
-#ifdef CONFIG_X86
- oops_begin();
-#endif
ghes_print_queued_estatus();
__ghes_panic(ghes);
}
-----------------%<-----------------
^ permalink raw reply related [flat|nested] 94+ messages in thread
* Re: [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code
@ 2018-03-28 16:30 ` James Morse
0 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-03-28 16:30 UTC (permalink / raw)
To: Borislav Petkov
Cc: Punit Agrawal, linux-acpi, kvmarm, linux-arm-kernel, linux-mm,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
Naoya Horiguchi, Rafael Wysocki, Len Brown, Tony Luck,
Tyler Baicar, Dongjiu Geng, Xie XiuQi
Hi Borislav,
On 27/03/18 18:25, Borislav Petkov wrote:
> On Mon, Mar 19, 2018 at 02:29:13PM +0000, James Morse wrote:
>> I don't think the die_lock really helps here, do we really want to wait for a
>> remote CPU to finish printing an OOPs about user-space's bad memory accesses,
>> before we bring the machine down due to this system-wide fatal RAS error? The
>> presence of firmware-first means we know this error, and any other oops are
>> unrelated.
>
> Hmm, now that you put it this way...
>> I'd like to leave this under the x86-ifdef for now. For arm64 it would be an
>> APEI specific arch hook to stop the arch code from printing some messages,
>
> ... I'm thinking we should ignore the whole serializing of oopses and
> really dump that hw error ASAP. If it really is a fatal error, our main
> and only goal is to get it out as fast as possible so that it has the
> highest chance to appear on some screen or logging facility and thus the
> system can be serviced successfully.
>
> And the other oopses have lower prio.
> Hmmm?
Yes, I agree. With firmware-first we know that errors the firmware takes first,
then notifies by NMI causing us to panic() must be a higher priority than
another oops.
I'll add a patch[0] to v3 making this argument and removing the #ifdef'd
oops_begin().
Thanks,
James
[0]
-----------------%<-----------------
ACPI / APEI: don't wait to serialise with oops messages when panic()ing
oops_begin() exists to group printk() messages with the oops message
printed by die(). To reach this caller we know that platform firmware
took this error first, then notified the OS via NMI with a 'panic'
severity.
Don't wait for another CPU to release the die-lock before we can
panic(), our only goal is to print this fatal error and panic().
This code is always called in_nmi(), and since 42a0bb3f7138 ("printk/nmi:
generic solution for safe printk in NMI"), it has been safe to call
printk() from this context. Messages are batched in a per-cpu buffer
and printed via irq-work, or a call back from panic().
Signed-off-by: James Morse <james.morse@arm.com>
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 22f6ea5b9ad5..f348e6540960 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -34,7 +34,6 @@
#include <linux/interrupt.h>
#include <linux/timer.h>
#include <linux/cper.h>
-#include <linux/kdebug.h>
#include <linux/platform_device.h>
#include <linux/mutex.h>
#include <linux/ratelimit.h>
@@ -736,9 +735,6 @@ static int _in_nmi_notify_one(struct ghes *ghes)
sev = ghes_severity(ghes->estatus->error_severity);
if (sev >= GHES_SEV_PANIC) {
-#ifdef CONFIG_X86
- oops_begin();
-#endif
ghes_print_queued_estatus();
__ghes_panic(ghes);
}
-----------------%<-----------------
^ permalink raw reply related [flat|nested] 94+ messages in thread
* [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code
@ 2018-03-28 16:30 ` James Morse
0 siblings, 0 replies; 94+ messages in thread
From: James Morse @ 2018-03-28 16:30 UTC (permalink / raw)
To: linux-arm-kernel
Hi Borislav,
On 27/03/18 18:25, Borislav Petkov wrote:
> On Mon, Mar 19, 2018 at 02:29:13PM +0000, James Morse wrote:
>> I don't think the die_lock really helps here, do we really want to wait for a
>> remote CPU to finish printing an OOPs about user-space's bad memory accesses,
>> before we bring the machine down due to this system-wide fatal RAS error? The
>> presence of firmware-first means we know this error, and any other oops are
>> unrelated.
>
> Hmm, now that you put it this way...
>> I'd like to leave this under the x86-ifdef for now. For arm64 it would be an
>> APEI specific arch hook to stop the arch code from printing some messages,
>
> ... I'm thinking we should ignore the whole serializing of oopses and
> really dump that hw error ASAP. If it really is a fatal error, our main
> and only goal is to get it out as fast as possible so that it has the
> highest chance to appear on some screen or logging facility and thus the
> system can be serviced successfully.
>
> And the other oopses have lower prio.
> Hmmm?
Yes, I agree. With firmware-first we know that errors the firmware takes first,
then notifies by NMI causing us to panic() must be a higher priority than
another oops.
I'll add a patch[0] to v3 making this argument and removing the #ifdef'd
oops_begin().
Thanks,
James
[0]
-----------------%<-----------------
ACPI / APEI: don't wait to serialise with oops messages when panic()ing
oops_begin() exists to group printk() messages with the oops message
printed by die(). To reach this caller we know that platform firmware
took this error first, then notified the OS via NMI with a 'panic'
severity.
Don't wait for another CPU to release the die-lock before we can
panic(), our only goal is to print this fatal error and panic().
This code is always called in_nmi(), and since 42a0bb3f7138 ("printk/nmi:
generic solution for safe printk in NMI"), it has been safe to call
printk() from this context. Messages are batched in a per-cpu buffer
and printed via irq-work, or a call back from panic().
Signed-off-by: James Morse <james.morse@arm.com>
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 22f6ea5b9ad5..f348e6540960 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -34,7 +34,6 @@
#include <linux/interrupt.h>
#include <linux/timer.h>
#include <linux/cper.h>
-#include <linux/kdebug.h>
#include <linux/platform_device.h>
#include <linux/mutex.h>
#include <linux/ratelimit.h>
@@ -736,9 +735,6 @@ static int _in_nmi_notify_one(struct ghes *ghes)
sev = ghes_severity(ghes->estatus->error_severity);
if (sev >= GHES_SEV_PANIC) {
-#ifdef CONFIG_X86
- oops_begin();
-#endif
ghes_print_queued_estatus();
__ghes_panic(ghes);
}
-----------------%<-----------------
^ permalink raw reply related [flat|nested] 94+ messages in thread
* Re: [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code
2018-03-28 16:30 ` James Morse
(?)
@ 2018-04-17 15:10 ` Borislav Petkov
-1 siblings, 0 replies; 94+ messages in thread
From: Borislav Petkov @ 2018-04-17 15:10 UTC (permalink / raw)
To: James Morse
Cc: Rafael Wysocki, Tony Luck, Xie XiuQi, linux-mm, Marc Zyngier,
Catalin Marinas, Punit Agrawal, Will Deacon, Tyler Baicar,
Dongjiu Geng, linux-acpi, linux-arm-kernel, Naoya Horiguchi,
kvmarm, Christoffer Dall, Len Brown
On Wed, Mar 28, 2018 at 05:30:55PM +0100, James Morse wrote:
> -----------------%<-----------------
> ACPI / APEI: don't wait to serialise with oops messages when panic()ing
>
> oops_begin() exists to group printk() messages with the oops message
> printed by die(). To reach this caller we know that platform firmware
> took this error first, then notified the OS via NMI with a 'panic'
> severity.
>
> Don't wait for another CPU to release the die-lock before we can
> panic(), our only goal is to print this fatal error and panic().
>
> This code is always called in_nmi(), and since 42a0bb3f7138 ("printk/nmi:
> generic solution for safe printk in NMI"), it has been safe to call
> printk() from this context. Messages are batched in a per-cpu buffer
> and printed via irq-work, or a call back from panic().
>
> Signed-off-by: James Morse <james.morse@arm.com>
>
> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
> index 22f6ea5b9ad5..f348e6540960 100644
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
> @@ -34,7 +34,6 @@
> #include <linux/interrupt.h>
> #include <linux/timer.h>
> #include <linux/cper.h>
> -#include <linux/kdebug.h>
> #include <linux/platform_device.h>
> #include <linux/mutex.h>
> #include <linux/ratelimit.h>
> @@ -736,9 +735,6 @@ static int _in_nmi_notify_one(struct ghes *ghes)
>
> sev = ghes_severity(ghes->estatus->error_severity);
> if (sev >= GHES_SEV_PANIC) {
> -#ifdef CONFIG_X86
> - oops_begin();
> -#endif
> ghes_print_queued_estatus();
> __ghes_panic(ghes);
> }
> -----------------%<-----------------
Acked-by: Borislav Petkov <bp@suse.de>
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply [flat|nested] 94+ messages in thread
* Re: [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code
@ 2018-04-17 15:10 ` Borislav Petkov
0 siblings, 0 replies; 94+ messages in thread
From: Borislav Petkov @ 2018-04-17 15:10 UTC (permalink / raw)
To: James Morse
Cc: Punit Agrawal, linux-acpi, kvmarm, linux-arm-kernel, linux-mm,
Christoffer Dall, Marc Zyngier, Catalin Marinas, Will Deacon,
Naoya Horiguchi, Rafael Wysocki, Len Brown, Tony Luck,
Tyler Baicar, Dongjiu Geng, Xie XiuQi
On Wed, Mar 28, 2018 at 05:30:55PM +0100, James Morse wrote:
> -----------------%<-----------------
> ACPI / APEI: don't wait to serialise with oops messages when panic()ing
>
> oops_begin() exists to group printk() messages with the oops message
> printed by die(). To reach this caller we know that platform firmware
> took this error first, then notified the OS via NMI with a 'panic'
> severity.
>
> Don't wait for another CPU to release the die-lock before we can
> panic(), our only goal is to print this fatal error and panic().
>
> This code is always called in_nmi(), and since 42a0bb3f7138 ("printk/nmi:
> generic solution for safe printk in NMI"), it has been safe to call
> printk() from this context. Messages are batched in a per-cpu buffer
> and printed via irq-work, or a call back from panic().
>
> Signed-off-by: James Morse <james.morse@arm.com>
>
> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
> index 22f6ea5b9ad5..f348e6540960 100644
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
> @@ -34,7 +34,6 @@
> #include <linux/interrupt.h>
> #include <linux/timer.h>
> #include <linux/cper.h>
> -#include <linux/kdebug.h>
> #include <linux/platform_device.h>
> #include <linux/mutex.h>
> #include <linux/ratelimit.h>
> @@ -736,9 +735,6 @@ static int _in_nmi_notify_one(struct ghes *ghes)
>
> sev = ghes_severity(ghes->estatus->error_severity);
> if (sev >= GHES_SEV_PANIC) {
> -#ifdef CONFIG_X86
> - oops_begin();
> -#endif
> ghes_print_queued_estatus();
> __ghes_panic(ghes);
> }
> -----------------%<-----------------
Acked-by: Borislav Petkov <bp@suse.de>
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code
@ 2018-04-17 15:10 ` Borislav Petkov
0 siblings, 0 replies; 94+ messages in thread
From: Borislav Petkov @ 2018-04-17 15:10 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Mar 28, 2018 at 05:30:55PM +0100, James Morse wrote:
> -----------------%<-----------------
> ACPI / APEI: don't wait to serialise with oops messages when panic()ing
>
> oops_begin() exists to group printk() messages with the oops message
> printed by die(). To reach this caller we know that platform firmware
> took this error first, then notified the OS via NMI with a 'panic'
> severity.
>
> Don't wait for another CPU to release the die-lock before we can
> panic(), our only goal is to print this fatal error and panic().
>
> This code is always called in_nmi(), and since 42a0bb3f7138 ("printk/nmi:
> generic solution for safe printk in NMI"), it has been safe to call
> printk() from this context. Messages are batched in a per-cpu buffer
> and printed via irq-work, or a call back from panic().
>
> Signed-off-by: James Morse <james.morse@arm.com>
>
> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
> index 22f6ea5b9ad5..f348e6540960 100644
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
> @@ -34,7 +34,6 @@
> #include <linux/interrupt.h>
> #include <linux/timer.h>
> #include <linux/cper.h>
> -#include <linux/kdebug.h>
> #include <linux/platform_device.h>
> #include <linux/mutex.h>
> #include <linux/ratelimit.h>
> @@ -736,9 +735,6 @@ static int _in_nmi_notify_one(struct ghes *ghes)
>
> sev = ghes_severity(ghes->estatus->error_severity);
> if (sev >= GHES_SEV_PANIC) {
> -#ifdef CONFIG_X86
> - oops_begin();
> -#endif
> ghes_print_queued_estatus();
> __ghes_panic(ghes);
> }
> -----------------%<-----------------
Acked-by: Borislav Petkov <bp@suse.de>
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply [flat|nested] 94+ messages in thread
end of thread, other threads:[~2018-04-17 15:10 UTC | newest]
Thread overview: 94+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-02-15 18:55 [PATCH 00/11] APEI in_nmi() rework and arm64 SDEI wire-up James Morse
2018-02-15 18:55 ` James Morse
2018-02-15 18:55 ` James Morse
2018-02-15 18:55 ` [PATCH 01/11] ACPI / APEI: Move the estatus queue code up, and under its own ifdef James Morse
2018-02-15 18:55 ` James Morse
2018-02-15 18:55 ` James Morse
2018-02-20 18:26 ` Punit Agrawal
2018-02-20 18:26 ` Punit Agrawal
2018-02-20 18:26 ` Punit Agrawal
2018-02-20 19:28 ` Borislav Petkov
2018-02-20 19:28 ` Borislav Petkov
2018-02-20 19:28 ` Borislav Petkov
2018-02-23 18:02 ` James Morse
2018-02-23 18:02 ` James Morse
2018-02-23 18:02 ` James Morse
2018-02-23 18:07 ` Borislav Petkov
2018-02-23 18:07 ` Borislav Petkov
2018-02-23 18:07 ` Borislav Petkov
2018-02-15 18:55 ` [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code James Morse
2018-02-15 18:55 ` James Morse
2018-02-15 18:55 ` James Morse
2018-02-20 18:26 ` Punit Agrawal
2018-02-20 18:26 ` Punit Agrawal
2018-02-20 18:26 ` Punit Agrawal
2018-02-23 18:21 ` James Morse
2018-02-23 18:21 ` James Morse
2018-02-23 18:21 ` James Morse
2018-03-01 15:01 ` Borislav Petkov
2018-03-01 15:01 ` Borislav Petkov
2018-03-01 15:01 ` Borislav Petkov
2018-03-01 18:06 ` Punit Agrawal
2018-03-01 18:06 ` Punit Agrawal
2018-03-01 18:06 ` Punit Agrawal
2018-03-01 22:35 ` Borislav Petkov
2018-03-01 22:35 ` Borislav Petkov
2018-03-01 22:35 ` Borislav Petkov
2018-03-07 18:15 ` James Morse
2018-03-07 18:15 ` James Morse
2018-03-07 18:15 ` James Morse
2018-03-08 10:44 ` Borislav Petkov
2018-03-08 10:44 ` Borislav Petkov
2018-03-08 10:44 ` Borislav Petkov
2018-03-19 14:29 ` James Morse
2018-03-19 14:29 ` James Morse
2018-03-19 14:29 ` James Morse
2018-03-27 17:25 ` Borislav Petkov
2018-03-27 17:25 ` Borislav Petkov
2018-03-27 17:25 ` Borislav Petkov
2018-03-28 16:30 ` James Morse
2018-03-28 16:30 ` James Morse
2018-03-28 16:30 ` James Morse
2018-04-17 15:10 ` Borislav Petkov
2018-04-17 15:10 ` Borislav Petkov
2018-04-17 15:10 ` Borislav Petkov
2018-02-15 18:55 ` [PATCH 03/11] ACPI / APEI: Switch NOTIFY_SEA to use the estatus queue James Morse
2018-02-15 18:55 ` James Morse
2018-02-15 18:55 ` James Morse
2018-02-15 18:55 ` [PATCH 04/11] KVM: arm/arm64: Add kvm_ras.h to collect kvm specific RAS plumbing James Morse
2018-02-15 18:55 ` James Morse
2018-02-15 18:56 ` [PATCH 05/11] arm64: KVM/mm: Move SEA handling behind a single 'claim' interface James Morse
2018-02-15 18:56 ` James Morse
2018-02-20 18:30 ` Punit Agrawal
2018-02-20 18:30 ` Punit Agrawal
2018-02-20 18:30 ` Punit Agrawal
2018-02-15 18:56 ` [PATCH 06/11] ACPI / APEI: Make the fixmap_idx per-ghes to allow multiple in_nmi() users James Morse
2018-02-15 18:56 ` James Morse
2018-02-20 21:18 ` Tyler Baicar
2018-02-20 21:18 ` Tyler Baicar
2018-02-20 21:18 ` Tyler Baicar
2018-02-22 17:47 ` James Morse
2018-02-22 17:47 ` James Morse
2018-02-22 17:47 ` James Morse
2018-02-15 18:56 ` [PATCH 07/11] ACPI / APEI: Split fixmap pages for arm64 NMI-like notifications James Morse
2018-02-15 18:56 ` James Morse
2018-02-15 18:56 ` James Morse
2018-02-15 18:56 ` [PATCH 08/11] firmware: arm_sdei: Add ACPI GHES registration helper James Morse
2018-02-15 18:56 ` James Morse
2018-02-20 18:31 ` Punit Agrawal
2018-02-20 18:31 ` Punit Agrawal
2018-02-20 18:31 ` Punit Agrawal
2018-02-15 18:56 ` [PATCH 09/11] ACPI / APEI: Add support for the SDEI GHES Notification type James Morse
2018-02-15 18:56 ` James Morse
2018-02-15 18:56 ` James Morse
2018-02-15 18:56 ` [PATCH 10/11] mm/memory-failure: increase queued recovery work's priority James Morse
2018-02-15 18:56 ` James Morse
2018-02-15 18:56 ` James Morse
2018-02-15 18:56 ` [PATCH 11/11] arm64: acpi: Make apei_claim_sea() synchronise with APEI's irq work James Morse
2018-02-15 18:56 ` James Morse
2018-02-19 21:05 ` [PATCH 00/11] APEI in_nmi() rework and arm64 SDEI wire-up Borislav Petkov
2018-02-19 21:05 ` Borislav Petkov
2018-02-19 21:05 ` Borislav Petkov
2018-02-20 18:42 ` Punit Agrawal
2018-02-20 18:42 ` Punit Agrawal
2018-02-20 18:42 ` Punit Agrawal
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.