All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: Huacai Chen <chenhuacai@loongson.cn>, akpm@linux-foundation.org
Cc: Vivek Goyal <vgoyal@redhat.com>, Dave Young <dyoung@redhat.com>,
	Youling Tang <tangyouling@kylinos.cn>,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kdump: Defer the insertion of crashkernel resources
Date: Fri, 5 Jan 2024 10:53:01 +0800	[thread overview]
Message-ID: <ZZdvDYg6sk8P2JWn@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20231229080213.2622204-1-chenhuacai@loongson.cn>

Huacai,

On 12/29/23 at 04:02pm, Huacai Chen wrote:
> In /proc/iomem, sub-regions should be inserted after their parent,
> otherwise the insertion of parent resource fails. But after generic
> crashkernel reservation applied, in both RISC-V and ARM64 (LoongArch
> will also use generic reservation later on), crashkernel resources are
> inserted before their parent, which causes the parent disappear in
> /proc/iomem. So we defer the insertion of crashkernel resources to an
> early_initcall().
> 
> 1, Without 'crashkernel' parameter:
> 
>  100d0100-100d01ff : LOON0001:00
>    100d0100-100d01ff : LOON0001:00 LOON0001:00
>  100e0000-100e0bff : LOON0002:00
>    100e0000-100e0bff : LOON0002:00 LOON0002:00
>  1fe001e0-1fe001e7 : serial
>  90400000-fa17ffff : System RAM
>    f6220000-f622ffff : Reserved
>    f9ee0000-f9ee3fff : Reserved
>    fa120000-fa17ffff : Reserved
>  fa190000-fe0bffff : System RAM
>    fa190000-fa1bffff : Reserved
>  fe4e0000-47fffffff : System RAM
>    43c000000-441ffffff : Reserved
>    47ff98000-47ffa3fff : Reserved
>    47ffa4000-47ffa7fff : Reserved
>    47ffa8000-47ffabfff : Reserved
>    47ffac000-47ffaffff : Reserved
>    47ffb0000-47ffb3fff : Reserved
> 
> 2, With 'crashkernel' parameter, before this patch:
> 
>  100d0100-100d01ff : LOON0001:00
>    100d0100-100d01ff : LOON0001:00 LOON0001:00
>  100e0000-100e0bff : LOON0002:00
>    100e0000-100e0bff : LOON0002:00 LOON0002:00
>  1fe001e0-1fe001e7 : serial
>  e6200000-f61fffff : Crash kernel
>  fa190000-fe0bffff : System RAM
>    fa190000-fa1bffff : Reserved
>  fe4e0000-47fffffff : System RAM
>    43c000000-441ffffff : Reserved
>    47ff98000-47ffa3fff : Reserved
>    47ffa4000-47ffa7fff : Reserved
>    47ffa8000-47ffabfff : Reserved
>    47ffac000-47ffaffff : Reserved
>    47ffb0000-47ffb3fff : Reserved
> 
> 3, With 'crashkernel' parameter, after this patch:
> 
>  100d0100-100d01ff : LOON0001:00
>    100d0100-100d01ff : LOON0001:00 LOON0001:00
>  100e0000-100e0bff : LOON0002:00
>    100e0000-100e0bff : LOON0002:00 LOON0002:00
>  1fe001e0-1fe001e7 : serial
>  90400000-fa17ffff : System RAM
>    e6200000-f61fffff : Crash kernel
>    f6220000-f622ffff : Reserved
>    f9ee0000-f9ee3fff : Reserved
>    fa120000-fa17ffff : Reserved
>  fa190000-fe0bffff : System RAM
>    fa190000-fa1bffff : Reserved
>  fe4e0000-47fffffff : System RAM
>    43c000000-441ffffff : Reserved
>    47ff98000-47ffa3fff : Reserved
>    47ffa4000-47ffa7fff : Reserved
>    47ffa8000-47ffabfff : Reserved
>    47ffac000-47ffaffff : Reserved
>    47ffb0000-47ffb3fff : Reserved

