Re: [PATCH v2] arm64: print a fault message when attempting to write RO memory

Hi Stephen, On 17/02/17 15:53, Stephen Boyd wrote: > Quoting James Morse (2017-02-17 03:00:39) >> On 17/02/17 01:19, Stephen Boyd wrote: >>> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c >>> index 156169c6981b..8bd4e7f11c70 100644 >>> --- a/arch/a

Re: [PATCH v2] arm64: print a fault message when attempting to write RO memory

Hi Stephen, On 17/02/17 15:53, Stephen Boyd wrote: > Quoting James Morse (2017-02-17 03:00:39) >> On 17/02/17 01:19, Stephen Boyd wrote: >>> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c >>> index 156169c6981b..8bd4e7f11c70 100644 >>> --- a/arch/a

Re: [PATCH v2] arm64: print a fault message when attempting to write RO memory

Hi Stephen, On 17/02/17 01:19, Stephen Boyd wrote: > If a page is marked read only we should print out that fact, > instead of printing out that there was a page fault. Right now we > get a cryptic error message that something went wrong with an > unhandled fault, but we don't evaluate the esr to

Re: [PATCH v2] arm64: print a fault message when attempting to write RO memory

Hi Stephen, On 17/02/17 01:19, Stephen Boyd wrote: > If a page is marked read only we should print out that fact, > instead of printing out that there was a page fault. Right now we > get a cryptic error message that something went wrong with an > unhandled fault, but we don't evaluate the esr to

Re: Looking more details and reasons for using orig_add_limit.

Hi Prasad, On 15/02/17 21:12, Sodagudi Prasad wrote: > On 2017-02-15 04:09, James Morse wrote: >> On 15/02/17 05:52, Sodagudi Prasad wrote: >>> that driver is calling set_fs(KERNEL_DS) and then copy_to_user() to user >>> space >>> memory. >> >

Re: Looking more details and reasons for using orig_add_limit.

Hi Prasad, On 15/02/17 21:12, Sodagudi Prasad wrote: > On 2017-02-15 04:09, James Morse wrote: >> On 15/02/17 05:52, Sodagudi Prasad wrote: >>> that driver is calling set_fs(KERNEL_DS) and then copy_to_user() to user >>> space >>> memory. >> >

Re: [PATCH V8 06/10] acpi: apei: panic OS with fatal error status block

Hi Tyler, On 13/02/17 22:45, Baicar, Tyler wrote: > On 2/9/2017 3:48 AM, James Morse wrote: >> On 01/02/17 17:16, Tyler Baicar wrote: >>> From: "Jonathan (Zhixiong) Zhang" <zjzh...@codeaurora.org> >>> >>> Even if an error status bloc

Re: [PATCH V8 06/10] acpi: apei: panic OS with fatal error status block

Hi Tyler, On 13/02/17 22:45, Baicar, Tyler wrote: > On 2/9/2017 3:48 AM, James Morse wrote: >> On 01/02/17 17:16, Tyler Baicar wrote: >>> From: "Jonathan (Zhixiong) Zhang" >>> >>> Even if an error status block's severity is fatal, the kernel d

Re: Looking more details and reasons for using orig_add_limit.

Hi Prasad, On 15/02/17 05:52, Sodagudi Prasad wrote: > When any sys call is made from user space orig_addr_limit will be zero and > after > that driver is calling set_fs(KERNEL_DS) and then copy_to_user() to user > space > memory. Don't do this, its exactly the case PAN+UAO and the code you

Re: Looking more details and reasons for using orig_add_limit.

Hi Prasad, On 15/02/17 05:52, Sodagudi Prasad wrote: > When any sys call is made from user space orig_addr_limit will be zero and > after > that driver is calling set_fs(KERNEL_DS) and then copy_to_user() to user > space > memory. Don't do this, its exactly the case PAN+UAO and the code you

Re: [PATCH V8 06/10] acpi: apei: panic OS with fatal error status block

