From: Yinghai Lu <yinghai@kernel.org>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Jeremy Fitzhardinge <jeremy@goop.org>,
Vivek Goyal <vgoyal@redhat.com>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>
Subject: Re: [PATCH 2/4] x86, memblock: Fix crashkernel allocation
Date: Tue, 05 Oct 2010 16:05:14 -0700 [thread overview]
Message-ID: <4CABAF2A.5090501@kernel.org> (raw)
In-Reply-To: <4CABA6E5.6030601@zytor.com>
On 10/05/2010 03:29 PM, H. Peter Anvin wrote:
> On 10/04/2010 02:57 PM, Yinghai Lu wrote:
>>
>> +#define DEFAULT_BZIMAGE_ADDR_MAX 0x37FFFFFF
>> static void __init reserve_crashkernel(void)
>> {
>> unsigned long long total_mem;
>> @@ -518,17 +519,28 @@ static void __init reserve_crashkernel(v
>> if (crash_base <= 0) {
>> const unsigned long long alignment = 16<<20; /* 16M */
>>
>> - crash_base = memblock_find_in_range(alignment, ULONG_MAX, crash_size,
>> - alignment);
>> + /*
>> + * Assume half crash_size is for bzImage
>> + * kexec want bzImage is below DEFAULT_BZIMAGE_ADDR_MAX
>> + */
>> + crash_base = memblock_find_in_range(alignment,
>> + DEFAULT_BZIMAGE_ADDR_MAX + crash_size/2,
>> + crash_size, alignment);
>> +
>> if (crash_base == MEMBLOCK_ERROR) {
>> - pr_info("crashkernel reservation failed - No suitable area found.\n");
>> - return;
>> + crash_base = memblock_find_in_range(alignment,
>> + ULONG_MAX, crash_size, alignment);
>> +
>> + if (crash_base == MEMBLOCK_ERROR) {
>> + pr_info("crashkernel reservation failed - No suitable area found.\n");
>> + return;
>> + }
>> }
>>
>
> Okay, this *really* doesn't make sense.
>
> It's bad enough that kexec doesn't know what memory is safe for it, but
> why the heck the heuristic that "half is for bzImage and the rest can go
> beyond the heuristic limit"?
kdump want that range half for bzImage or half for initrd.
and kexec only check if bzImage can be put under small range.
> Can't we at least simply cap the region to
> the default, unless the kexec system has passed in some knowable
> alternative?
+ crash_base = memblock_find_in_range(alignment,
+ DEFAULT_BZIMAGE_ADDR_MAX,
+ crash_size, alignment);
Furthermore, why bother having the "fallback" at all
> (certainly without having a message!?) If we don't get the memory area
> we need we're likely to randomly fail anyway.
if kexec is fixed to work with bzImage with 64bit entry...
>
> Let me be completely clear -- it's obvious from all of this that kexec
> is fundamentally broken by design: if kexec can't communicate the safe
> memory to use it's busted seven ways to Sunday and it needs to be fixed.
> However, in the meantime I can see capping the memory available to it
> as a temporary band-aid, but a fallback to picking random memory is
> nuts, especially on the motivation that "a future kexec version might be
> able to use it." If so, the "future kexec tools" should SAY SO.
ok, please check
[PATCH -v6] x86, memblock: Fix crashkernel allocation
Cai Qian found crashkernel is broken with x86 memblock changes
1. crashkernel=128M@32M always reported that range is used, even first kernel is small
no one use that range
2. always get following report when using "kexec -p"
Could not find a free area of memory of a000 bytes...
locate_hole failed
The root cause is that generic memblock_find_in_range() will try to get range from top_down.
But crashkernel do need from low and specified range.
Let's limit the target range with crash_base + crash_size to make sure that
We get exact range.
-v6: use DEFAULT_BZIMAGE_ADDR_MAX to limit area that could be used by bzImge.
Reported-and-Bisected-by: CAI Qian <caiqian@redhat.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
---
arch/x86/kernel/setup.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
Index: linux-2.6/arch/x86/kernel/setup.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/setup.c
+++ linux-2.6/arch/x86/kernel/setup.c
@@ -501,6 +501,7 @@ static inline unsigned long long get_tot
return total << PAGE_SHIFT;
}
+#define DEFAULT_BZIMAGE_ADDR_MAX 0x37FFFFFF
static void __init reserve_crashkernel(void)
{
unsigned long long total_mem;
@@ -518,8 +519,12 @@ static void __init reserve_crashkernel(v
if (crash_base <= 0) {
const unsigned long long alignment = 16<<20; /* 16M */
- crash_base = memblock_find_in_range(alignment, ULONG_MAX, crash_size,
- alignment);
+ /*
+ * kexec want bzImage is below DEFAULT_BZIMAGE_ADDR_MAX
+ */
+ crash_base = memblock_find_in_range(alignment,
+ DEFAULT_BZIMAGE_ADDR_MAX, crash_size, alignment);
+
if (crash_base == MEMBLOCK_ERROR) {
pr_info("crashkernel reservation failed - No suitable area found.\n");
return;
@@ -527,8 +532,8 @@ static void __init reserve_crashkernel(v
} else {
unsigned long long start;
- start = memblock_find_in_range(crash_base, ULONG_MAX, crash_size,
- 1<<20);
+ start = memblock_find_in_range(crash_base,
+ crash_base + crash_size, crash_size, 1<<20);
if (start != crash_base) {
pr_info("crashkernel reservation failed - memory is in use.\n");
return;
next prev parent reply other threads:[~2010-10-05 23:06 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4CAA4BD5.4020505@kernel.org>
2010-10-04 21:57 ` [PATCH 1/4] memblock: Fix big size with find_region() Yinghai Lu
2010-10-06 6:28 ` [tip:core/memblock] memblock: Fix wraparound in find_region() tip-bot for Yinghai Lu
2010-10-04 21:57 ` [PATCH 2/4] x86, memblock: Fix crashkernel allocation Yinghai Lu
2010-10-05 21:15 ` H. Peter Anvin
2010-10-05 22:29 ` H. Peter Anvin
2010-10-05 23:05 ` Yinghai Lu [this message]
2010-10-06 6:27 ` [tip:core/memblock] " tip-bot for Yinghai Lu
2010-10-06 15:14 ` Vivek Goyal
2010-10-06 22:16 ` H. Peter Anvin
2010-10-06 22:47 ` Vivek Goyal
2010-10-06 23:06 ` Vivek Goyal
2010-10-06 23:09 ` H. Peter Anvin
2010-10-07 18:18 ` Vivek Goyal
2010-10-07 18:54 ` H. Peter Anvin
2010-10-07 19:21 ` Vivek Goyal
2010-10-07 20:44 ` H. Peter Anvin
2010-10-04 21:58 ` [PATCH 3/4] x86, memblock: Remove __memblock_x86_find_in_range_size() Yinghai Lu
2010-10-06 6:29 ` [tip:core/memblock] " tip-bot for Yinghai Lu
2010-10-04 21:58 ` [PATCH 4/4] x86, mm, memblock, 32bit: Make add_highpages honor early reserved ranges Yinghai Lu
2010-10-05 22:50 ` H. Peter Anvin
2010-10-05 23:15 ` Yinghai Lu
2010-10-06 6:28 ` [tip:core/memblock] x86-32, memblock: " tip-bot for Yinghai Lu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CABAF2A.5090501@kernel.org \
--to=yinghai@kernel.org \
--cc=benh@kernel.crashing.org \
--cc=hpa@zytor.com \
--cc=jeremy@goop.org \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--cc=vgoyal@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox