linux-kernel - Re: [PATCH] x86, kdump: crashkernel=X try to reserve below 896M first, then try below 4G, then 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20131015144810.GI31215@redhat.com>
Date:	Tue, 15 Oct 2013 10:48:10 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	WANG Chao <chaowang@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Pekka Enberg <penberg@...nel.org>,
	Jacob Shin <jacob.shin@....com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	"kexec@...ts.infradead.org" <kexec@...ts.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86, kdump: crashkernel=X try to reserve below 896M
 first, then try below 4G, then MAXMEM

On Mon, Oct 14, 2013 at 11:54:22AM -0700, Yinghai Lu wrote:
> On Mon, Oct 14, 2013 at 4:46 AM, WANG Chao <chaowang@...hat.com> wrote:
> > Now crashkernel=X will fail out if there's not enough memory at
> > low (below 896M). What makes sense for crashkernel=X would be:
> >
> >  - First try to reserve X below 896M (for being compatible with old
> >    kexec-tools).
> >  - If fails, try to reserve X below 4G (swiotlb need to stay below 4G).
> >  - If fails, try to reserve X from MAXMEM top down.
> >
> > So that user can easily reserve large memory with crashkernel=X instead
> > of crashkernel=X,high. It's more transparent and user-friendly.
> >
> > If crashkernel is large and the reserved is beyond 896M, old kexec-tools
> > won't be compatible with new kernel for most of time.
> >
> > kexec will fail out immediately in this case. But the failure could be
> > expected, because old kexec users should not try to reserve that large
> > amount of memory at the first place.
> >
> > On the other hand, old kexec also will fail on old kernel when there's
> > not enough low memory to reserve a large crash kernel area. So the
> > failure of old kexec is consistent between old kernel and new kernel.
> >
> > Signed-off-by: WANG Chao <chaowang@...hat.com>
> > ---
> >  arch/x86/kernel/setup.c | 14 ++++++++++++++
> >  1 file changed, 14 insertions(+)
> >
> > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> > index f0de629..38e6c1f 100644
> > --- a/arch/x86/kernel/setup.c
> > +++ b/arch/x86/kernel/setup.c
> > @@ -593,6 +593,20 @@ static void __init reserve_crashkernel(void)
> >                                         high ? CRASH_KERNEL_ADDR_HIGH_MAX :
> >                                                CRASH_KERNEL_ADDR_LOW_MAX,
> >                                         crash_size, alignment);
> > +               /*
> > +                * crashkernel=X reserve below 896M fails? Try below 4G
> > +                */
> > +               if (!high && !crash_base)
> > +                       crash_base = memblock_find_in_range(alignment,
> > +                                               (1ULL << 32),
> > +                                               crash_size, alignment);
> > +               /*
> > +                * crashkernel=X reserve below 4G fails? Try MAXMEM
> > +                */
> > +               if (!high && !crash_base)
> > +                       crash_base = memblock_find_in_range(alignment,
> > +                                               CRASH_KERNEL_ADDR_HIGH_MAX,
> > +                                               crash_size, alignment);
> >
> >                 if (!crash_base) {
> >                         pr_info("crashkernel reservation failed - No suitable area found.\n");
> > --
> 
> User should change crashkernel=X to crashkernel=X,high.

I think if we can extend old syntax of crashkernel=X, then it makes life
really easy for users.

> 
> As user could forget to update kexec-tools to utilize ",high" feature, and get
> kdump later fail later.

Previously high reservation (reservation above 896M) will anyway fail. So
instead of failing, if we try reservation in higher memory areas why that
would break old kexec-tools?

IOW, previously anyway kexec-tools will not work as no memory will be
reserved in higher memory area. Now memory will be reserved but old
kexec-tools should fail as it can't load in that area.

If that works, then one would use crashkernel=X,high only if he is
particualr that memory reservation comes from area above 4G (despite
the fact that same memory could have been reserved below 4G too).

Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/