lists.openwall.net   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  linux-cve-announce  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]
Message-ID: <53b582bd-e30a-848a-dfcd-e79e51296598@redhat.com>
Date:   Tue, 16 Oct 2018 11:45:06 +0800
From:   lijiang <lijiang@...hat.com>
To:     Dave Young <dyoung@...hat.com>
Cc:     linux-kernel@...r.kernel.org, kexec@...ts.infradead.org,
        tglx@...utronix.de, mingo@...hat.com, hpa@...or.com,
        x86@...nel.org, akpm@...ux-foundation.org,
        dan.j.williams@...el.com, thomas.lendacky@....com,
        bhelgaas@...gle.com, baiyaowei@...s.chinamobile.com, tiwai@...e.de,
        bp@...e.de, brijesh.singh@....com, bhe@...hat.com
Subject: Re: [PATCH 0/3 v3] add reserved e820 ranges to the kdump kernel e820
 table

在 2018年10月16日 10:56, Dave Young 写道:
> On 09/21/18 at 03:32pm, Lianbo Jiang wrote:
>> E820 reserved ranges is useful in kdump kernel, we have added this in
>> kexec-tools code.
>>
>> One reason is PCI mmconf (extended mode) requires reserved region otherwise
>> it falls back to legacy mode.
>>
>> Furthermore, when AMD SME kdump support, it needs to map dmi table area as
>> unencrypted. For normal boot, these ranges sit in e820 reserved ranges,
>> thus the early ioremap code naturally map them as unencrypted. If we also
>> have same e820 reserve setup in kdump kernel then it will just work like
>> normal kernel.
>>
>> Kdump uses walk_iomem_res_desc to iterate resources, then adds matched desc
>> to e820 table for the kdump kernel.
>>
>> But IORES_DESC_NONE resource type includes several different e820 types, we
>> need add exact e820 type to the kdump kernel e820 table, thus it also needs
>> an extra checking in memmap_entry_callback() to match the e820 type and
>> resource name.
>>
>> By the way, we also fix an error which walks through iomem resources, the
>> values of the function parameter may be modified in the while loop of
>> __walk_iomem_res_desc(), which will cause us to not get the desired result
>> in some cases.
>>
>> Changes since v2:
>> 1. Modified the value of flags to "0", when walking through the whole
>> tree for e820 reserved ranges.
>> 2. Modified the invalid SOB chain issue.
>>
>> Lianbo Jiang (3):
>>   resource: fix an error which walks through iomem resources
>>   x86/kexec_file: add e820 entry in case e820 type string matches to io
>>     resource name
>>   x86/kexec_file: add reserved e820 ranges to kdump kernel e820 table
> 
> Lianbo, since Bjorn has fixed the resource issue in another patchset,
> can you rebase your patch 2 and 3 on top of his patches and resend?
> 
Ok, Thanks for your reminder.
I will adjust these patches and post again.

Thanks.
Lianbo
>>
>>  arch/x86/include/asm/e820/api.h |  2 ++
>>  arch/x86/kernel/crash.c         | 11 ++++++++++-
>>  arch/x86/kernel/e820.c          |  2 +-
>>  kernel/resource.c               |  3 +++
>>  4 files changed, 16 insertions(+), 2 deletions(-)
>>
>> -- 
>> 2.17.1
>>
> 
> Thanks
> Dave
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