_estatus_cache_add(ghes->generic, ghes->estatus); > } > + if (ghes_severity(ghes->estatus->error_severity) >= GHES_SEV_PANIC) { > + __ghes_call_panic(); > + } > + I think this ghes_severity() then panic() should go above the: > if (!ghes_estatus_ca

Re: [PATCH V8 06/10] acpi: apei: panic OS with fatal error status block

gt;estatus); > } > + if (ghes_severity(ghes->estatus->error_severity) >= GHES_SEV_PANIC) { > + __ghes_call_panic(); > + } > + I think this ghes_severity() then panic() should go above the: > if (!ghes_estatus_cached(ghes->estatus)) { and we should call __ghes_print_estatus() here too, to make sure the message definitely got out! With that, Reviewed-by: James Morse Thanks, James

Re: [PATCH V8 05/10] acpi: apei: handle SEA notification type for ARMv8

Hi Tyler, On 01/02/17 17:16, Tyler Baicar wrote: > ARM APEI extension proposal added SEA (Synchronous External Abort) > notification type for ARMv8. > Add a new GHES error source handling function for SEA. If an error > source's notification type is SEA, then this function can be registered >

Re: [PATCH V8 05/10] acpi: apei: handle SEA notification type for ARMv8

Hi Tyler, On 01/02/17 17:16, Tyler Baicar wrote: > ARM APEI extension proposal added SEA (Synchronous External Abort) > notification type for ARMv8. > Add a new GHES error source handling function for SEA. If an error > source's notification type is SEA, then this function can be registered >

Re: [PATCH V8 04/10] arm64: exception: handle Synchronous External Abort

(translation table walk)" }, > + { do_sea, SIGBUS, 0, "level 0 synchronous > parity error (translation table walk)" }, > + { do_sea, SIGBUS, 0, "level 1 synchronous > parity error (translation table walk)" }, > + { do_sea, SIGBUS, 0, "level 2 synchronous > parity error (translation table walk)" }, > + { do_sea, SIGBUS, 0, "level 3 synchronous > parity error (translation table walk)" }, > { do_bad, SIGBUS, 0, "unknown 32" > }, > { do_alignment_fault, SIGBUS, BUS_ADRALN,"alignment fault" > }, > { do_bad, SIGBUS, 0, "unknown 34" > }, > With the ESR_ELx_FnV change above, Reviewed-by: James Morse <james.mo...@arm.com> Thanks, James

Re: [PATCH V8 04/10] arm64: exception: handle Synchronous External Abort

(translation table walk)" }, > + { do_sea, SIGBUS, 0, "level 0 synchronous > parity error (translation table walk)" }, > + { do_sea, SIGBUS, 0, "level 1 synchronous > parity error (translation table walk)" }, > + { do_sea, SIGBUS, 0, "level 2 synchronous > parity error (translation table walk)" }, > + { do_sea, SIGBUS, 0, "level 3 synchronous > parity error (translation table walk)" }, > { do_bad, SIGBUS, 0, "unknown 32" > }, > { do_alignment_fault, SIGBUS, BUS_ADRALN,"alignment fault" > }, > { do_bad, SIGBUS, 0, "unknown 34" > }, > With the ESR_ELx_FnV change above, Reviewed-by: James Morse Thanks, James

Re: next-20170125 hangs on aarch64

Hi Yury, [CC: Andy Gross] On 29/01/17 12:21, Yury Norov wrote: > On Sun, Jan 29, 2017 at 03:42:55PM +0530, Yury Norov wrote: >> Hi all, >> >> I pulled next-20170125 kernel, and found it hanged on boot. The exact reason >> is >> panic on dereferencing of the 0xffc8 address, which is most

Re: next-20170125 hangs on aarch64

Hi Yury, [CC: Andy Gross] On 29/01/17 12:21, Yury Norov wrote: > On Sun, Jan 29, 2017 at 03:42:55PM +0530, Yury Norov wrote: >> Hi all, >> >> I pulled next-20170125 kernel, and found it hanged on boot. The exact reason >> is >> panic on dereferencing of the 0xffc8 address, which is most

Re: [PATCH V7 05/10] acpi: apei: handle SEA notification type for ARMv8

Hi Tyler, On 20/01/17 20:58, Baicar, Tyler wrote: > On 1/19/2017 10:57 AM, James Morse wrote: >> On 18/01/17 23:51, Baicar, Tyler wrote: >>> On 1/18/2017 7:50 AM, James Morse wrote: >>>> On 12/01/17 18:15, Tyler Baicar wrote: >>>>> diff --git a/driver

Re: [PATCH V7 05/10] acpi: apei: handle SEA notification type for ARMv8

Hi Tyler, On 20/01/17 20:58, Baicar, Tyler wrote: > On 1/19/2017 10:57 AM, James Morse wrote: >> On 18/01/17 23:51, Baicar, Tyler wrote: >>> On 1/18/2017 7:50 AM, James Morse wrote: >>>> On 12/01/17 18:15, Tyler Baicar wrote: >>>>> diff --git a/driver

Re: [PATCH V7 04/10] arm64: exception: handle Synchronous External Abort

Hi Tyler, On 20/01/17 20:35, Baicar, Tyler wrote: > On 1/19/2017 10:55 AM, James Morse wrote: >> On 18/01/17 23:26, Baicar, Tyler wrote: >>> On 1/17/2017 3:31 AM, James Morse wrote: >>>> On 12/01/17 18:15, Tyler Baicar wrote: >>>>> +info.si_addr =

Re: [PATCH V7 04/10] arm64: exception: handle Synchronous External Abort

Hi Tyler, On 20/01/17 20:35, Baicar, Tyler wrote: > On 1/19/2017 10:55 AM, James Morse wrote: >> On 18/01/17 23:26, Baicar, Tyler wrote: >>> On 1/17/2017 3:31 AM, James Morse wrote: >>>> On 12/01/17 18:15, Tyler Baicar wrote: >>>>> +info.si_addr =

Re: [PATCH V7 04/10] arm64: exception: handle Synchronous External Abort

Hi Tyler, On 18/01/17 23:26, Baicar, Tyler wrote: > On 1/17/2017 3:31 AM, James Morse wrote: >> On 12/01/17 18:15, Tyler Baicar wrote: >>> SEA exceptions are often caused by an uncorrected hardware >>> error, and are handled when data abort and instruction abort

Re: [PATCH V7 04/10] arm64: exception: handle Synchronous External Abort

Hi Tyler, On 18/01/17 23:26, Baicar, Tyler wrote: > On 1/17/2017 3:31 AM, James Morse wrote: >> On 12/01/17 18:15, Tyler Baicar wrote: >>> SEA exceptions are often caused by an uncorrected hardware >>> error, and are handled when data abort and instruction abort

Re: [PATCH V7 05/10] acpi: apei: handle SEA notification type for ARMv8

Hi Tyler, On 18/01/17 23:51, Baicar, Tyler wrote: > On 1/18/2017 7:50 AM, James Morse wrote: >> On 12/01/17 18:15, Tyler Baicar wrote: >>> ARM APEI extension proposal added SEA (Synchrounous External >>> Abort) notification type for ARMv8. >>> Add a new GHES er

Re: [PATCH V7 05/10] acpi: apei: handle SEA notification type for ARMv8

Hi Tyler, On 18/01/17 23:51, Baicar, Tyler wrote: > On 1/18/2017 7:50 AM, James Morse wrote: >> On 12/01/17 18:15, Tyler Baicar wrote: >>> ARM APEI extension proposal added SEA (Synchrounous External >>> Abort) notification type for ARMv8. >>> Add a new GHES er

Re: [PATCH V7 05/10] acpi: apei: handle SEA notification type for ARMv8

Hi Tyler, On 12/01/17 18:15, Tyler Baicar wrote: > ARM APEI extension proposal added SEA (Synchrounous External Nit: Synchronous > Abort) notification type for ARMv8. > Add a new GHES error source handling function for SEA. If an error > source's notification type is SEA, then this function can

Re: [PATCH V7 05/10] acpi: apei: handle SEA notification type for ARMv8

Hi Tyler, On 12/01/17 18:15, Tyler Baicar wrote: > ARM APEI extension proposal added SEA (Synchrounous External Nit: Synchronous > Abort) notification type for ARMv8. > Add a new GHES error source handling function for SEA. If an error > source's notification type is SEA, then this function can

Re: [PATCH V7 04/10] arm64: exception: handle Synchronous External Abort

Hi Tyler, On 12/01/17 18:15, Tyler Baicar wrote: > SEA exceptions are often caused by an uncorrected hardware > error, and are handled when data abort and instruction abort > exception classes have specific values for their Fault Status > Code. > When SEA occurs, before killing the process, go

Re: [PATCH V7 04/10] arm64: exception: handle Synchronous External Abort

Hi Tyler, On 12/01/17 18:15, Tyler Baicar wrote: > SEA exceptions are often caused by an uncorrected hardware > error, and are handled when data abort and instruction abort > exception classes have specific values for their Fault Status > Code. > When SEA occurs, before killing the process, go

Re: [PATCH V7 04/10] arm64: exception: handle Synchronous External Abort

Hi Tyler, On 16/01/17 11:53, Will Deacon wrote: > On Thu, Jan 12, 2017 at 11:15:18AM -0700, Tyler Baicar wrote: >> SEA exceptions are often caused by an uncorrected hardware >> error, and are handled when data abort and instruction abort >> exception classes have specific values for their Fault

Re: [PATCH V7 04/10] arm64: exception: handle Synchronous External Abort

Hi Tyler, On 16/01/17 11:53, Will Deacon wrote: > On Thu, Jan 12, 2017 at 11:15:18AM -0700, Tyler Baicar wrote: >> SEA exceptions are often caused by an uncorrected hardware >> error, and are handled when data abort and instruction abort >> exception classes have specific values for their Fault

Re: [PATCH V6 05/10] acpi: apei: handle SEA notification type for ARMv8

Hi Tyler, On 05/01/17 22:31, Baicar, Tyler wrote: > On 12/20/2016 8:29 AM, James Morse wrote: >> On 07/12/16 21:48, Tyler Baicar wrote: >>> ARM APEI extension proposal added SEA (Synchrounous External >>> Abort) notification type for ARMv8. >>> Add a new

Re: [PATCH V6 05/10] acpi: apei: handle SEA notification type for ARMv8

Hi Tyler, On 05/01/17 22:31, Baicar, Tyler wrote: > On 12/20/2016 8:29 AM, James Morse wrote: >> On 07/12/16 21:48, Tyler Baicar wrote: >>> ARM APEI extension proposal added SEA (Synchrounous External >>> Abort) notification type for ARMv8. >>> Add a new

Re: [PATCH V6 05/10] acpi: apei: handle SEA notification type for ARMv8

Hi Tyler, On 07/12/16 21:48, Tyler Baicar wrote: > ARM APEI extension proposal added SEA (Synchrounous External > Abort) notification type for ARMv8. > Add a new GHES error source handling function for SEA. If an error > source's notification type is SEA, then this function can be registered >

Re: [PATCH V6 05/10] acpi: apei: handle SEA notification type for ARMv8

Hi Tyler, On 07/12/16 21:48, Tyler Baicar wrote: > ARM APEI extension proposal added SEA (Synchrounous External > Abort) notification type for ARMv8. > Add a new GHES error source handling function for SEA. If an error > source's notification type is SEA, then this function can be registered >

Re: [PATCH V6 03/10] efi: parse ARM processor error

r error logs. Looks good to me, a few minor comments below. Reviewed-by: James Morse <james.mo...@arm.com> > diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c > index 8fa4e23..1ac2572 100644 > --- a/drivers/firmware/efi/cper.c > +++ b/drivers/firmware/e

Re: [PATCH V6 03/10] efi: parse ARM processor error

r error logs. Looks good to me, a few minor comments below. Reviewed-by: James Morse > diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c > index 8fa4e23..1ac2572 100644 > --- a/drivers/firmware/efi/cper.c > +++ b/drivers/firmware/efi/cper.c > @@ -18

[PATCH 1/2] arm64: mm: Mark nomap regions with the PG_reserved flag

pages in the nomap regions. This gives pfn walkers the necessary hint that the page might not be accessible, allowing pfn_valid()s meaning to change slightly. Signed-off-by: James Morse <james.mo...@arm.com> --- arch/arm64/mm/init.c | 14 ++ 1 file changed, 14 insertions(+) diff

[PATCH 1/2] arm64: mm: Mark nomap regions with the PG_reserved flag

pages in the nomap regions. This gives pfn walkers the necessary hint that the page might not be accessible, allowing pfn_valid()s meaning to change slightly. Signed-off-by: James Morse --- arch/arm64/mm/init.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/arch/arm64/mm/in

[PATCH 2/2] arm64: hibernate: report nomap regions as being pfn_nosave

the memblock nomap regions to the ranges reported as being 'pfn_nosave' to the hibernate core code. This only works if all pages in the nomap region are also marked with PG_reserved. Signed-off-by: James Morse <james.mo...@arm.com> --- arch/arm64/kernel/hibernate.c | 6 +- 1 file chan

[PATCH 2/2] arm64: hibernate: report nomap regions as being pfn_nosave

the memblock nomap regions to the ranges reported as being 'pfn_nosave' to the hibernate core code. This only works if all pages in the nomap region are also marked with PG_reserved. Signed-off-by: James Morse --- arch/arm64/kernel/hibernate.c | 6 +- 1 file changed, 5 insertions(+), 1

[PATCH 0/2] Hibernate fixes for 'Fix memmap to be initialized for the entire section'

hes make hibernate's savable_page() take its escape route via 'if (PageReserved(page) && pfn_is_nosave(pfn))'. [0] https://lkml.org/lkml/2016/11/30/566 James Morse (2): arm64: mm: Mark nomap regions with the PG_reserved flag arm64: hibernate: report nomap regions as being pf

[PATCH 0/2] Hibernate fixes for 'Fix memmap to be initialized for the entire section'

hes make hibernate's savable_page() take its escape route via 'if (PageReserved(page) && pfn_is_nosave(pfn))'. [0] https://lkml.org/lkml/2016/11/30/566 James Morse (2): arm64: mm: Mark nomap regions with the PG_reserved flag arm64: hibernate: report nomap regions as being pf

Re: [PATCH v2] arm64: mm: Fix memmap to be initialized for the entire section

Hi Robert, On 02/12/16 07:11, Robert Richter wrote: > On 01.12.16 17:26:55, James Morse wrote: >> On 01/12/16 16:45, Will Deacon wrote: >>> Thanks for sending out the new patch. Whilst I'm still a bit worried about >>> changing pfn_valid like this, I guess we'll just

Re: [PATCH v2] arm64: mm: Fix memmap to be initialized for the entire section

Hi Robert, On 02/12/16 07:11, Robert Richter wrote: > On 01.12.16 17:26:55, James Morse wrote: >> On 01/12/16 16:45, Will Deacon wrote: >>> Thanks for sending out the new patch. Whilst I'm still a bit worried about >>> changing pfn_valid like this, I guess we'll just

Re: [PATCH v2] arm64: mm: Fix memmap to be initialized for the entire section

Hi Robert, Will, On 01/12/16 16:45, Will Deacon wrote: > On Wed, Nov 30, 2016 at 07:21:31PM +0100, Robert Richter wrote: >> On ThunderX systems with certain memory configurations we see the >> following BUG_ON(): >> >> kernel BUG at mm/page_alloc.c:1848! >> >> This happens for some configs with

Re: [PATCH v2] arm64: mm: Fix memmap to be initialized for the entire section

Hi Robert, Will, On 01/12/16 16:45, Will Deacon wrote: > On Wed, Nov 30, 2016 at 07:21:31PM +0100, Robert Richter wrote: >> On ThunderX systems with certain memory configurations we see the >> following BUG_ON(): >> >> kernel BUG at mm/page_alloc.c:1848! >> >> This happens for some configs with

Re: [PATCHv4 05/10] arm64: Use __pa_symbol for kernel symbols

-%< I can post it as a separate fixes patch if you prefer. I also tested kexec. FWIW: Tested-by: James Morse <james.mo...@arm.com> Thanks, James [0] Trace [4.191607] Freezing user space processes ... (elapsed 0.000 seconds) done. [4.224251] r

Re: [PATCHv4 05/10] arm64: Use __pa_symbol for kernel symbols

-%< I can post it as a separate fixes patch if you prefer. I also tested kexec. FWIW: Tested-by: James Morse Thanks, James [0] Trace [4.191607] Freezing user space processes ... (elapsed 0.000 seconds) done. [4.224251] random: fast init done [4.2438

Re: [PATCH V5 03/10] efi: parse ARMv8 processor error

Hi Tyler, On 21/11/16 22:35, Tyler Baicar wrote: > Add support for ARMv8 Common Platform Error Record (CPER). > UEFI 2.6 specification adds support for ARMv8 specific > processor error information to be reported as part of the > CPER records. This provides more detail on for processor error logs.

Re: [PATCH V5 03/10] efi: parse ARMv8 processor error

Hi Tyler, On 21/11/16 22:35, Tyler Baicar wrote: > Add support for ARMv8 Common Platform Error Record (CPER). > UEFI 2.6 specification adds support for ARMv8 specific > processor error information to be reported as part of the > CPER records. This provides more detail on for processor error logs.

Re: [PATCH V5 02/10] ras: acpi/apei: cper: generic error data entry v3 per ACPI 6.1

st_generic_data_v300 *)(gdata)) + 1) : > + gdata + 1; > +} > diff --git a/include/linux/cper.h b/include/linux/cper.h > index dcacb1a..13ea41c 100644 > --- a/include/linux/cper.h > +++ b/include/linux/cper.h > @@ -255,6 +255,18 @@ enum { > > #define CPER_PCIE_SLOT_SHIFT 3 > > +#define acpi_hest_generic_data_error_length(gdata) \ > + (((struct acpi_hest_generic_data *)(gdata))->error_data_length) > +#define acpi_hest_generic_data_size(gdata) \ > + ((acpi_hest_generic_data_version(gdata) >= 3) ? \ > + sizeof(struct acpi_hest_generic_data_v300) :\ > + sizeof(struct acpi_hest_generic_data)) > +#define acpi_hest_generic_data_record_size(gdata)\ > + (acpi_hest_generic_data_size(gdata) + \ > + acpi_hest_generic_data_error_length(gdata)) > +#define acpi_hest_generic_data_next(gdata) \ > + ((void *)(gdata) + acpi_hest_generic_data_record_size(gdata)) > + How come these aren't in ghes.h? Reviewed-by: James Morse <james.mo...@arm.com> Thanks, James

Re: [PATCH V5 02/10] ras: acpi/apei: cper: generic error data entry v3 per ACPI 6.1

st_generic_data_v300 *)(gdata)) + 1) : > + gdata + 1; > +} > diff --git a/include/linux/cper.h b/include/linux/cper.h > index dcacb1a..13ea41c 100644 > --- a/include/linux/cper.h > +++ b/include/linux/cper.h > @@ -255,6 +255,18 @@ enum { > > #define CPER_PCIE_SLOT_SHIFT 3 > > +#define acpi_hest_generic_data_error_length(gdata) \ > + (((struct acpi_hest_generic_data *)(gdata))->error_data_length) > +#define acpi_hest_generic_data_size(gdata) \ > + ((acpi_hest_generic_data_version(gdata) >= 3) ? \ > + sizeof(struct acpi_hest_generic_data_v300) :\ > + sizeof(struct acpi_hest_generic_data)) > +#define acpi_hest_generic_data_record_size(gdata)\ > + (acpi_hest_generic_data_size(gdata) + \ > + acpi_hest_generic_data_error_length(gdata)) > +#define acpi_hest_generic_data_next(gdata) \ > + ((void *)(gdata) + acpi_hest_generic_data_record_size(gdata)) > + How come these aren't in ghes.h? Reviewed-by: James Morse Thanks, James

Re: [PATCH V5 01/10] acpi: apei: read ack upon ghes record consumption

PI_HEST_TYPE_GENERIC_ERROR && > + hest_hdr->type != ACPI_HEST_TYPE_GENERIC_ERROR_V2) > return 0; > > if (!((struct acpi_hest_generic *)hest_hdr)->enabled) > diff --git a/include/acpi/ghes.h b/include/acpi/ghes.h > index 720446c..68f088a 100644 > --- a/include/acpi/ghes.h > +++ b/include/acpi/ghes.h > @@ -13,7 +13,10 @@ > #define GHES_EXITING 0x0002 > > struct ghes { > - struct acpi_hest_generic *generic; > + union { > + struct acpi_hest_generic *generic; > + struct acpi_hest_generic_v2 *generic_v2; > + }; > struct acpi_hest_generic_status *estatus; > u64 buffer_paddr; > unsigned long flags; > Looks good to me, for what its worth: Reviewed-by: James Morse <james.mo...@arm.com> Thanks, James

