From: James Morse <james.morse@arm.com>
To: Punit Agrawal <punit.agrawal@arm.com>
Cc: Rafael Wysocki <rjw@rjwysocki.net>,
Tony Luck <tony.luck@intel.com>, Xie XiuQi <xiexiuqi@huawei.com>,
linux-mm@kvack.org, Marc Zyngier <marc.zyngier@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Tyler Baicar <tbaicar@codeaurora.org>,
Will Deacon <will.deacon@arm.com>,
Dongjiu Geng <gengdongjiu@huawei.com>,
linux-acpi@vger.kernel.org, Borislav Petkov <bp@alien8.de>,
linux-arm-kernel@lists.infradead.org,
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
kvmarm@lists.cs.columbia.edu,
Christoffer Dall <christoffer.dall@linaro.org>,
Len Brown <lenb@kernel.org>
Subject: Re: [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code
Date: Fri, 23 Feb 2018 18:21:31 +0000 [thread overview]
Message-ID: <5A905BAB.2060007@arm.com> (raw)
In-Reply-To: <87sh9vzfdn.fsf@e105922-lin.cambridge.arm.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: james.morse@arm.com (James Morse)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code
Date: Fri, 23 Feb 2018 18:21:31 +0000 [thread overview]
Message-ID: <5A905BAB.2060007@arm.com> (raw)
In-Reply-To: <87sh9vzfdn.fsf@e105922-lin.cambridge.arm.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: James Morse <james.morse@arm.com>
To: Punit Agrawal <punit.agrawal@arm.com>
Cc: linux-acpi@vger.kernel.org, kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org,
Borislav Petkov <bp@alien8.de>,
Christoffer Dall <christoffer.dall@linaro.org>,
Marc Zyngier <marc.zyngier@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
Rafael Wysocki <rjw@rjwysocki.net>, Len Brown <lenb@kernel.org>,
Tony Luck <tony.luck@intel.com>,
Tyler Baicar <tbaicar@codeaurora.org>,
Dongjiu Geng <gengdongjiu@huawei.com>,
Xie XiuQi <xiexiuqi@huawei.com>
Subject: Re: [PATCH 02/11] ACPI / APEI: Generalise the estatus queue's add/remove and notify code
Date: Fri, 23 Feb 2018 18:21:31 +0000 [thread overview]
Message-ID: <5A905BAB.2060007@arm.com> (raw)
In-Reply-To: <87sh9vzfdn.fsf@e105922-lin.cambridge.arm.com>
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>
next prev parent reply other threads:[~2018-02-23 18:21 UTC|newest]
Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5A905BAB.2060007@arm.com \
--to=james.morse@arm.com \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=christoffer.dall@linaro.org \
--cc=gengdongjiu@huawei.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=marc.zyngier@arm.com \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=punit.agrawal@arm.com \
--cc=rjw@rjwysocki.net \
--cc=tbaicar@codeaurora.org \
--cc=tony.luck@intel.com \
--cc=will.deacon@arm.com \
--cc=xiexiuqi@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is 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.