Re: [PATCH 01/11] ACPI / APEI: Move the estatus queue code up, and under its own ifdef

2018-02-23 Thread Borislav Petkov
On Fri, Feb 23, 2018 at 06:02:21PM +, 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.

Re: [PATCH 01/11] ACPI / APEI: Move the estatus queue code up, and under its own ifdef

2018-02-23 Thread James Morse
Hi Borislav, On 20/02/18 19:28, Borislav Petkov wrote: > On Thu, Feb 15, 2018 at 06:55:56PM +, 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()

Re: [PATCH 01/11] ACPI / APEI: Move the estatus queue code up, and under its own ifdef

2018-02-20 Thread Borislav Petkov
On Thu, Feb 15, 2018 at 06:55:56PM +, 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

Re: [PATCH 01/11] ACPI / APEI: Move the estatus queue code up, and under its own ifdef

2018-02-20 Thread Punit Agrawal
Hi James, A couple of nitpicks below. James Morse 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

[PATCH 01/11] ACPI / APEI: Move the estatus queue code up, and under its own ifdef

2018-02-15 Thread 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