Re: [PATCH V5 01/10] acpi: apei: read ack upon ghes record consumption

return 0; > > if (!((struct acpi_hest_generic *)hest_hdr)->enabled) > diff --git a/include/acpi/ghes.h b/include/acpi/ghes.h > index 720446c..68f088a 100644 > --- a/include/acpi/ghes.h > +++ b/include/acpi/ghes.h > @@ -13,7 +13,10 @@ > #define GHES_EXITING 0x0002 > > struct ghes { > - struct acpi_hest_generic *generic; > + union { > + struct acpi_hest_generic *generic; > + struct acpi_hest_generic_v2 *generic_v2; > + }; > struct acpi_hest_generic_status *estatus; > u64 buffer_paddr; > unsigned long flags; > Looks good to me, for what its worth: Reviewed-by: James Morse Thanks, James

[tip:irq/urgent] irqchip/gicv3: Silence noisy DEBUG_PER_CPU_MAPS warning

Commit-ID: 727653d6ce7103b245eb8041f55dd5885f4c3289 Gitweb: http://git.kernel.org/tip/727653d6ce7103b245eb8041f55dd5885f4c3289 Author: James Morse <james.mo...@arm.com> AuthorDate: Mon, 19 Sep 2016 18:29:15 +0100 Committer: Thomas Gleixner <t...@linutronix.de> CommitDate:

