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] [thread-next>] [day] [month] [year] [list]
Message-ID: <463c284b-115e-0784-ca07-a430127e6176@redhat.com>
Date:   Tue, 27 Nov 2018 10:58:38 +0800
From:   lijiang <lijiang@...hat.com>
To:     Dave Hansen <dave.hansen@...el.com>, linux-kernel@...r.kernel.org
Cc:     kexec@...ts.infradead.org, x86@...nel.org,
        linux-ia64@...r.kernel.org, linux-efi@...r.kernel.org,
        tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
        akpm@...ux-foundation.org, dave.hansen@...ux.intel.com,
        luto@...nel.org, peterz@...radead.org, ard.biesheuvel@...aro.org,
        tony.luck@...el.com, fenghua.yu@...el.com, dyoung@...hat.com,
        bhe@...hat.com
Subject: Re: [PATCH 0/2 RESEND v7] add reserved e820 ranges to the kdump
 kernel e820 table

在 2018年11月27日 02:54, Dave Hansen 写道:
> On 11/23/18 9:12 PM, Lianbo Jiang wrote:
>> These patches add the new I/O resource descriptor 'IORES_DESC_RESERVED'
>> for the iomem resources search interfaces, and in order to make it still
>> work after the new descriptor is added, these codes originally related
>> to 'IORES_DESC_NONE' have been updated.
> 
> This is rather anemic "0/" text.  Could you please include some more
> background in here?  The 2/2 patch is pretty good in this regard, but it
> needs to be here, too.
> 

Thanks for your comment. 

Originally, this patch added the e820 reserved ranges by accurately comparing
a string. It only modifies fewer code paths. Please refer to patch v6.
https://lore.kernel.org/lkml/20181114072926.13312-2-lijiang@redhat.com/

Because the string comparison is fragile and error-prone, this patch used the
solution that adds a new descriptor 'IORES_DESC_RESERVED'. Please refer to this
link: https://lore.kernel.org/lkml/20181120192935.GK2527@zn.tnic/

When passing the e820 reserved ranges to the second kernel, why does it need to
compare strings accurately or add a new descriptor 'IORES_DESC_RESERVED'?

-The reason is that it can not exactly match the e820 reserved resource ranges
when walking through iomem resources with the descriptor 'IORES_DESC_NONE'.

Thanks.
Lianbo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