linux-kernel - Re: [RFC PATCH] kdump: Add support for crashkernel=auto

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: <YgOGPbdtQIhPNen7@MiWiFi-R3L-srv>
Date:   Wed, 9 Feb 2022 17:15:41 +0800
From:   Baoquan He <bhe@...hat.com>
To:     Petr Tesařík <ptesarik@...e.cz>,
        Tiezhu Yang <yangtiezhu@...ngson.cn>
Cc:     Vivek Goyal <vgoyal@...hat.com>, Dave Young <dyoung@...hat.com>,
        Jonathan Corbet <corbet@....net>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Xuefeng Li <lixuefeng@...ngson.cn>, kexec@...ts.infradead.org,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] kdump: Add support for crashkernel=auto

Hi,

On 01/27/22 at 04:53pm, Petr Tesařík wrote:
> Hi Tiezhu Yang,
> 
> I'm afraid the whole concept is broken by design. See below.
> 
> Dne 27. 01. 22 v 10:31 Tiezhu Yang napsal(a):
> > Set the reserved memory automatically for the crash kernel based on
> > architecture.
> > 
> > Most code of this patch come from:
> > https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-8/-/tree/c8s

This code is from RHEL8/Centos8 which Redhat has been using. It's
working pretty well, except of those big box with dozens of pcie
devices, or exceptional device driver costing very much memory.
See below patchset in i40e NIC case, it eats out 1.5G meory on
ppc64le for a NIC driver init.

[PATCH v1 0/3] Reducing memory usage of i40e for kdump
https://www.spinics.net/lists/kexec/msg26521.html

I agree asking customer to estimate the needed reservation size firstly,
then adding the value to cmdline and reboot is much easier. The thing is
it needs customer to operate. And no matter how much reservation is
needed, it mostly will be satisfied, including the above crazy i40e.
You won't get report about the exception, unless user check that
carefully each time. And you can't cover the hotplugged case.

The thing is which side is in lazy mode. Customer do the
estimation and set, developer is easy. If customer want to be easy,
developer need do more.

https://sigillatum.tesarici.cz/2022-01-27-whats-wrong-with-crashkernel-auto.html

I read Petr's above article, I have some different opinion about part of
them. Crashkernel=auto is not for upstream kernel, or customized kernel,
it is for distros. For distros, the kernel config is fixed in one
release, the kernel code, data is fixed. In rhel8, crashkernel=160M
is a default value, and works on most of cases. The kernel modules are
different, we filter out the unneeded according to user's kdump config.
We only keep the needed user space tools certainly. We have document to
note user that nfs needs more memory, some big end server need more memory.
We try to reserve a little more memory propotional to the total memory.
With these effort, we hope more people can try kdump w/o worrying about
no knowledge.

About the effort trying to get crashkernel=auto into kernel, Philipp
pasted a patch from Oracle. The kernel config way is expected but
rejected by Linus. We gave up too soon. RHEL instead make it in
userspace package. We will see, we may try again if it's not going well.

> And that's the problem, I think. The solution might be good for this
> specific OS, but not for others.
> 
> > [...]
> > diff --git a/kernel/crash_core.c b/kernel/crash_core.c
> > index 256cf6d..32c51e2 100644
> > --- a/kernel/crash_core.c
> > +++ b/kernel/crash_core.c
> > @@ -252,6 +252,26 @@ static int __init __parse_crashkernel(char *cmdline,
> >   	if (suffix)
> >   		return parse_crashkernel_suffix(ck_cmdline, crash_size,
> >   				suffix);
> > +
> > +	if (strncmp(ck_cmdline, "auto", 4) == 0) {
> > +#if defined(CONFIG_X86_64) || defined(CONFIG_S390)
> > +		ck_cmdline = "1G-4G:160M,4G-64G:192M,64G-1T:256M,1T-:512M";
> > +#elif defined(CONFIG_ARM64)
> > +		ck_cmdline = "2G-:448M";
> > +#elif defined(CONFIG_PPC64)
> > +		char *fadump_cmdline;
> > +
> > +		fadump_cmdline = get_last_crashkernel(cmdline, "fadump=", NULL);
> > +		fadump_cmdline = fadump_cmdline ?
> > +				fadump_cmdline + strlen("fadump=") : NULL;
> > +		if (!fadump_cmdline || (strncmp(fadump_cmdline, "off", 3) == 0))
> > +			ck_cmdline = "2G-4G:384M,4G-16G:512M,16G-64G:1G,64G-128G:2G,128G-:4G";
> > +		else
> > +			ck_cmdline = "4G-16G:768M,16G-64G:1G,64G-128G:2G,128G-1T:4G,1T-2T:6G,2T-4T:12G,4T-8T:20G,8T-16T:36G,16T-32T:64G,32T-64T:128G,64T-:180G";
> > +#endif
> > +		pr_info("Using crashkernel=auto, the size chosen is a best effort estimation.\n");
> > +	}
> > +
> 
> How did you even arrive at the above numbers? I've done some research on
> this topic recently (ie. during the last 7 years or so). My x86_64 system
> with 8G RAM running openSUSE Leap 15.3 seems needs 188M for saving to the
> local disk, and 203M to save over the network (using SFTP). My PPC64 LPAR
> with 16G RAM running latest Beta of SLES 15 SP4 needs 587M, i.e. with the
> above numbers it may run out of memory while saving the dump.
> 
> Since this is not the first time, I'm trying to explain things, I've written
> a blog post now:
> 
> https://sigillatum.tesarici.cz/2022-01-27-whats-wrong-with-crashkernel-auto.html
> 
> HTH
> Petr Tesarik
>