[tip:irq/urgent] irqchip/gicv3: Silence noisy DEBUG_PER_CPU_MAPS warning

Commit-ID: 727653d6ce7103b245eb8041f55dd5885f4c3289 Gitweb: http://git.kernel.org/tip/727653d6ce7103b245eb8041f55dd5885f4c3289 Author: James Morse AuthorDate: Mon, 19 Sep 2016 18:29:15 +0100 Committer: Thomas Gleixner CommitDate: Tue, 20 Sep 2016 01:43:23 +0200 irqchip/gicv3: Silence

[tip:irq/urgent] irqchip/gicv3: Silence noisy DEBUG_PER_CPU_MAPS warning

Commit-ID: 7e947926fc3bfa095644c2933ec209128cbfd61e Gitweb: http://git.kernel.org/tip/7e947926fc3bfa095644c2933ec209128cbfd61e Author: James Morse <james.mo...@arm.com> AuthorDate: Mon, 19 Sep 2016 18:29:15 +0100 Committer: Thomas Gleixner <t...@linutronix.de> CommitDate:

[tip:irq/urgent] irqchip/gicv3: Silence noisy DEBUG_PER_CPU_MAPS warning

Commit-ID: 7e947926fc3bfa095644c2933ec209128cbfd61e Gitweb: http://git.kernel.org/tip/7e947926fc3bfa095644c2933ec209128cbfd61e Author: James Morse AuthorDate: Mon, 19 Sep 2016 18:29:15 +0100 Committer: Thomas Gleixner CommitDate: Mon, 19 Sep 2016 21:07:12 +0200 irqchip/gicv3: Silence

