linux-kernel - Re: [PATCH 1/2] kdump/x86: crashkernel=X try to reserve below 896M first then below 4G and MAXMEM

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] [day] [month] [year] [list]

Date:   Wed, 31 Oct 2018 14:16:50 +0800
From:   Pingfan Liu <kernelfans@...il.com>
To:     Dave Young <dyoung@...hat.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Baoquan He <bhe@...hat.com>, yinghai@...nel.org,
        vgoyal@...hat.com, kexec@...ts.infradead.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] kdump/x86: crashkernel=X try to reserve below 896M
 first then below 4G and MAXMEM

Hi, I encounter a case where crashkernel=384M, and kaslr is enabled.
During the test, sometimes, the system may fail to reserve region for
crash kernel, although there is much free space above 896MB. It is
caused by the truncation of the candidate region by kaslr kernel. It
raises confusion to the end user that sometimes crashkernel=X works
while sometimes fails.
So can we have this patch to fix the issue?

Thanks,
Pingfan
On Mon, May 7, 2018 at 10:49 AM Dave Young <dyoung@...hat.com> wrote:
>
> On 04/27/18 at 05:14pm, Dave Young wrote:
> > Hi,
> >
> > This is a resend of below patches:
> > http://lists.infradead.org/pipermail/kexec/2017-October/019569.html
> >
> > I dropped the original patch 1 since Baoquan is not happy with it.
> > For patch 2 (the 1st patch in this series), there is some improvement
> > comment from Baoquan to create some generic memblock iteration function.
> > But nobody has time to work on it for the time being.  According to
> > offline discussion with him.  That can be done in the future if someone
> > is interested.  We can go with the current kdump only fixes.
> >
> > Other than above,  the patches are just same.
>
> Hi Andrew, do you have concerns about the patches?  It has been used for
> long time in Red Hat kernel, since people do not object them, could you
> pick them if no other concerns?
>
> Thanks
> Dave