If crash_base is equal to CRASH_ADDR_LOW_MAX, it also indicates that
the crashkernel memory is allocated from high memory. However, the
current check only considers the case where crash_base is greater than
CRASH_ADDR_LOW_MAX. Fix it.
This patch also includes some minor cleanups.
Fixes: 0ab97169aa05 ("crash_core: add generic function to do reservation")
Signed-off-by: Yuntao Wang <[email protected]>
---
kernel/crash_core.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/kernel/crash_core.c b/kernel/crash_core.c
index efe87d501c8c..d4313b53837e 100644
--- a/kernel/crash_core.c
+++ b/kernel/crash_core.c
@@ -199,7 +199,7 @@ static __initdata char *suffix_tbl[] = {
* It returns 0 on success and -EINVAL on failure.
*/
static int __init parse_crashkernel_suffix(char *cmdline,
- unsigned long long *crash_size,
+ unsigned long long *crash_size,
const char *suffix)
{
char *cur = cmdline;
@@ -268,9 +268,9 @@ static int __init __parse_crashkernel(char *cmdline,
unsigned long long *crash_base,
const char *suffix)
{
- char *first_colon, *first_space;
- char *ck_cmdline;
- char *name = "crashkernel=";
+ char *first_colon, *first_space;
+ char *ck_cmdline;
+ char *name = "crashkernel=";
BUG_ON(!crash_size || !crash_base);
*crash_size = 0;
@@ -440,7 +440,7 @@ void __init reserve_crashkernel_generic(char *cmdline,
return;
}
- if ((crash_base > CRASH_ADDR_LOW_MAX) &&
+ if ((crash_base >= CRASH_ADDR_LOW_MAX) &&
crash_low_size && reserve_crashkernel_low(crash_low_size)) {
memblock_phys_free(crash_base, crash_size);
return;
--
2.43.0
On Sat, 9 Dec 2023 22:14:38 +0800 Yuntao Wang <[email protected]> wrote:
> If crash_base is equal to CRASH_ADDR_LOW_MAX, it also indicates that
> the crashkernel memory is allocated from high memory. However, the
> current check only considers the case where crash_base is greater than
> CRASH_ADDR_LOW_MAX. Fix it.
>
> This patch also includes some minor cleanups.
Can we please include a description of the runtime effects of this
change? ie, what happens now and under what circumstances, and how
does the fix alter these things?
The purpose of the reserve_crashkernel_generic() function is to allocate a
block of memory for crash kernel, and if the block of memory is allocated
from high memory, it will allocate an additional block from low memory.
The method to determine if a block of memory is from high memory is to
check if crash_base is greater than or equal to CRASH_ADDR_LOW_MAX.
However, the current code only considers the case where crash_base is
greater than CRASH_ADDR_LOW_MAX.
This means that if the memory is allocated from high memory and its
starting address is CRASH_ADDR_LOW_MAX, reserve_crashkernel_generic()
will no longer allocate the additional memory from low memory for crash
kernel, even if it is necessary.
In fact, we can also take a look at the code before it was modified in
these commits:
9c08a2a139fe ("x86: kdump: use generic interface to simplify crashkernel reservation code")
fdc268232dbb ("arm64: kdump: use generic interface to simplify crashkernel reservation")
39365395046f ("riscv: kdump: use generic interface to simplify crashkernel reservation")
They all checked for the case where crash_base is equal to
CRASH_ADDR_LOW_MAX.
This patch also includes some minor cleanups.
Fixes: 0ab97169aa05 ("crash_core: add generic function to do reservation")
Signed-off-by: Yuntao Wang <[email protected]>
---
v1->v2: Provide a more detailed description.
kernel/crash_core.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/kernel/crash_core.c b/kernel/crash_core.c
index efe87d501c8c..d4313b53837e 100644
--- a/kernel/crash_core.c
+++ b/kernel/crash_core.c
@@ -199,7 +199,7 @@ static __initdata char *suffix_tbl[] = {
* It returns 0 on success and -EINVAL on failure.
*/
static int __init parse_crashkernel_suffix(char *cmdline,
- unsigned long long *crash_size,
+ unsigned long long *crash_size,
const char *suffix)
{
char *cur = cmdline;
@@ -268,9 +268,9 @@ static int __init __parse_crashkernel(char *cmdline,
unsigned long long *crash_base,
const char *suffix)
{
- char *first_colon, *first_space;
- char *ck_cmdline;
- char *name = "crashkernel=";
+ char *first_colon, *first_space;
+ char *ck_cmdline;
+ char *name = "crashkernel=";
BUG_ON(!crash_size || !crash_base);
*crash_size = 0;
@@ -440,7 +440,7 @@ void __init reserve_crashkernel_generic(char *cmdline,
return;
}
- if ((crash_base > CRASH_ADDR_LOW_MAX) &&
+ if ((crash_base >= CRASH_ADDR_LOW_MAX) &&
crash_low_size && reserve_crashkernel_low(crash_low_size)) {
memblock_phys_free(crash_base, crash_size);
return;
--
2.43.0
On 12/09/23 at 02:34pm, Andrew Morton wrote:
> On Sat, 9 Dec 2023 22:14:38 +0800 Yuntao Wang <[email protected]> wrote:
>
> > If crash_base is equal to CRASH_ADDR_LOW_MAX, it also indicates that
> > the crashkernel memory is allocated from high memory. However, the
> > current check only considers the case where crash_base is greater than
> > CRASH_ADDR_LOW_MAX. Fix it.
> >
> > This patch also includes some minor cleanups.
>
> Can we please include a description of the runtime effects of this
> change? ie, what happens now and under what circumstances, and how
> does the fix alter these things?
This is a good catch. Guess it's observed from code exploring.
The runtime effects is that crashkernel high memory is successfully
reserved, whereas the crashkernel low memory is bypassed in this
case, then kdump kernel bootup will fail because of no low memory
under 4G.