Re: [RFC] Arm64 boot fail with numa enable in BIOS

On 19/09/16 15:07, Mark Rutland wrote: > On Mon, Sep 19, 2016 at 09:05:26PM +0800, Yisheng Xie wrote: >> For the crash log, it seems caused by error number of cpumask. >> Any ideas about it? > Much earlier in your log, there was a (non-fatal) warning, as below. Do > you see this without NUMA/SRAT

Re: [RFC] Arm64 boot fail with numa enable in BIOS

On 19/09/16 15:07, Mark Rutland wrote: > On Mon, Sep 19, 2016 at 09:05:26PM +0800, Yisheng Xie wrote: >> For the crash log, it seems caused by error number of cpumask. >> Any ideas about it? > Much earlier in your log, there was a (non-fatal) warning, as below. Do > you see this without NUMA/SRAT

[PATCH] irqchip/gicv3: silence noisy DEBUG_PER_CPU_MAPS warning

return early as start >= nbits), this patch just silences the warning. Signed-off-by: James Morse <james.mo...@arm.com> --- drivers/irqchip/irq-gic-v3.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c ind

[PATCH] irqchip/gicv3: silence noisy DEBUG_PER_CPU_MAPS warning

return early as start >= nbits), this patch just silences the warning. Signed-off-by: James Morse --- drivers/irqchip/irq-gic-v3.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c index ede5672ab34d..9e37c447cc

