2016-12-15 03:30:39

by Xunlei Pang

[permalink] [raw]
Subject: [PATCH] x86/crash: Update the stale comment in reserve_crashkernel()

CRASH_KERNEL_ADDR_MAX was missing for a long time, update it
with more detailed explanation.

Cc: Robert LeBlanc <[email protected]>
Cc: Baoquan He <[email protected]>
Signed-off-by: Xunlei Pang <[email protected]>
---
arch/x86/kernel/setup.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 9c337b0..79ee507 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -575,7 +575,10 @@ static void __init reserve_crashkernel(void)
/* 0 means: find the address automatically */
if (crash_base <= 0) {
/*
- * kexec want bzImage is below CRASH_KERNEL_ADDR_MAX
+ * Set CRASH_ADDR_LOW_MAX upper bound for crash range
+ * as old kexec-tools loads bzImage below that, unless
+ * "size,high" or "size@offset"(nonzero offset, see the
+ * else leg below) is specified.
*/
crash_base = memblock_find_in_range(CRASH_ALIGN,
high ? CRASH_ADDR_HIGH_MAX
--
1.8.3.1


2016-12-22 03:22:39

by Baoquan He

[permalink] [raw]
Subject: Re: [PATCH] x86/crash: Update the stale comment in reserve_crashkernel()

On 12/15/16 at 11:30am, Xunlei Pang wrote:
> CRASH_KERNEL_ADDR_MAX was missing for a long time, update it
> with more detailed explanation.
>
> Cc: Robert LeBlanc <[email protected]>
> Cc: Baoquan He <[email protected]>
> Signed-off-by: Xunlei Pang <[email protected]>
> ---
> arch/x86/kernel/setup.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 9c337b0..79ee507 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -575,7 +575,10 @@ static void __init reserve_crashkernel(void)
> /* 0 means: find the address automatically */
> if (crash_base <= 0) {
> /*
> - * kexec want bzImage is below CRASH_KERNEL_ADDR_MAX
> + * Set CRASH_ADDR_LOW_MAX upper bound for crash range
> + * as old kexec-tools loads bzImage below that, unless
> + * "size,high" or "size@offset"(nonzero offset, see the
> + * else leg below) is specified.

Yes, this is a good catch. It might be better to add comment only about
this if branch. If you want to say more about the upper bounds, better
discuss with Robert LeBlanc to see if it can be detailed in kdump.txt.

Also please CC to x86 maintainers, or akpm. They can help merge this.

Thanks
Baoquan

2016-12-23 08:36:02

by Xunlei Pang

[permalink] [raw]
Subject: Re: [PATCH] x86/crash: Update the stale comment in reserve_crashkernel()

On 12/22/2016 at 11:22 AM, Baoquan He wrote:
> On 12/15/16 at 11:30am, Xunlei Pang wrote:
>> CRASH_KERNEL_ADDR_MAX was missing for a long time, update it
>> with more detailed explanation.
>>
>> Cc: Robert LeBlanc <[email protected]>
>> Cc: Baoquan He <[email protected]>
>> Signed-off-by: Xunlei Pang <[email protected]>
>> ---
>> arch/x86/kernel/setup.c | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
>> index 9c337b0..79ee507 100644
>> --- a/arch/x86/kernel/setup.c
>> +++ b/arch/x86/kernel/setup.c
>> @@ -575,7 +575,10 @@ static void __init reserve_crashkernel(void)
>> /* 0 means: find the address automatically */
>> if (crash_base <= 0) {
>> /*
>> - * kexec want bzImage is below CRASH_KERNEL_ADDR_MAX
>> + * Set CRASH_ADDR_LOW_MAX upper bound for crash range
>> + * as old kexec-tools loads bzImage below that, unless
>> + * "size,high" or "size@offset"(nonzero offset, see the
>> + * else leg below) is specified.
> Yes, this is a good catch. It might be better to add comment only about
> this if branch. If you want to say more about the upper bounds, better

OK, how about the following change?
/*
* Set CRASH_ADDR_LOW_MAX upper bound for crash memory.
* as old kexec-tools loads bzImage below that, unless
* "crashkernel=size[KMG],high" is specified.
*/

> discuss with Robert LeBlanc to see if it can be detailed in kdump.txt.

Yes, this is independent of Robert's documentation patch.

>
> Also please CC to x86 maintainers, or akpm. They can help merge this.

OK, thanks!

Regards,
Xunlei