This looks like a great catch. I am curious where arm64 and loongarch
insert the system RAM range into iomem before crashk_res and
crashk_low_res. On x86, it should be done by pci or acpi init which is
earlier than crashkernel parsing and inserting into iomem, just went\
through codes, haven't adding debugging code to print.

> 
> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
> ---
>  kernel/crash_core.c | 14 ++++++++++++--
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
> index d4313b53837e..755d8d4ef5b0 100644
> --- a/kernel/crash_core.c
> +++ b/kernel/crash_core.c
> @@ -377,7 +377,6 @@ static int __init reserve_crashkernel_low(unsigned long long low_size)
>  
>  	crashk_low_res.start = low_base;
>  	crashk_low_res.end   = low_base + low_size - 1;
> -	insert_resource(&iomem_resource, &crashk_low_res);
>  #endif
>  	return 0;
>  }
> @@ -459,8 +458,19 @@ void __init reserve_crashkernel_generic(char *cmdline,
>  
>  	crashk_res.start = crash_base;
>  	crashk_res.end = crash_base + crash_size - 1;
> -	insert_resource(&iomem_resource, &crashk_res);
>  }
> +
> +static __init int insert_crashkernel_resources(void)
> +{
> +	if (crashk_res.start < crashk_res.end)
> +		insert_resource(&iomem_resource, &crashk_res);
> +
> +	if (crashk_low_res.start < crashk_low_res.end)
> +		insert_resource(&iomem_resource, &crashk_low_res);
> +
> +	return 0;
> +}
> +early_initcall(insert_crashkernel_resources);
>  #endif
>  
>  int crash_prepare_elf64_headers(struct crash_mem *mem, int need_kernel_map,
> -- 
> 2.39.3
> 
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
> 


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: Huacai Chen <chenhuacai@loongson.cn>, akpm@linux-foundation.org
Cc: Vivek Goyal <vgoyal@redhat.com>, Dave Young <dyoung@redhat.com>,
	Youling Tang <tangyouling@kylinos.cn>,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kdump: Defer the insertion of crashkernel resources
Date: Fri, 5 Jan 2024 10:53:01 +0800	[thread overview]
Message-ID: <ZZdvDYg6sk8P2JWn@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20231229080213.2622204-1-chenhuacai@loongson.cn>

Huacai,

On 12/29/23 at 04:02pm, Huacai Chen wrote:
> In /proc/iomem, sub-regions should be inserted after their parent,
> otherwise the insertion of parent resource fails. But after generic
> crashkernel reservation applied, in both RISC-V and ARM64 (LoongArch
> will also use generic reservation later on), crashkernel resources are
> inserted before their parent, which causes the parent disappear in
> /proc/iomem. So we defer the insertion of crashkernel resources to an
> early_initcall().
> 
> 1, Without 'crashkernel' parameter:
> 
>  100d0100-100d01ff : LOON0001:00
>    100d0100-100d01ff : LOON0001:00 LOON0001:00
>  100e0000-100e0bff : LOON0002:00
>    100e0000-100e0bff : LOON0002:00 LOON0002:00
>  1fe001e0-1fe001e7 : serial
>  90400000-fa17ffff : System RAM
>    f6220000-f622ffff : Reserved
>    f9ee0000-f9ee3fff : Reserved
>    fa120000-fa17ffff : Reserved
>  fa190000-fe0bffff : System RAM
>    fa190000-fa1bffff : Reserved
>  fe4e0000-47fffffff : System RAM
>    43c000000-441ffffff : Reserved
>    47ff98000-47ffa3fff : Reserved
>    47ffa4000-47ffa7fff : Reserved
>    47ffa8000-47ffabfff : Reserved
>    47ffac000-47ffaffff : Reserved
>    47ffb0000-47ffb3fff : Reserved
> 
> 2, With 'crashkernel' parameter, before this patch:
> 
>  100d0100-100d01ff : LOON0001:00
>    100d0100-100d01ff : LOON0001:00 LOON0001:00
>  100e0000-100e0bff : LOON0002:00
>    100e0000-100e0bff : LOON0002:00 LOON0002:00
>  1fe001e0-1fe001e7 : serial
>  e6200000-f61fffff : Crash kernel
>  fa190000-fe0bffff : System RAM
>    fa190000-fa1bffff : Reserved
>  fe4e0000-47fffffff : System RAM
>    43c000000-441ffffff : Reserved
>    47ff98000-47ffa3fff : Reserved
>    47ffa4000-47ffa7fff : Reserved
>    47ffa8000-47ffabfff : Reserved
>    47ffac000-47ffaffff : Reserved
>    47ffb0000-47ffb3fff : Reserved
> 
> 3, With 'crashkernel' parameter, after this patch:
> 
>  100d0100-100d01ff : LOON0001:00
>    100d0100-100d01ff : LOON0001:00 LOON0001:00
>  100e0000-100e0bff : LOON0002:00
>    100e0000-100e0bff : LOON0002:00 LOON0002:00
>  1fe001e0-1fe001e7 : serial
>  90400000-fa17ffff : System RAM
>    e6200000-f61fffff : Crash kernel
>    f6220000-f622ffff : Reserved
>    f9ee0000-f9ee3fff : Reserved
>    fa120000-fa17ffff : Reserved
>  fa190000-fe0bffff : System RAM
>    fa190000-fa1bffff : Reserved
>  fe4e0000-47fffffff : System RAM
>    43c000000-441ffffff : Reserved
>    47ff98000-47ffa3fff : Reserved
>    47ffa4000-47ffa7fff : Reserved
>    47ffa8000-47ffabfff : Reserved
>    47ffac000-47ffaffff : Reserved
>    47ffb0000-47ffb3fff : Reserved

This looks like a great catch. I am curious where arm64 and loongarch
insert the system RAM range into iomem before crashk_res and
crashk_low_res. On x86, it should be done by pci or acpi init which is
earlier than crashkernel parsing and inserting into iomem, just went\
through codes, haven't adding debugging code to print.

> 
> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
> ---
>  kernel/crash_core.c | 14 ++++++++++++--
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
> index d4313b53837e..755d8d4ef5b0 100644
> --- a/kernel/crash_core.c
> +++ b/kernel/crash_core.c
> @@ -377,7 +377,6 @@ static int __init reserve_crashkernel_low(unsigned long long low_size)
>  
>  	crashk_low_res.start = low_base;
>  	crashk_low_res.end   = low_base + low_size - 1;
> -	insert_resource(&iomem_resource, &crashk_low_res);
>  #endif
>  	return 0;
>  }
> @@ -459,8 +458,19 @@ void __init reserve_crashkernel_generic(char *cmdline,
>  
>  	crashk_res.start = crash_base;
>  	crashk_res.end = crash_base + crash_size - 1;
> -	insert_resource(&iomem_resource, &crashk_res);
>  }
> +
> +static __init int insert_crashkernel_resources(void)
> +{
> +	if (crashk_res.start < crashk_res.end)
> +		insert_resource(&iomem_resource, &crashk_res);
> +
> +	if (crashk_low_res.start < crashk_low_res.end)
> +		insert_resource(&iomem_resource, &crashk_low_res);
> +
> +	return 0;
> +}
> +early_initcall(insert_crashkernel_resources);
>  #endif
>  
>  int crash_prepare_elf64_headers(struct crash_mem *mem, int need_kernel_map,
> -- 
> 2.39.3
> 
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
> 


  reply	other threads:[~2024-01-05  2:53 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-29  8:02 [PATCH] kdump: Defer the insertion of crashkernel resources Huacai Chen
2023-12-29  8:02 ` Huacai Chen
2024-01-05  2:53 ` Baoquan He [this message]
2024-01-05  2:53   ` Baoquan He
2024-01-05 16:49 ` Andrew Morton
2024-01-05 16:49   ` Andrew Morton
2024-01-06  2:09   ` Baoquan He
2024-01-06  2:09     ` Baoquan He

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=ZZdvDYg6sk8P2JWn@MiWiFi-R3L-srv \
    --to=bhe@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=chenhuacai@loongson.cn \
    --cc=dyoung@redhat.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tangyouling@kylinos.cn \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.