Re: [PATCH v5 0/3] arm64: hibernate: Resume when hibernate image created on non-boot CPU

Hi Rafael, On 14/09/16 02:07, Rafael J. Wysocki wrote: > What's the status of this? Will has queued it in his for-next/core branch. Thanks, James

Re: [PATCH v5 0/3] arm64: hibernate: Resume when hibernate image created on non-boot CPU

Hi Rafael, On 14/09/16 02:07, Rafael J. Wysocki wrote: > What's the status of this? Will has queued it in his for-next/core branch. Thanks, James

Re: [PATCH v3 2/3] hwmon: xgene: Add hwmon driver

Hi, On 09/09/16 04:18, AKASHI Takahiro wrote: > On Thu, Sep 08, 2016 at 11:47:59AM +0100, James Morse wrote: >> On 08/09/16 09:14, Arnd Bergmann wrote: >>> On Wednesday, September 7, 2016 3:37:05 PM CEST Guenter Roeck wrote: >>>> On Wed, Sep 07, 2016 at 11:41:4

Re: [PATCH v3 2/3] hwmon: xgene: Add hwmon driver

Hi, On 09/09/16 04:18, AKASHI Takahiro wrote: > On Thu, Sep 08, 2016 at 11:47:59AM +0100, James Morse wrote: >> On 08/09/16 09:14, Arnd Bergmann wrote: >>> On Wednesday, September 7, 2016 3:37:05 PM CEST Guenter Roeck wrote: >>>> On Wed, Sep 07, 2016 at 11:41:4

Re: [PATCH v3 2/3] hwmon: xgene: Add hwmon driver

Hi, On 08/09/16 09:14, Arnd Bergmann wrote: > On Wednesday, September 7, 2016 3:37:05 PM CEST Guenter Roeck wrote: >> On Wed, Sep 07, 2016 at 11:41:44PM +0200, Arnd Bergmann wrote: >>> On Thursday, July 21, 2016 1:55:56 PM CEST Hoan Tran wrote: + ctx->comm_base_addr =

Re: [PATCH v3 2/3] hwmon: xgene: Add hwmon driver

Hi, On 08/09/16 09:14, Arnd Bergmann wrote: > On Wednesday, September 7, 2016 3:37:05 PM CEST Guenter Roeck wrote: >> On Wed, Sep 07, 2016 at 11:41:44PM +0200, Arnd Bergmann wrote: >>> On Thursday, July 21, 2016 1:55:56 PM CEST Hoan Tran wrote: + ctx->comm_base_addr =

[PATCH v5 3/3] Revert "arm64: hibernate: Refuse to hibernate if the boot cpu is offline"

-by: James Morse <james.mo...@arm.com> Acked-by: Catalin Marinas <catalin.mari...@arm.com> --- This patch should be merged via the same tree as patch 1. arch/arm64/kernel/hibernate.c | 26 -- 1 file changed, 26 deletions(-) diff --git a/arch/arm64/kernel/hibern

[PATCH v5 3/3] Revert "arm64: hibernate: Refuse to hibernate if the boot cpu is offline"

-by: James Morse Acked-by: Catalin Marinas --- This patch should be merged via the same tree as patch 1. arch/arm64/kernel/hibernate.c | 26 -- 1 file changed, 26 deletions(-) diff --git a/arch/arm64/kernel/hibernate.c b/arch/arm64/kernel/hibernate.c index 9fcf2fcda876

[PATCH v5 0/3] arm64: hibernate: Resume when hibernate image created on non-boot CPU

PM: noirq restore of devices complete after 1.434 msecs [ 80.880381] PM: early restore of devices complete after 0.701 msecs [ 81.231471] PM: restore of devices complete after 71.157 msecs [ 81.238336] Restarting tasks ... done. root@ubuntu:~# -%<----

