[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190204223016.GB11986@anatevka>
Date: Mon, 4 Feb 2019 15:30:16 -0700
From: Jerry Hoemann <jerry.hoemann@....com>
To: Borislav Petkov <bp@...en8.de>
Cc: Dave Young <dyoung@...hat.com>, x86@...nel.org,
Baoquan He <bhe@...hat.com>,
Randy Dunlap <rdunlap@...radead.org>,
kexec@...ts.infradead.org, linux-kernel@...r.kernel.org,
Pingfan Liu <kernelfans@...il.com>,
Mike Rapoport <rppt@...ux.vnet.ibm.com>,
Andrew Morton <akpm@...ux-foundation.org>, yinghai@...nel.org,
vgoyal@...hat.com
Subject: Re: [PATCHv7] x86/kdump: bugfix, make the behavior of crashkernel=X
consistent with kaslr
On Fri, Feb 01, 2019 at 12:47:40AM +0100, Borislav Petkov wrote:
> On Thu, Jan 31, 2019 at 03:27:32PM -0700, Jerry Hoemann wrote:
> > So even if a system administrator is diligent and tests
> > that a chosen kdump configuration works, that configuration
> > might not work on some random reboot 7 months in the future.
>
> Jerry, did you read the rest of the thread where I'm *actually*
> suggesting to make the allocation code more robust against such
> failures?
Boris,
I may have misunderstood your earlier comment:
So we don't really need this - we simply need to tell people to use high
if it fails with KASLR, AFAICT
To imply an iterative approach to crashkernel size discovery. Whereas you
may simply have ment: Always use ,high as the old way is broken.
> Now let's look at the code:
>
> The "high" allocation does:
>
> crash_base = memblock_find_in_range(CRASH_ALIGN,
> high ? CRASH_ADDR_HIGH_MAX
> : CRASH_ADDR_LOW_MAX,
> crash_size, CRASH_ALIGN);
>
> where high=true and CRASH_ADDR_HIGH_MAX on 64-bit is MAXMEM:
>
> # define CRASH_ADDR_HIGH_MAX MAXMEM
>
> The second fallback in the suggested patch does the same:
>
> + /*
> + * crashkernel=X reserve below 4G fails? Try MAXMEM
> + */
> + if (!high && !crash_base)
> + crash_base = memblock_find_in_range(CRASH_ALIGN,
> + CRASH_ADDR_HIGH_MAX,
> + crash_size, CRASH_ALIGN);
>
> and yet I get back that falling back to "high" if the first allocation
> doesn't succeed is not something we should do by default because of
> reasons. But this patch *practically* *does* it.
Is your objection only to the second fallback of allocating
memory above >= 4GB? Or are you objecting to allocating from
(896 .. 4GB) as well?
Falling back to allocating < 4GB probably satisfes most of the cases
where the original allocation fails.
thanks
--
-----------------------------------------------------------------------------
Jerry Hoemann Software Engineer Hewlett Packard Enterprise
-----------------------------------------------------------------------------
Powered by blists - more mailing lists