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-next>] [day] [month] [year] [list]
Date:   Fri, 20 Nov 2020 17:34:35 +0800
From:   Kairui Song <>
To:     Saeed Mirzamohammadi <>
Cc:     John Donnelly <>,,
        Dave Young <>, Baoquan He <>,
        Vivek Goyal <>,
        Jonathan Corbet <>,
        Catalin Marinas <>,
        Will Deacon <>,
        Thomas Gleixner <>,
        Ingo Molnar <>, Borislav Petkov <>,
        "the arch/x86 maintainers" <>,
        "H. Peter Anvin" <>,
        Bjorn Andersson <>,
        Shawn Guo <>, Li Yang <>,
        Vinod Koul <>, Arnd Bergmann <>,
        Anson Huang <>,
        Geert Uytterhoeven <>,
        Michael Walle <>,
        Krzysztof Kozlowski <>,
        Olof Johansson <>,
        "Martin K. Petersen" <>,
        Diego Elio Pettenò <>,
        Miguel Ojeda <>,
        Randy Dunlap <>,,,
        Linux Kernel Mailing List <>,
Subject: Re: [PATCH 1/1] kernel/crash_core.c - Add crashkernel=auto for x86
 and ARM

On Fri, Nov 20, 2020 at 4:28 AM Saeed Mirzamohammadi
<> wrote:
> Hi,
> And I think crashkernel=auto could be used as an indicator that user
> want the kernel to control the crashkernel size, so some further work
> could be done to adjust the crashkernel more accordingly. eg. when
> memory encryption is enabled, increase the crashkernel value for the
> auto estimation, as it's known to consume more crashkernel memory.
> Thanks for the suggestion! I tried to keep it simple and leave it to the user to change Kconfig in case a different range is needed. Based on experience, these ranges work well for most of the regular cases.

Yes, I think the current implementation is a very good start.

There are some use cases, where kernel is expected to reserve more memory, like:
- when memory encryption is enabled, an extra swiotlb size of memory
should be reserved
- on pcc, fadump will expect more memory to be reserved

I believe there are a lot more cases like these.
I tried to come up with some patches to let the kernel reserve more
memory automatically, when such conditions are detected, but changing
the crashkernel= specified value is really weird.

But if we have a crashkernel=auto, then kernel automatically reserve
more memory will make sense.

> But why not make it arch-independent? This crashkernel=auto idea
> should simply work with every arch.
> Thanks! I’ll be making it arch-independent in the v2 patch.
> #include <asm/page.h>
> #include <asm/sections.h>
> @@ -41,6 +42,15 @@ static int __init parse_crashkernel_mem(char *cmdline,
>                                        unsigned long long *crash_base)
> {
>        char *cur = cmdline, *tmp;
> +       unsigned long long total_mem = system_ram;
> +
> +       /*
> +        * Firmware sometimes reserves some memory regions for it's own use.
> +        * so we get less than actual system memory size.
> +        * Workaround this by round up the total size to 128M which is
> +        * enough for most test cases.
> +        */
> +       total_mem = roundup(total_mem, SZ_128M);
> I think this rounding may be better moved to the arch specified part
> where parse_crashkernel is called?
> Thanks for the suggestion. Could you please elaborate why do we need to do that?

Every arch gets their total memory value using different methods,
(just check every parse_crashkernel call, and the system_ram param is
filled in many different ways), so I'm really not sure if this
rounding is always suitable.

> Thanks,
> Saeed
Best Regards,
Kairui Song

Powered by blists - more mailing lists