[PATCH v5 1/3] cpu/hotplug: Allow suspend/resume CPU to be specified

CPU is not online. Add disable_nonboot_cpus() as an inline function that has the existing behaviour. Signed-off-by: James Morse <james.mo...@arm.com> Cc: Rafael J. Wysocki <r...@rjwysocki.net> --- An alternative is to provide two functions calling a common function, but this would m

[PATCH v5 2/3] arm64: hibernate: Resume when hibernate image created on non-boot CPU

, use hibernate_resume_nonboot_cpu_disable() to direct which CPU we should resume on based on the MPIDR of the CPU we hibernated on. This allows us to hibernate/resume on any CPU, even if the logical numbers have been shuffled by kexec. Signed-off-by: James Morse <james.mo...@arm.com> Cc: Mark R

[PATCH v5 1/3] cpu/hotplug: Allow suspend/resume CPU to be specified

CPU is not online. Add disable_nonboot_cpus() as an inline function that has the existing behaviour. Signed-off-by: James Morse Cc: Rafael J. Wysocki --- An alternative is to provide two functions calling a common function, but this would mean spilling the cpu_maps_update_begin() into these two

[PATCH v5 2/3] arm64: hibernate: Resume when hibernate image created on non-boot CPU

, use hibernate_resume_nonboot_cpu_disable() to direct which CPU we should resume on based on the MPIDR of the CPU we hibernated on. This allows us to hibernate/resume on any CPU, even if the logical numbers have been shuffled by kexec. Signed-off-by: James Morse Cc: Mark Rutland Cc: Lorenzo

[PATCH v5 0/3] arm64: hibernate: Resume when hibernate image created on non-boot CPU

PM: noirq restore of devices complete after 1.434 msecs [ 80.880381] PM: early restore of devices complete after 0.701 msecs [ 81.231471] PM: restore of devices complete after 71.157 msecs [ 81.238336] Restarting tasks ... done. root@ubuntu:~# -%<----

Re: [PATCH 6/8] arm64: Introduce raw_{d,i}cache_line_size

_exit) > > add x1, x10, #PAGE_SIZE > /* Clean the copied page to PoU - based on flush_icache_range() */ > - dcache_line_size x2, x3 > + raw_dcache_line_size x2, x3 > sub x3, x2, #1 > bic x4, x10, x3 > 2: dc cvau, x4/* clean D line / unified line */ Looks like no-change to me! If you think you need it: Acked-by: James Morse <james.mo...@arm.com> Thanks, James

Re: [PATCH 6/8] arm64: Introduce raw_{d,i}cache_line_size

_exit) > > add x1, x10, #PAGE_SIZE > /* Clean the copied page to PoU - based on flush_icache_range() */ > - dcache_line_size x2, x3 > + raw_dcache_line_size x2, x3 > sub x3, x2, #1 > bic x4, x10, x3 > 2: dc cvau, x4/* clean D line / unified line */ Looks like no-change to me! If you think you need it: Acked-by: James Morse Thanks, James

Re: [PATCH][RFC v3] x86, hotplug: Use hlt instead of mwait if invoked from disable_nonboot_cpus

Hi, On 07/07/16 03:50, Chen, Yu C wrote: >> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] >> Below is my sort of version of this (untested) and I did it this way, >> because the >> issue is specific to resume from hibernation (the workaround need not be >> applied anywhere else) and the

Re: [PATCH][RFC v3] x86, hotplug: Use hlt instead of mwait if invoked from disable_nonboot_cpus

Hi, On 07/07/16 03:50, Chen, Yu C wrote: >> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net] >> Below is my sort of version of this (untested) and I did it this way, >> because the >> issue is specific to resume from hibernation (the workaround need not be >> applied anywhere else) and the

Re: [PATCH][RFC v3] x86, hotplug: Use hlt instead of mwait if invoked from disable_nonboot_cpus

Hi Rafael, On 07/07/16 01:33, Rafael J. Wysocki wrote: > Below is my sort of version of this (untested) and I did it this way, because > the issue is specific to resume from hibernation (the workaround need not be > applied anywhere else) and the hibernate_resume_nonboot_cpu_disable() thing >

Re: [PATCH][RFC v3] x86, hotplug: Use hlt instead of mwait if invoked from disable_nonboot_cpus

Hi Rafael, On 07/07/16 01:33, Rafael J. Wysocki wrote: > Below is my sort of version of this (untested) and I did it this way, because > the issue is specific to resume from hibernation (the workaround need not be > applied anywhere else) and the hibernate_resume_nonboot_cpu_disable() thing >

Re: [PATCH v2] arm64: allow building with kcov coverage on ARM64

On 16/06/16 17:36, Alexander Potapenko wrote: > On Thu, Jun 16, 2016 at 6:32 PM, Mark Rutland wrote: >> On Thu, Jun 16, 2016 at 05:25:31PM +0100, Catalin Marinas wrote: >>> I noticed that there was an ack on v1 form Marc Z that's missing in v2. >> >> I believe Marc's reply

Re: [PATCH v2] arm64: allow building with kcov coverage on ARM64

On 16/06/16 17:36, Alexander Potapenko wrote: > On Thu, Jun 16, 2016 at 6:32 PM, Mark Rutland wrote: >> On Thu, Jun 16, 2016 at 05:25:31PM +0100, Catalin Marinas wrote: >>> I noticed that there was an ack on v1 form Marc Z that's missing in v2. >> >> I believe Marc's reply [1] was to v3 [2], it's

Re: [PATCH v2] arm64: allow building with kcov coverage on ARM64

