lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Tue, 24 Jan 2017 11:43:38 -0700
From:   "Baicar, Tyler" <>
To:     James Morse <>
Subject: Re: [PATCH V7 05/10] acpi: apei: handle SEA notification type for

On 1/24/2017 10:55 AM, James Morse wrote:
> 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/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
>>> There are two other things that need changing to make the in_nmi() code path
>>> work on arm64.
>>> Always reserve the virtual-address-space forcing GHES_IOREMAP_PAGES to be 2
>>> regardless of CONFIG_HAVE_ACPI_APEI_NMI. This is almost revert of
>>> 594c7255dce7a13cac50cf2470cc56e2c3b0494e (but that did a few other things too).
>> Looks simple enough, should I force it to 2 in all cases, or add a check for
>> similar to the check for CONFIG_HAVE_ACPI_APEI_NMI?
> Its just address space not actual memory it is reserving right? I think just
> reserve two pages all the time to save eye-sore #ifdefs!
Okay, will do!
>>> We also need to fix ghes_ioremap_pfn_nmi() to use arch_apei_get_mem_attribute()
>>> and not assume PAGE_KERNEL.
>> So just change the call to ioremap_page_range to:
>> ioremap_page_range(vaddr, vaddr + PAGE_SIZE, pfn << PAGE_SHIFT,
>> arch_apei_get_mem_attribute());
> (you need to give arch_apei_get_mem_attribute() the address...) copying whatever
> ghes_ioremap_pfn_irq() does a few lines down is probably best.
Sounds good, I'll make the changes in my next patchset.


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.

Powered by blists - more mailing lists