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]
Date:   Tue, 9 Apr 2019 13:20:16 +0800
From:   Bhupesh Sharma <bhsharma@...hat.com>
To:     Chen Zhou <chenzhou10@...wei.com>, catalin.marinas@....com,
        will.deacon@....com, akpm@...ux-foundation.org, rppt@...ux.ibm.com,
        ard.biesheuvel@...aro.org, takahiro.akashi@...aro.org
Cc:     wangkefeng.wang@...wei.com, kexec@...ts.infradead.org,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 0/3] support reserving crashkernel above 4G on arm64 kdump

Hi Chen,

Thanks for the patchset.

Before I review the patches in detail, I have a couple of generic 
queries. Please see them in-line:

On 04/03/2019 11:05 AM, Chen Zhou wrote:
> When crashkernel is reserved above 4G in memory, kernel should reserve
> some amount of low memory for swiotlb and some DMA buffers. So there may
> be two crash kernel regions, one is below 4G, the other is above 4G.
> 
> Crash dump kernel reads more than one crash kernel regions via a dtb
> property under node /chosen,
> linux,usable-memory-range = <BASE1 SIZE1 [BASE2 SIZE2]>.
> 
> Besides, we need to modify kexec-tools:
>    arm64: support more than one crash kernel regions
> 
> Chen Zhou (3):
>    arm64: kdump: support reserving crashkernel above 4G
>    arm64: kdump: support more than one crash kernel regions
>    kdump: update Documentation about crashkernel on arm64
> 
>   Documentation/admin-guide/kernel-parameters.txt |   4 +-
>   arch/arm64/kernel/setup.c                       |   3 +
>   arch/arm64/mm/init.c                            | 108 ++++++++++++++++++++----
>   include/linux/memblock.h                        |   1 +
>   mm/memblock.c                                   |  40 +++++++++
>   5 files changed, 139 insertions(+), 17 deletions(-)

I am wondering about the use-case for the same. I remember normally 
fedora-based arm64 systems can do well with a maximum crashkernel size 
of <=512MB reserved below the 4G boundary.

So, do you mean that for your use-case (may be a huawei board based 
setup?), you need:

- more than 512MB of crashkernel size, or
- you want to split the crashkernel reservation across the 4GB boundary 
irrespective of the crashkernel size value.

Thanks,
Bhupesh

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