[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190131234740.GO6749@zn.tnic>
Date: Fri, 1 Feb 2019 00:47:40 +0100
From: Borislav Petkov <bp@...en8.de>
To: Jerry Hoemann <jerry.hoemann@....com>
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 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?
Doesn't look like it...
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.
So no, until this hasn't been done cleanly and properly explained, we'll
be in a holding pattern.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
Powered by blists - more mailing lists