linux-kernel - Re: [PATCH 1/1] kernel/crash_core.c - Add crashkernel=auto for x86 and ARM

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: <CAHD1Q_yA37wWrOscBHpSFEjFecGFcrzY6R6qU_iMESzYArV_Kg@mail.gmail.com>
Date:   Thu, 19 Nov 2020 18:56:14 -0300
From:   Guilherme Piccoli <gpiccoli@...onical.com>
To:     Saeed Mirzamohammadi <saeed.mirzamohammadi@...cle.com>
Cc:     Geert Uytterhoeven <geert+renesas@...der.be>,
        linux-doc@...r.kernel.org,
        Catalin Marinas <catalin.marinas@....com>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        "H. Peter Anvin" <hpa@...or.com>, Will Deacon <will@...nel.org>,
        Anson Huang <Anson.Huang@....com>,
        Jonathan Corbet <corbet@....net>, x86@...nel.org,
        Michael Walle <michael@...le.cc>,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Ingo Molnar <mingo@...hat.com>, Dave Young <dyoung@...hat.com>,
        Vivek Goyal <vgoyal@...hat.com>, john.p.donnelly@...cle.com,
        Arnd Bergmann <arnd@...db.de>, Borislav Petkov <bp@...en8.de>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-arm-kernel@...ts.infradead.org, Baoquan He <bhe@...hat.com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        kexec mailing list <kexec@...ts.infradead.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "# v4 . 16+" <stable@...r.kernel.org>,
        Li Yang <leoyang.li@....com>,
        Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
        Vinod Koul <vkoul@...nel.org>,
        Diego Elio Pettenò <flameeyes@...meeyes.com>,
        Olof Johansson <olof@...om.net>,
        Shawn Guo <shawnguo@...nel.org>,
        Thadeu Lima de Souza Cascardo <cascardo@...onical.com>,
        Dann Frazier <dann.frazier@...onical.com>
Subject: Re: [PATCH 1/1] kernel/crash_core.c - Add crashkernel=auto for x86
 and ARM

Hi Saeed, thanks for your patch/idea! Comments inline, below.

On Wed, Nov 18, 2020 at 8:29 PM Saeed Mirzamohammadi
<saeed.mirzamohammadi@...cle.com> wrote:
>
> This adds crashkernel=auto feature to configure reserved memory for
> vmcore creation to both x86 and ARM platforms based on the total memory
> size.
>
> Cc: stable@...r.kernel.org
> Signed-off-by: John Donnelly <john.p.donnelly@...cle.com>
> Signed-off-by: Saeed Mirzamohammadi <saeed.mirzamohammadi@...cle.com>
> ---
>  Documentation/admin-guide/kdump/kdump.rst |  5 +++++
>  arch/arm64/Kconfig                        | 26 ++++++++++++++++++++++-
>  arch/arm64/configs/defconfig              |  1 +
>  arch/x86/Kconfig                          | 26 ++++++++++++++++++++++-
>  arch/x86/configs/x86_64_defconfig         |  1 +
>  kernel/crash_core.c                       | 20 +++++++++++++++--
>  6 files changed, 75 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/admin-guide/kdump/kdump.rst b/Documentation/admin-guide/kdump/kdump.rst
> index 75a9dd98e76e..f95a2af64f59 100644
> --- a/Documentation/admin-guide/kdump/kdump.rst
> +++ b/Documentation/admin-guide/kdump/kdump.rst
> @@ -285,7 +285,12 @@ This would mean:
>      2) if the RAM size is between 512M and 2G (exclusive), then reserve 64M
>      3) if the RAM size is larger than 2G, then reserve 128M
>
> +Or you can use crashkernel=auto if you have enough memory. The threshold
> +is 1G on x86_64 and arm64. If your system memory is less than the threshold,
> +crashkernel=auto will not reserve memory. The size changes according to
> +the system memory size like below:
>
> +    x86_64/arm64: 1G-64G:128M,64G-1T:256M,1T-:512M

As mentioned in the thread, this was tried before and never got merged
- I'm not sure the all the reasons, but I speculate that a stronger
reason is that it'd likely fail in many cases. I've seen cases of 256G
servers that require crashkernel=600M (or more), due to the amount of
devices. Also, the minimum nowadays would likely be 96M or more - I'm
looping Cascardo and Dann (Debian/Ubuntu maintainers of kdump stuff)
so they maybe can jump in with even more examples/considerations.

What we've been trying to do in Ubuntu/Debian is using an estimator
approach [0] - this is purely userspace and tries to infer the amount
of necessary memory a kdump minimal[1] kernel would take. I'm not
-1'ing your approach totally, but I think a bit more consideration is
needed in the ranges, at least accounting the number of devices of the
machine or something like that.

Cheers,


Guilherme

[0] https://salsa.debian.org/debian/makedumpfile/-/merge_requests/7
[1] Minimal as having a reduced initrd + "shrinking" parameters (like
nr_cpus=1).