g. >>> >>> Any ideas? >> According to Dmitry (thanks, Dmitry!) this has regressed recently, but >> there's a pending patch that should probably fix the problem: >> http://lkml.iu.edu/hypermail/linux/kernel/1605.2/04379.html > > Thanks for the pointer

Re: [PATCH v2] arm64: allow building with kcov coverage on ARM64

According to Dmitry (thanks, Dmitry!) this has regressed recently, but >> there's a pending patch that should probably fix the problem: >> http://lkml.iu.edu/hypermail/linux/kernel/1605.2/04379.html > > Thanks for the pointer! With that applied, the program runs. > > However, it looks like I missed a warning from the kernel build system, > and my toolchain doesn't actually support -fsanitize-coverage=trace-pc, > so I'm not going to be able to test that further. I dusted off a compiler that supports this, and ran the sample program under Documentation with the above unproxify patch. Tested-by: James Morse Thanks, James

Re: [PATCHv2] kcov: reject open when kernel not instrumented

Hi Mark, On 15/06/16 18:04, Mark Rutland wrote: > If the toolchain does not support -fsanitize-coverage=trace-pc, we blat > this option from CFLAGS_KCOV, and build the kernel without > instrumentation, even if CONFIG_KCOV was selected. However, we still > build the rest of the kcov

Re: [PATCHv2] kcov: reject open when kernel not instrumented

Hi Mark, On 15/06/16 18:04, Mark Rutland wrote: > If the toolchain does not support -fsanitize-coverage=trace-pc, we blat > this option from CFLAGS_KCOV, and build the kernel without > instrumentation, even if CONFIG_KCOV was selected. However, we still > build the rest of the kcov

Re: [PATCH v12 05/10] arm64: Kprobes with single stepping support

Hi David, Sandeepa, On 27/04/16 19:53, David Long wrote: > From: Sandeepa Prabhu > diff --git a/arch/arm64/kernel/kprobes.c b/arch/arm64/kernel/kprobes.c > new file mode 100644 > index 000..dfa1b1f > --- /dev/null > +++ b/arch/arm64/kernel/kprobes.c > @@ -0,0

Re: [PATCH v12 05/10] arm64: Kprobes with single stepping support

Hi David, Sandeepa, On 27/04/16 19:53, David Long wrote: > From: Sandeepa Prabhu > diff --git a/arch/arm64/kernel/kprobes.c b/arch/arm64/kernel/kprobes.c > new file mode 100644 > index 000..dfa1b1f > --- /dev/null > +++ b/arch/arm64/kernel/kprobes.c > @@ -0,0 +1,520 @@ > +/* > + *

Re: [PATCH v12 06/10] arm64: Treat all entry code as non-kprobe-able

Hi David, Pratyush On 27/04/16 19:53, David Long wrote: > From: Pratyush Anand > > Entry symbols are not kprobe safe. So blacklist them for kprobing. > > Signed-off-by: Pratyush Anand > diff --git a/arch/arm64/kernel/kprobes.c

Re: [PATCH v12 06/10] arm64: Treat all entry code as non-kprobe-able

Hi David, Pratyush On 27/04/16 19:53, David Long wrote: > From: Pratyush Anand > > Entry symbols are not kprobe safe. So blacklist them for kprobing. > > Signed-off-by: Pratyush Anand > diff --git a/arch/arm64/kernel/kprobes.c b/arch/arm64/kernel/kprobes.c > index dfa1b1f..6a1292b 100644 >

Re: [PATCH v12 00/10] arm64: Add kernel probes (kprobes) support

Hi David, On 27/04/16 19:52, David Long wrote: > From: "David A. Long" > > This patchset is heavily based on Sandeepa Prabhu's ARM v8 kprobes patches, > first seen in October 2013. This version attempts to address concerns raised > by > reviewers and also fixes problems

Re: [PATCH v12 00/10] arm64: Add kernel probes (kprobes) support

Hi David, On 27/04/16 19:52, David Long wrote: > From: "David A. Long" > > This patchset is heavily based on Sandeepa Prabhu's ARM v8 kprobes patches, > first seen in October 2013. This version attempts to address concerns raised > by > reviewers and also fixes problems discovered during

[PATCH] kcov: Don't trace the code coverage code

that ftrace won't try to patch this code. Signed-off-by: James Morse <james.mo...@arm.com> --- This patch lets arm64 with KCOV and STACK_TRACER boot. kernel/kcov.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/kcov.c b/kernel/kcov.c index 3efbee0834a8..78bed7125515

[PATCH] kcov: Don't trace the code coverage code

that ftrace won't try to patch this code. Signed-off-by: James Morse --- This patch lets arm64 with KCOV and STACK_TRACER boot. kernel/kcov.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/kcov.c b/kernel/kcov.c index 3efbee0834a8..78bed7125515 100644 --- a/kernel/kcov.c

Re: [PATCH v1] arm64: allow building with kcov coverage on ARM64

Hi Alex, On 12/04/16 12:17, Alexander Potapenko wrote: > I also wonder if we can, say, land the change to arch/arm64/Kconfig > separately from makefile changes that improve the precision or fix > certain build configurations. (I'm not sure what you mean by precision) It depends which build

Re: [PATCH v1] arm64: allow building with kcov coverage on ARM64

Hi Alex, On 12/04/16 12:17, Alexander Potapenko wrote: > I also wonder if we can, say, land the change to arch/arm64/Kconfig > separately from makefile changes that improve the precision or fix > certain build configurations. (I'm not sure what you mean by precision) It depends which build

<    5   6   7   8   9   10   11   >