Re: [PATCH v3 5/9] crash_core: move crashk_*res definition into crash_core.c
On 2023/9/14 11:31, Baoquan He wrote:
> Both crashk_res and crashk_low_res are used to mark the reserved
> crashkernel regions in iomem_resource tree. And later the generic
> crashkernel resrvation will be added into crash_core.c. So move
> crashk_res and crashk_low_res definition into crash_core.c to avoid
> compiling error if CONFIG_CRASH_CORE=on while CONFIG_KEXEC_CORE is
> unset.
>
> Meanwhile include in if generic
> reservation is needed. In that case, need be added
> by ARCH. In asm/crash_core.h, ARCH can provide its own macro definitions
> to override macros in if needed. Wrap the including
> into CONFIG_ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION ifdeffery scope to
> avoid compiling error in other ARCH-es which don't take the generic
> reservation way yet.
Reviewed-by: Zhen Lei
>
> Signed-off-by: Baoquan He
> ---
> include/linux/crash_core.h | 8
> include/linux/kexec.h | 4
> kernel/crash_core.c| 16
> kernel/kexec_core.c| 17 -
> 4 files changed, 24 insertions(+), 21 deletions(-)
>
> diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
> index 4dbd6565e0ff..3c735a7e33fb 100644
> --- a/include/linux/crash_core.h
> +++ b/include/linux/crash_core.h
> @@ -5,6 +5,14 @@
> #include
> #include
> #include
> +#ifdef CONFIG_ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION
> +#include
> +#endif
> +
> +/* Location of a reserved region to hold the crash kernel.
> + */
> +extern struct resource crashk_res;
> +extern struct resource crashk_low_res;
>
> #define CRASH_CORE_NOTE_NAME"CORE"
> #define CRASH_CORE_NOTE_HEAD_BYTES ALIGN(sizeof(struct elf_note), 4)
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index 32c78078552c..8227455192b7 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -22,10 +22,6 @@
> #include
> #include
>
> -/* Location of a reserved region to hold the crash kernel.
> - */
> -extern struct resource crashk_res;
> -extern struct resource crashk_low_res;
> extern note_buf_t __percpu *crash_notes;
>
> #ifdef CONFIG_KEXEC_CORE
> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
> index ca66b5f41dc7..ad7dc03f3993 100644
> --- a/kernel/crash_core.c
> +++ b/kernel/crash_core.c
> @@ -35,6 +35,22 @@ u32 *vmcoreinfo_note;
> /* trusted vmcoreinfo, e.g. we can make a copy in the crash memory */
> static unsigned char *vmcoreinfo_data_safecopy;
>
> +/* Location of the reserved area for the crash kernel */
> +struct resource crashk_res = {
> + .name = "Crash kernel",
> + .start = 0,
> + .end = 0,
> + .flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
> + .desc = IORES_DESC_CRASH_KERNEL
> +};
> +struct resource crashk_low_res = {
> + .name = "Crash kernel",
> + .start = 0,
> + .end = 0,
> + .flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
> + .desc = IORES_DESC_CRASH_KERNEL
> +};
> +
> /*
> * parsing the "crashkernel" commandline
> *
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index 9dc728982d79..be5642a4ec49 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -52,23 +52,6 @@ atomic_t __kexec_lock = ATOMIC_INIT(0);
> /* Flag to indicate we are going to kexec a new kernel */
> bool kexec_in_progress = false;
>
> -
> -/* Location of the reserved area for the crash kernel */
> -struct resource crashk_res = {
> - .name = "Crash kernel",
> - .start = 0,
> - .end = 0,
> - .flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
> - .desc = IORES_DESC_CRASH_KERNEL
> -};
> -struct resource crashk_low_res = {
> - .name = "Crash kernel",
> - .start = 0,
> - .end = 0,
> - .flags = IORESOURCE_BUSY | IORESOURCE_SYSTEM_RAM,
> - .desc = IORES_DESC_CRASH_KERNEL
> -};
> -
> int kexec_should_crash(struct task_struct *p)
> {
> /*
>
--
Regards,
Zhen Lei
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v3 4/9] crash_core: add generic function to do reservation
On 2023/9/14 11:31, Baoquan He wrote:
> In architecture like x86_64, arm64 and riscv, they have vast virtual
> address space and usually have huge physical memory RAM. Their
> crashkernel reservation doesn't have to be limited under 4G RAM,
> but can be extended to the whole physical memory via crashkernel=,high
> support.
>
> Now add function reserve_crashkernel_generic() to reserve crashkernel
> memory if users specify any case of kernel pamameters, like
> crashkernel=xM[@offset] or crashkernel=,high|low.
>
> This is preparation to simplify code of crashkernel=,high support
> in architecutures.
Reviewed-by: Zhen Lei
>
> Signed-off-by: Baoquan He
> ---
> include/linux/crash_core.h | 28 ++
> kernel/crash_core.c| 107 -
> 2 files changed, 134 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
> index d8050a7eab01..4dbd6565e0ff 100644
> --- a/include/linux/crash_core.h
> +++ b/include/linux/crash_core.h
> @@ -93,6 +93,34 @@ int parse_crashkernel_high(char *cmdline, unsigned long
> long system_ram,
> int parse_crashkernel_low(char *cmdline, unsigned long long system_ram,
> unsigned long long *crash_size, unsigned long long *crash_base);
>
> +#ifdef CONFIG_ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION
> +#ifndef DEFAULT_CRASH_KERNEL_LOW_SIZE
> +#define DEFAULT_CRASH_KERNEL_LOW_SIZE(128UL << 20)
> +#endif
> +#ifndef CRASH_ALIGN
> +#define CRASH_ALIGN SZ_2M
> +#endif
> +#ifndef CRASH_ADDR_LOW_MAX
> +#define CRASH_ADDR_LOW_MAX SZ_4G
> +#endif
> +#ifndef CRASH_ADDR_HIGH_MAX
> +#define CRASH_ADDR_HIGH_MAX memblock_end_of_DRAM()
> +#endif
> +
> +void __init reserve_crashkernel_generic(char *cmdline,
> + unsigned long long crash_size,
> + unsigned long long crash_base,
> + unsigned long long crash_low_size,
> + bool high);
> +#else
> +static inline void __init reserve_crashkernel_generic(char *cmdline,
> + unsigned long long crash_size,
> + unsigned long long crash_base,
> + unsigned long long crash_low_size,
> + bool high)
> +{}
> +#endif
> +
> /* Alignment required for elf header segment */
> #define ELF_CORE_HEADER_ALIGN 4096
>
> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
> index dce2f5874fea..ca66b5f41dc7 100644
> --- a/kernel/crash_core.c
> +++ b/kernel/crash_core.c
> @@ -5,7 +5,6 @@
> */
>
> #include
> -#include
> #include
> #include
> #include
> @@ -13,6 +12,9 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
>
> #include
> #include
> @@ -360,6 +362,109 @@ static int __init parse_crashkernel_dummy(char *arg)
> }
> early_param("crashkernel", parse_crashkernel_dummy);
>
> +#ifdef CONFIG_ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION
> +static int __init reserve_crashkernel_low(unsigned long long low_size)
> +{
> +#ifdef CONFIG_64BIT
> + unsigned long long low_base;
> +
> + low_base = memblock_phys_alloc_range(low_size, CRASH_ALIGN, 0,
> CRASH_ADDR_LOW_MAX);
> + if (!low_base) {
> + pr_err("cannot allocate crashkernel low memory
> (size:0x%llx).\n", low_size);
> + return -ENOMEM;
> + }
> +
> + pr_info("crashkernel low memory reserved: 0x%08llx - 0x%08llx (%lld
> MB)\n",
> + low_base, low_base + low_size, low_size >> 20);
> +
> + crashk_low_res.start = low_base;
> + crashk_low_res.end = low_base + low_size - 1;
> + insert_resource(_resource, _low_res);
> +#endif
> + return 0;
> +}
> +
> +void __init reserve_crashkernel_generic(char *cmdline,
> + unsigned long long crash_size,
> + unsigned long long crash_base,
> + unsigned long long crash_low_size,
> + bool high)
> +{
> + unsigned long long search_end = CRASH_ADDR_LOW_MAX, search_base = 0;
> + bool fixed_base = false;
> +
> + /* User specifies base address explicitly. */
> + if (crash_base) {
> + fixed_base = true;
> + search_base = crash_base;
> + search_end = crash_base + crash_size;
> + } else if (high) {
> + search_base = CRASH_ADDR_LOW_MAX;
> + search_end = CRASH_ADDR_HIGH_MAX;
> + }
> +
> +retry:
> + crash_base = memblock_phys_alloc_range(crash_size, CRASH_ALIGN,
> +search_base, search_end);
> + if (!crash_base) {
> + /*
> + * For crashkernel=size[KMG]@offset[KMG], print out failure
> + * message if can't reserve the specified region.
> + */
> + if (fixed_base) {
> + pr_warn("crashkernel reservation failed - memory is in
> use.\n");
> + return;
> + }
> +
> + /*
> + * For
Re: [PATCH v3 3/9] crash_core: change parse_crashkernel() to support crashkernel=,high|low parsing
On 2023/9/14 11:31, Baoquan He wrote:
> Now parse_crashkernel() is a real entry point for all kinds of
> crahskernel parsing on any architecture.
>
> And wrap the crahskernel=,high|low handling inside
> CONFIG_ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION ifdeffery scope.
Reviewed-by: Zhen Lei
>
> Signed-off-by: Baoquan He
> ---
> include/linux/crash_core.h | 6 ++
> kernel/crash_core.c| 36 +---
> 2 files changed, 39 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
> index 6156355ef831..d8050a7eab01 100644
> --- a/include/linux/crash_core.h
> +++ b/include/linux/crash_core.h
> @@ -79,6 +79,12 @@ Elf_Word *append_elf_note(Elf_Word *buf, char *name,
> unsigned int type,
> void *data, size_t data_len);
> void final_note(Elf_Word *buf);
>
> +#ifdef CONFIG_ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION
> +#ifndef DEFAULT_CRASH_KERNEL_LOW_SIZE
> +#define DEFAULT_CRASH_KERNEL_LOW_SIZE (128UL << 20)
> +#endif
> +#endif
> +
> int __init parse_crashkernel(char *cmdline, unsigned long long system_ram,
> unsigned long long *crash_size, unsigned long long *crash_base,
> unsigned long long *low_size, bool *high);
> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
> index cca1d76e8255..dce2f5874fea 100644
> --- a/kernel/crash_core.c
> +++ b/kernel/crash_core.c
> @@ -283,6 +283,9 @@ static int __init __parse_crashkernel(char *cmdline,
> /*
> * That function is the entry point for command line parsing and should be
> * called from the arch-specific code.
> + *
> + * If crashkernel=,high|low is supported on architecture, non-NULL values
> + * should be passed to parameters 'low_size' and 'high'.
> */
> int __init parse_crashkernel(char *cmdline,
>unsigned long long system_ram,
> @@ -296,10 +299,37 @@ int __init parse_crashkernel(char *cmdline,
> /* crashkernel=X[@offset] */
> ret = __parse_crashkernel(cmdline, system_ram, crash_size,
> crash_base, NULL);
> - if (!high)
> - return ret;
> +#ifdef CONFIG_ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION
> + /*
> + * If non-NULL 'high' passed in and no normal crashkernel
> + * setting detected, try parsing crashkernel=,high|low.
> + */
> + if (high && ret == -ENOENT) {
> + ret = __parse_crashkernel(cmdline, 0, crash_size,
> + crash_base, suffix_tbl[SUFFIX_HIGH]);
> + if (ret || !*crash_size)
> + return -EINVAL;
>
> - return 0;
> + /*
> + * crashkernel=Y,low can be specified or not, but invalid value
> + * is not allowed.
> + */
> + ret = __parse_crashkernel(cmdline, 0, low_size,
> + crash_base, suffix_tbl[SUFFIX_LOW]);
> + if (ret == -ENOENT) {
> + *low_size = DEFAULT_CRASH_KERNEL_LOW_SIZE;
> + ret = 0;
> + } else if (ret) {
> + return ret;
> + }
> +
> + *high = true;
> + }
> +#endif
> + if (!*crash_size)
> + ret = -EINVAL;
> +
> + return ret;
> }
>
> int __init parse_crashkernel_high(char *cmdline,
>
--
Regards,
Zhen Lei
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2 3/8] crash_core: change parse_crashkernel() to support crashkernel=,high|low parsing
On 2023/9/5 16:29, Baoquan He wrote:
> On 09/04/23 at 10:47am, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2023/9/1 17:49, Baoquan He wrote:
>>>>> +
>>>>> + *high = true;
>>>>> + } else if (ret || !*crash_size) {
>>>> This check can be moved outside of #ifdef. Because even '!high', it's
>>>> completely
>>>> applicable. The overall adjustment is as follows:
>>> Hmm, the current logic is much easier to understand. However, I may not
>>> 100% get your suggestion. Can you paste the complete code in your
>>> suggested way? Do not need 100% correct code, just the skeleton of code
>>> logic
>>> so that I can better understand it and add inline comment.
>>
>> int __init parse_crashkernel(...)
>> {
>> int ret;
>>
>> /* crashkernel=X[@offset] */
>> ret = __parse_crashkernel(cmdline, system_ram, crash_size,
>> crash_base, NULL);
>>
>> #ifdef CONFIG_ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION
>> if (high && ret == -ENOENT) {
>> ... ... //The code for your original branch "else if
>> (ret == -ENOENT) {"
>> ret = 0;//Added based on the next discussion
>> }
>> +#endif
>>
>> if (!*crash_size)
>> ret = -EINVAL;
>>
>> return ret;
>> }
>>
> Thanks, Zhen Lei.
>
> I paste the whole parse_crashkernel() as you suggested at bottom. Please
> check if it's what you want.
Yes.
> To me, both is fine to me. I have two minor
> concerns to your suggested way.
>
> 1)
> I took the "if (!high) return" way because except of x86/arm64, all
> other architectures will call parse_crashkerne() and check
> if *crash_size ==0. Please try 'git grep "parse_crashkernel(" arch'
> and check those call sites. With that, we will have duplicated checking.
Add some patches to remove the duplicated checking of other ARCHs? After this
patch series upstreamed.
>
> ret = __parse_crashkernel(cmdline, system_ram, crash_size,
> crash_base, NULL);
> if (!high)
> return ret;
> 2)
> I actually like below branch and the code comment. It can give people
> hint about what's going on in that case. Discarding it is a little pity.
Except that "!*crash_size" and "(high && ret == -ENOENT)" needs special
comments,
other common errors do not need to be described, I think. Even if some is
required,
it should be placed in function __parse_crashkernel().
>
> } else if (ret || !*crash_size) {
> /* The specified value is invalid */
> return -1;
> }
>
> int __init parse_crashkernel(...)
> {
> int ret;
>
> /* crashkernel=X[@offset] */
> ret = __parse_crashkernel(cmdline, system_ram, crash_size,
> crash_base, NULL);
> #ifdef CONFIG_ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION
> if (high && ret == -ENOENT) {
> ret = __parse_crashkernel(cmdline, 0, crash_size,
> crash_base, suffix_tbl[SUFFIX_HIGH]);
> if (ret || !*crash_size)
> return -EINVAL;
>
> /*
>* crashkernel=Y,low can be specified or not, but invalid value
>* is not allowed.
>*/
> ret = __parse_crashkernel(cmdline, 0, low_size,
> crash_base, suffix_tbl[SUFFIX_LOW]);
> if (ret == -ENOENT) {
> *low_size = DEFAULT_CRASH_KERNEL_LOW_SIZE;
> ret = 0;
> } else if (ret) {
> return ret;
> }
>
> *high = true;
> }
> #endif
>
> if (!*crash_size)
> ret = -EINVAL;
>
> return ret;
> }
>
> .
>
--
Regards,
Zhen Lei
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2 3/8] crash_core: change parse_crashkernel() to support crashkernel=,high|low parsing
On 2023/9/1 17:49, Baoquan He wrote:
>>> +
>>> + *high = true;
>>> + } else if (ret || !*crash_size) {
>> This check can be moved outside of #ifdef. Because even '!high', it's
>> completely
>> applicable. The overall adjustment is as follows:
> Hmm, the current logic is much easier to understand. However, I may not
> 100% get your suggestion. Can you paste the complete code in your
> suggested way? Do not need 100% correct code, just the skeleton of code logic
> so that I can better understand it and add inline comment.
int __init parse_crashkernel(...)
{
int ret;
/* crashkernel=X[@offset] */
ret = __parse_crashkernel(cmdline, system_ram, crash_size,
crash_base, NULL);
#ifdef CONFIG_ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION
if (high && ret == -ENOENT) {
... ... //The code for your original branch "else if
(ret == -ENOENT) {"
ret = 0;//Added based on the next discussion
}
+#endif
if (!*crash_size)
ret = -EINVAL;
return ret;
}
>
>> -if (!high)
>> -return ret;
>>
>> #ifdef CONFIG_ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION
>> if (high && ret == -ENOENT) {
>> ... ...
>> if (ret || !*crash_size)//parse HIGH
>> ... ...
>> }
>>
>> //At this point, *crash_size is not 0 and ret is 0.
>> //We can also delete if (!*crash_size) above because it will be checked
>> later.
>> #endif
>>
>> if (!*crash_size)
>> ret = -EINVAL;
>>
>> return ret;
> When crashkernel=,high is specified while crashkernel=,low is omitted,
> the ret==-ENOENT, but we can't return ret directly. That is still an
> acceptable way.
Oh, yes. Sorry, I didn't notice branch "ret==-ENOENT" didn't return. So "ret =
0;"
needs to be added.
if (high && ret == -ENOENT) {
... ...
*high = true;
+ ret = 0;
}
>
>> -return 0;
>>
>>> + /* The specified value is invalid */
>>> + return -1;
>>> + }
>>> +#endif
>>> return 0;
>>> }
>>>
>>>
--
Regards,
Zhen Lei
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2 8/8] crash_core.c: remove unneeded functions
On 2023/8/29 20:16, Baoquan He wrote:
> So far, nobody calls functions parse_crashkernel_high() and
> parse_crashkernel_low(), remove both of them.
Reviewed-by: Zhen Lei
>
> Signed-off-by: Baoquan He
> ---
> include/linux/crash_core.h | 4
> kernel/crash_core.c| 18 --
> 2 files changed, 22 deletions(-)
>
> diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
> index 86e22e6a039f..d64006c4bd43 100644
> --- a/include/linux/crash_core.h
> +++ b/include/linux/crash_core.h
> @@ -83,10 +83,6 @@ void final_note(Elf_Word *buf);
> int __init parse_crashkernel(char *cmdline, unsigned long long system_ram,
> unsigned long long *crash_size, unsigned long long *crash_base,
> unsigned long long *low_size, bool *high);
> -int parse_crashkernel_high(char *cmdline, unsigned long long system_ram,
> - unsigned long long *crash_size, unsigned long long *crash_base);
> -int parse_crashkernel_low(char *cmdline, unsigned long long system_ram,
> - unsigned long long *crash_size, unsigned long long *crash_base);
>
> #ifdef CONFIG_ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION
> #ifndef DEFAULT_CRASH_KERNEL_LOW_SIZE
> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
> index 6bc00cc390b5..61a8ea3b23a2 100644
> --- a/kernel/crash_core.c
> +++ b/kernel/crash_core.c
> @@ -323,24 +323,6 @@ int __init parse_crashkernel(char *cmdline,
> return 0;
> }
>
> -int __init parse_crashkernel_high(char *cmdline,
> - unsigned long long system_ram,
> - unsigned long long *crash_size,
> - unsigned long long *crash_base)
> -{
> - return __parse_crashkernel(cmdline, system_ram, crash_size, crash_base,
> - suffix_tbl[SUFFIX_HIGH]);
> -}
> -
> -int __init parse_crashkernel_low(char *cmdline,
> - unsigned long long system_ram,
> - unsigned long long *crash_size,
> - unsigned long long *crash_base)
> -{
> - return __parse_crashkernel(cmdline, system_ram, crash_size, crash_base,
> - suffix_tbl[SUFFIX_LOW]);
> -}
> -
> /*
> * Add a dummy early_param handler to mark crashkernel= as a known command
> line
> * parameter and suppress incorrect warnings in init/main.c.
>
--
Regards,
Zhen Lei
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2 7/8] arm64: kdump: use generic interface to simplify crashkernel reservation
On 2023/8/29 20:16, Baoquan He wrote:
> With the help of newly changed function parse_crashkernel() and
> generic reserve_crashkernel_generic(), crashkernel reservation can be
> simplified by steps:
>
> 1) Add a new header file , and define CRASH_ALIGN,
>CRASH_ADDR_LOW_MAX, CRASH_ADDR_HIGH_MAX and
>DEFAULT_CRASH_KERNEL_LOW_SIZE in ;
>
> 2) Add arch_reserve_crashkernel() to call parse_crashkernel() and
>reserve_crashkernel_generic();
>
> 3) Add ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION Kconfig in
>arch/arm64/Kconfig.
>
> The old reserve_crashkernel_low() and reserve_crashkernel() can be
> removed.
Reviewed-by: Zhen Lei
>
> Signed-off-by: Baoquan He
> ---
> arch/arm64/Kconfig | 3 +
> arch/arm64/include/asm/crash_core.h | 10 ++
> arch/arm64/mm/init.c| 140 ++--
> 3 files changed, 21 insertions(+), 132 deletions(-)
> create mode 100644 arch/arm64/include/asm/crash_core.h
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 29db061db9bb..07fb8c71339d 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1481,6 +1481,9 @@ config KEXEC_FILE
> for kernel and initramfs as opposed to list of segments as
> accepted by previous system call.
>
> +config ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION
> + def_bool CRASH_CORE
> +
> config KEXEC_SIG
> bool "Verify kernel signature during kexec_file_load() syscall"
> depends on KEXEC_FILE
> diff --git a/arch/arm64/include/asm/crash_core.h
> b/arch/arm64/include/asm/crash_core.h
> new file mode 100644
> index ..9f5c8d339f44
> --- /dev/null
> +++ b/arch/arm64/include/asm/crash_core.h
> @@ -0,0 +1,10 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef _ARM64_CRASH_CORE_H
> +#define _ARM64_CRASH_CORE_H
> +
> +/* Current arm64 boot protocol requires 2MB alignment */
> +#define CRASH_ALIGN SZ_2M
> +
> +#define CRASH_ADDR_LOW_MAX arm64_dma_phys_limit
> +#define CRASH_ADDR_HIGH_MAX (PHYS_MASK + 1)
> +#endif
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 4ad637508b75..48ab23531bb6 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -64,15 +64,6 @@ EXPORT_SYMBOL(memstart_addr);
> */
> phys_addr_t __ro_after_init arm64_dma_phys_limit;
>
> -/* Current arm64 boot protocol requires 2MB alignment */
> -#define CRASH_ALIGN SZ_2M
> -
> -#define CRASH_ADDR_LOW_MAX arm64_dma_phys_limit
> -#define CRASH_ADDR_HIGH_MAX (PHYS_MASK + 1)
> -#define CRASH_HIGH_SEARCH_BASE SZ_4G
> -
> -#define DEFAULT_CRASH_KERNEL_LOW_SIZE(128UL << 20)
> -
> /*
> * To make optimal use of block mappings when laying out the linear
> * mapping, round down the base of physical memory to a size that can
> @@ -100,140 +91,25 @@ phys_addr_t __ro_after_init arm64_dma_phys_limit;
> #define ARM64_MEMSTART_ALIGN (1UL << ARM64_MEMSTART_SHIFT)
> #endif
>
> -static int __init reserve_crashkernel_low(unsigned long long low_size)
> -{
> - unsigned long long low_base;
> -
> - low_base = memblock_phys_alloc_range(low_size, CRASH_ALIGN, 0,
> CRASH_ADDR_LOW_MAX);
> - if (!low_base) {
> - pr_err("cannot allocate crashkernel low memory
> (size:0x%llx).\n", low_size);
> - return -ENOMEM;
> - }
> -
> - pr_info("crashkernel low memory reserved: 0x%08llx - 0x%08llx (%lld
> MB)\n",
> - low_base, low_base + low_size, low_size >> 20);
> -
> - crashk_low_res.start = low_base;
> - crashk_low_res.end = low_base + low_size - 1;
> - insert_resource(_resource, _low_res);
> -
> - return 0;
> -}
> -
> -/*
> - * reserve_crashkernel() - reserves memory for crash kernel
> - *
> - * This function reserves memory area given in "crashkernel=" kernel command
> - * line parameter. The memory reserved is used by dump capture kernel when
> - * primary kernel is crashing.
> - */
> -static void __init reserve_crashkernel(void)
> +static void __init arch_reserve_crashkernel(void)
> {
> - unsigned long long crash_low_size = 0, search_base = 0;
> - unsigned long long crash_max = CRASH_ADDR_LOW_MAX;
> + unsigned long long low_size = 0;
> unsigned long long crash_base, crash_size;
> char *cmdline = boot_command_line;
> - bool fixed_base = false;
> bool high = false;
> int ret;
>
> if (!IS_ENABLED(CONFIG_KEXEC_CORE))
> return;
>
> - /* crashkernel=X[@offset] */
> ret = parse_crashkernel(cmdline, memblock_phys_mem_size(),
> - _size, _base, NULL, NULL);
> - if (ret == -ENOENT) {
> - ret = parse_crashkernel_high(cmdline, 0, _size,
> _base);
> - if (ret || !crash_size)
> - return;
> -
> - /*
> - * crashkernel=Y,low can be specified or not, but invalid value
> - * is not allowed.
> -
Re: [PATCH v2 6/8] x86: kdump: use generic interface to simplify crashkernel reservation code
On 2023/8/29 20:16, Baoquan He wrote:
> With the help of newly changed function parse_crashkernel() and
> generic reserve_crashkernel_generic(), crashkernel reservation can be
> simplified by steps:
>
> 1) Add a new header file , and define CRASH_ALIGN,
>CRASH_ADDR_LOW_MAX, CRASH_ADDR_HIGH_MAX and
>DEFAULT_CRASH_KERNEL_LOW_SIZE in ;
>
> 2) Add arch_reserve_crashkernel() to call parse_crashkernel() and
>reserve_crashkernel_generic(), and do the ARCH specific work if
>needed.
>
> 3) Add ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION Kconfig in
>arch/x86/Kconfig.
>
> When adding DEFAULT_CRASH_KERNEL_LOW_SIZE, add crash_low_size_default()
> to calculate crashkernel low memory because x86_64 has special
> requirement.
>
> The old reserve_crashkernel_low() and reserve_crashkernel() can be
> removed.
>
> Signed-off-by: Baoquan He
> ---
> arch/x86/Kconfig | 3 +
> arch/x86/include/asm/crash_core.h | 34 +++
> arch/x86/kernel/setup.c | 144 --
> 3 files changed, 53 insertions(+), 128 deletions(-)
> create mode 100644 arch/x86/include/asm/crash_core.h
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 8d9e4b362572..c4539dc35985 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -2037,6 +2037,9 @@ config KEXEC_FILE
> config ARCH_HAS_KEXEC_PURGATORY
> def_bool KEXEC_FILE
>
> +config ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION
> + def_bool CRASH_CORE
> +
> config KEXEC_SIG
> bool "Verify kernel signature during kexec_file_load() syscall"
> depends on KEXEC_FILE
> diff --git a/arch/x86/include/asm/crash_core.h
> b/arch/x86/include/asm/crash_core.h
> new file mode 100644
> index ..5fc5e4f94521
> --- /dev/null
> +++ b/arch/x86/include/asm/crash_core.h
> @@ -0,0 +1,34 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _X86_CRASH_CORE_H
> +#define _X86_CRASH_CORE_H
> +
> +/* 16M alignment for crash kernel regions */
> +#define CRASH_ALIGN SZ_16M
> +
> +/*
> + * Keep the crash kernel below this limit.
> + *
> + * Earlier 32-bits kernels would limit the kernel to the low 512 MB range
> + * due to mapping restrictions.
> + *
> + * 64-bit kdump kernels need to be restricted to be under 64 TB, which is
> + * the upper limit of system RAM in 4-level paging mode. Since the kdump
> + * jump could be from 5-level paging to 4-level paging, the jump will fail if
> + * the kernel is put above 64 TB, and during the 1st kernel bootup there's
> + * no good way to detect the paging mode of the target kernel which will be
> + * loaded for dumping.
> + */
> +
> +#ifdef CONFIG_X86_32
> +# define CRASH_ADDR_LOW_MAX SZ_512M
> +# define CRASH_ADDR_HIGH_MAXSZ_512M
> +#else
> +# define CRASH_ADDR_LOW_MAX SZ_4G
> +# define CRASH_ADDR_HIGH_MAXSZ_64T
> +#endif
> +
> +# define DEFAULT_CRASH_KERNEL_LOW_SIZE crash_low_size_default()
> +
> +extern unsigned long crash_low_size_default(void);
> +
> +#endif /* _X86_CRASH_CORE_H */
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 382c66d2cf71..559a5c4141db 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -474,152 +474,40 @@ static void __init
> memblock_x86_reserve_range_setup_data(void)
> /*
> * - Crashkernel reservation --
> */
> -
> -/* 16M alignment for crash kernel regions */
> -#define CRASH_ALIGN SZ_16M
> -
> -/*
> - * Keep the crash kernel below this limit.
> - *
> - * Earlier 32-bits kernels would limit the kernel to the low 512 MB range
> - * due to mapping restrictions.
> - *
> - * 64-bit kdump kernels need to be restricted to be under 64 TB, which is
> - * the upper limit of system RAM in 4-level paging mode. Since the kdump
> - * jump could be from 5-level paging to 4-level paging, the jump will fail if
> - * the kernel is put above 64 TB, and during the 1st kernel bootup there's
> - * no good way to detect the paging mode of the target kernel which will be
> - * loaded for dumping.
> - */
> -#ifdef CONFIG_X86_32
> -# define CRASH_ADDR_LOW_MAX SZ_512M
> -# define CRASH_ADDR_HIGH_MAX SZ_512M
> -#else
> -# define CRASH_ADDR_LOW_MAX SZ_4G
> -# define CRASH_ADDR_HIGH_MAX SZ_64T
> -#endif
> -
> -static int __init reserve_crashkernel_low(void)
> +unsigned long crash_low_size_default(void)
> {
> #ifdef CONFIG_X86_64
> - unsigned long long base, low_base = 0, low_size = 0;
> - unsigned long low_mem_limit;
> - int ret;
> -
> - low_mem_limit = min(memblock_phys_mem_size(), CRASH_ADDR_LOW_MAX);
> -
> - /* crashkernel=Y,low */
> - ret = parse_crashkernel_low(boot_command_line, low_mem_limit,
> _size, );
> - if (ret) {
> - /*
> - * two parts from kernel/dma/swiotlb.c:
> - * -swiotlb size: user-specified with swiotlb= or default.
> - *
> - * -swiotlb overflow buffer: now hardcoded to 32k. We round it
> - * to 8M for other
Re: [PATCH v2 4/8] crash_core: add generic function to do reservation
On 2023/8/29 20:16, Baoquan He wrote:
> In architecture like x86_64, arm64 and riscv, they have vast virtual
> address space and usually have huge physical memory RAM. Their
> crashkernel reservation doesn't have to be limited under 4G RAM,
> but can be extended to the whole physical memory via crashkernel=,high
> support.
>
> Now add function reserve_crashkernel_generic() to reserve crashkernel
> memory if users specify any case of kernel pamameters, like
> crashkernel=xM[@offset] or crashkernel=,high|low.
>
> This is preparation to simplify code of crashkernel=,high support
> in architecutures.
>
> Signed-off-by: Baoquan He
> ---
> include/linux/crash_core.h | 34 ++--
> kernel/crash_core.c| 109 -
> 2 files changed, 136 insertions(+), 7 deletions(-)
>
> diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
> index 85260bf4a734..2f732493e922 100644
> --- a/include/linux/crash_core.h
> +++ b/include/linux/crash_core.h
> @@ -77,12 +77,6 @@ Elf_Word *append_elf_note(Elf_Word *buf, char *name,
> unsigned int type,
> void *data, size_t data_len);
> void final_note(Elf_Word *buf);
>
> -#ifdef CONFIG_ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION
> -#ifndef DEFAULT_CRASH_KERNEL_LOW_SIZE
> -#define DEFAULT_CRASH_KERNEL_LOW_SIZE (128UL << 20)
> -#endif
> -#endif
> -
> int __init parse_crashkernel(char *cmdline, unsigned long long system_ram,
> unsigned long long *crash_size, unsigned long long *crash_base,
> unsigned long long *low_size, bool *high);
> @@ -91,4 +85,32 @@ int parse_crashkernel_high(char *cmdline, unsigned long
> long system_ram,
> int parse_crashkernel_low(char *cmdline, unsigned long long system_ram,
> unsigned long long *crash_size, unsigned long long *crash_base);
>
> +#ifdef CONFIG_ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION
> +#ifndef DEFAULT_CRASH_KERNEL_LOW_SIZE
> +#define DEFAULT_CRASH_KERNEL_LOW_SIZE(128UL << 20)
> +#endif
> +#ifndef CRASH_ALIGN
> +#define CRASH_ALIGN SZ_2M
> +#endif
> +#ifndef CRASH_ADDR_LOW_MAX
> +#define CRASH_ADDR_LOW_MAX SZ_4G
> +#endif
> +#ifndef CRASH_ADDR_HIGH_MAX
> +#define CRASH_ADDR_HIGH_MAX memblock_end_of_DRAM()
> +#endif
> +
> +void __init reserve_crashkernel_generic(char *cmdline,
> + unsigned long long crash_size,
> + unsigned long long crash_base,
> + unsigned long long crash_low_size,
> + bool high);
> +#else
> +static inline void __init reserve_crashkernel_generic(char *cmdline,
> + unsigned long long crash_size,
> + unsigned long long crash_base,
> + unsigned long long crash_low_size,
> + bool high)
> +{}
> +#endif
> +
> #endif /* LINUX_CRASH_CORE_H */
> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
> index 355b0ab5189c..6bc00cc390b5 100644
> --- a/kernel/crash_core.c
> +++ b/kernel/crash_core.c
> @@ -5,11 +5,13 @@
> */
>
> #include
> -#include
> #include
> #include
> #include
> #include
> +#include
> +#include
> +#include
>
> #include
> #include
> @@ -349,6 +351,111 @@ static int __init parse_crashkernel_dummy(char *arg)
> }
> early_param("crashkernel", parse_crashkernel_dummy);
>
> +#ifdef CONFIG_ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION
> +static int __init reserve_crashkernel_low(unsigned long long low_size)
> +{
> +#ifdef CONFIG_64BIT
> + unsigned long long low_base;
> +
> + low_base = memblock_phys_alloc_range(low_size, CRASH_ALIGN, 0,
> CRASH_ADDR_LOW_MAX);
> + if (!low_base) {
> + pr_err("cannot allocate crashkernel low memory
> (size:0x%llx).\n", low_size);
> + return -ENOMEM;
> + }
> +
> + pr_info("crashkernel low memory reserved: 0x%08llx - 0x%08llx (%lld
> MB)\n",
> + low_base, low_base + low_size, low_size >> 20);
> +
> + crashk_low_res.start = low_base;
> + crashk_low_res.end = low_base + low_size - 1;
> + insert_resource(_resource, _low_res);
> +#endif
> + return 0;
> +}
> +
> +void __init reserve_crashkernel_generic(char *cmdline,
> + unsigned long long crash_size,
> + unsigned long long crash_base,
> + unsigned long long crash_low_size,
> + bool high)
> +{
> + unsigned long long search_end = CRASH_ADDR_LOW_MAX, search_base = 0;
> + bool fixed_base = false;
> +
> + /* User specifies base address explicitly. */
> + if (crash_base) {
> + fixed_base = true;
> + search_base = crash_base;
> + search_end = crash_base + crash_size;
> + }
> +
> + if (high) {
It might be a little clearer to use "else if (high) {"
> + search_base = CRASH_ADDR_LOW_MAX;
> + search_end = CRASH_ADDR_HIGH_MAX;
> + }
> +
> +retry:
> + crash_base = memblock_phys_alloc_range(crash_size,
Re: [PATCH v2 3/8] crash_core: change parse_crashkernel() to support crashkernel=,high|low parsing
On 2023/8/29 20:16, Baoquan He wrote:
> Now parse_crashkernel() is a real entry point for all kinds of
> crahskernel parsing on any architecture.
>
> And wrap the crahskernel=,high|low handling inside
> CONFIG_ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION ifdeffery scope.
>
> Signed-off-by: Baoquan He
> ---
> include/linux/crash_core.h | 6 ++
> kernel/crash_core.c| 28 +++-
> 2 files changed, 33 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
> index 2e76289699ff..85260bf4a734 100644
> --- a/include/linux/crash_core.h
> +++ b/include/linux/crash_core.h
> @@ -77,6 +77,12 @@ Elf_Word *append_elf_note(Elf_Word *buf, char *name,
> unsigned int type,
> void *data, size_t data_len);
> void final_note(Elf_Word *buf);
>
> +#ifdef CONFIG_ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION
> +#ifndef DEFAULT_CRASH_KERNEL_LOW_SIZE
> +#define DEFAULT_CRASH_KERNEL_LOW_SIZE (128UL << 20)
> +#endif
> +#endif
> +
> int __init parse_crashkernel(char *cmdline, unsigned long long system_ram,
> unsigned long long *crash_size, unsigned long long *crash_base,
> unsigned long long *low_size, bool *high);
> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
> index f6a5c219e2e1..355b0ab5189c 100644
> --- a/kernel/crash_core.c
> +++ b/kernel/crash_core.c
> @@ -276,6 +276,9 @@ static int __init __parse_crashkernel(char *cmdline,
> /*
> * That function is the entry point for command line parsing and should be
> * called from the arch-specific code.
> + *
> + * If crashkernel=,high|low is supported on architecture, non-NULL values
> + * should be passed to parameters 'low_size' and 'high'.
> */
> int __init parse_crashkernel(char *cmdline,
>unsigned long long system_ram,
> @@ -291,7 +294,30 @@ int __init parse_crashkernel(char *cmdline,
> crash_base, NULL);
> if (!high)
> return ret;
> -
> +#ifdef CONFIG_ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION
> + else if (ret == -ENOENT) {
> + ret = __parse_crashkernel(cmdline, 0, crash_size,
> + crash_base, suffix_tbl[SUFFIX_HIGH]);
> + if (ret || !*crash_size)
> + return -1;
Change -1 to -EINVAL?
> +
> + /*
> + * crashkernel=Y,low can be specified or not, but invalid value
> + * is not allowed.
> + */
> + ret = __parse_crashkernel(cmdline, 0, low_size,
> + crash_base, suffix_tbl[SUFFIX_LOW]);
> + if (ret == -ENOENT)
> + *low_size = DEFAULT_CRASH_KERNEL_LOW_SIZE;
> + else if (ret)
> + return -1;
return ret;
> +
> + *high = true;
> + } else if (ret || !*crash_size) {
This check can be moved outside of #ifdef. Because even '!high', it's completely
applicable. The overall adjustment is as follows:
- if (!high)
- return ret;
#ifdef CONFIG_ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION
if (high && ret == -ENOENT) {
... ...
if (ret || !*crash_size)//parse HIGH
... ...
}
//At this point, *crash_size is not 0 and ret is 0.
//We can also delete if (!*crash_size) above because it will be checked
later.
#endif
if (!*crash_size)
ret = -EINVAL;
return ret;
- return 0;
> + /* The specified value is invalid */
> + return -1;
> + }
> +#endif
> return 0;
> }
>
>
--
Regards,
Zhen Lei
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2 2/8] crash_core: change the prototype of function parse_crashkernel()
On 2023/8/29 20:16, Baoquan He wrote:
> Add two parameters 'low_size' and 'high' to function parse_crashkernel(),
> later crashkernel=,high|low parsing will be added. Make adjustments in all
> call sites of parse_crashkernel() in arch.
Reviewed-by: Zhen Lei
>
> Signed-off-by: Baoquan He
> ---
> arch/arm/kernel/setup.c | 3 ++-
> arch/arm64/mm/init.c | 2 +-
> arch/ia64/kernel/setup.c | 2 +-
> arch/loongarch/kernel/setup.c| 4 +++-
> arch/mips/kernel/setup.c | 3 ++-
> arch/powerpc/kernel/fadump.c | 2 +-
> arch/powerpc/kexec/core.c| 2 +-
> arch/powerpc/mm/nohash/kaslr_booke.c | 2 +-
> arch/riscv/mm/init.c | 2 +-
> arch/s390/kernel/setup.c | 4 ++--
> arch/sh/kernel/machine_kexec.c | 2 +-
> arch/x86/kernel/setup.c | 3 ++-
> include/linux/crash_core.h | 3 ++-
> kernel/crash_core.c | 15 ---
> 14 files changed, 32 insertions(+), 17 deletions(-)
>
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index c66b560562b3..e2bb7afd0683 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -1010,7 +1010,8 @@ static void __init reserve_crashkernel(void)
>
> total_mem = get_total_mem();
> ret = parse_crashkernel(boot_command_line, total_mem,
> - _size, _base);
> + _size, _base,
> + NULL, NULL);
> /* invalid value specified or crashkernel=0 */
> if (ret || !crash_size)
> return;
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 4fcb88a445ef..4ad637508b75 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -142,7 +142,7 @@ static void __init reserve_crashkernel(void)
>
> /* crashkernel=X[@offset] */
> ret = parse_crashkernel(cmdline, memblock_phys_mem_size(),
> - _size, _base);
> + _size, _base, NULL, NULL);
> if (ret == -ENOENT) {
> ret = parse_crashkernel_high(cmdline, 0, _size,
> _base);
> if (ret || !crash_size)
> diff --git a/arch/ia64/kernel/setup.c b/arch/ia64/kernel/setup.c
> index 5a55ac82c13a..4faea2d2cf07 100644
> --- a/arch/ia64/kernel/setup.c
> +++ b/arch/ia64/kernel/setup.c
> @@ -277,7 +277,7 @@ static void __init setup_crashkernel(unsigned long total,
> int *n)
> int ret;
>
> ret = parse_crashkernel(boot_command_line, total,
> - , );
> + , , NULL, NULL);
> if (ret == 0 && size > 0) {
> if (!base) {
> sort_regions(rsvd_region, *n);
> diff --git a/arch/loongarch/kernel/setup.c b/arch/loongarch/kernel/setup.c
> index 9d830ab4e302..776a068d8718 100644
> --- a/arch/loongarch/kernel/setup.c
> +++ b/arch/loongarch/kernel/setup.c
> @@ -267,7 +267,9 @@ static void __init arch_parse_crashkernel(void)
> unsigned long long crash_base, crash_size;
>
> total_mem = memblock_phys_mem_size();
> - ret = parse_crashkernel(boot_command_line, total_mem, _size,
> _base);
> + ret = parse_crashkernel(boot_command_line, total_mem,
> + _size, _base,
> + NULL, NULL);
> if (ret < 0 || crash_size <= 0)
> return;
>
> diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
> index cb871eb784a7..08321c945ac4 100644
> --- a/arch/mips/kernel/setup.c
> +++ b/arch/mips/kernel/setup.c
> @@ -460,7 +460,8 @@ static void __init mips_parse_crashkernel(void)
>
> total_mem = memblock_phys_mem_size();
> ret = parse_crashkernel(boot_command_line, total_mem,
> - _size, _base);
> + _size, _base,
> + NULL, NULL);
> if (ret != 0 || crash_size <= 0)
> return;
>
> diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
> index ea0a073abd96..7dbdeba56e74 100644
> --- a/arch/powerpc/kernel/fadump.c
> +++ b/arch/powerpc/kernel/fadump.c
> @@ -313,7 +313,7 @@ static __init u64 fadump_calculate_reserve_size(void)
>* memory at a predefined offset.
>*/
> ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
> - , );
> + , , NULL, NULL);
> if (ret == 0 && size > 0) {
> unsigned long max_size;
>
> diff --git a/arch/powerpc/kexec/core.c b/arch/powerpc/kexec/core.c
> index de64c7962991..9346c960b296 100644
> --- a/arch/powerpc/kexec/core.c
> +++ b/arch/powerpc/kexec/core.c
> @@ -109,7 +109,7 @@ void __init reserve_crashkernel(void)
> total_mem_sz = memory_limit ? memory_limit : memblock_phys_mem_size();
> /* use common parsing */
> ret = parse_crashkernel(boot_command_line, total_mem_sz,
> -
Re: [PATCH v2 1/8] crash_core.c: remove unnecessary parameter of function
On 2023/8/29 20:16, Baoquan He wrote:
> In all call sites of __parse_crashkernel(), the parameter 'name' is
> hardcoded as "crashkernel=". So remove the unnecessary parameter 'name',
> add local varibale 'name' inside __parse_crashkernel() instead.
Reviewed-by: Zhen Lei
>
> Signed-off-by: Baoquan He
> ---
> kernel/crash_core.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
> index 90ce1dfd591c..f27b4e45d410 100644
> --- a/kernel/crash_core.c
> +++ b/kernel/crash_core.c
> @@ -241,11 +241,11 @@ static int __init __parse_crashkernel(char *cmdline,
>unsigned long long system_ram,
>unsigned long long *crash_size,
>unsigned long long *crash_base,
> - const char *name,
>const char *suffix)
> {
> char*first_colon, *first_space;
> char*ck_cmdline;
> + char*name = "crashkernel=";
>
> BUG_ON(!crash_size || !crash_base);
> *crash_size = 0;
> @@ -283,7 +283,7 @@ int __init parse_crashkernel(char *cmdline,
>unsigned long long *crash_base)
> {
> return __parse_crashkernel(cmdline, system_ram, crash_size, crash_base,
> - "crashkernel=", NULL);
> + NULL);
> }
>
> int __init parse_crashkernel_high(char *cmdline,
> @@ -292,7 +292,7 @@ int __init parse_crashkernel_high(char *cmdline,
>unsigned long long *crash_base)
> {
> return __parse_crashkernel(cmdline, system_ram, crash_size, crash_base,
> - "crashkernel=", suffix_tbl[SUFFIX_HIGH]);
> + suffix_tbl[SUFFIX_HIGH]);
> }
>
> int __init parse_crashkernel_low(char *cmdline,
> @@ -301,7 +301,7 @@ int __init parse_crashkernel_low(char *cmdline,
>unsigned long long *crash_base)
> {
> return __parse_crashkernel(cmdline, system_ram, crash_size, crash_base,
> - "crashkernel=", suffix_tbl[SUFFIX_LOW]);
> + suffix_tbl[SUFFIX_LOW]);
> }
>
> /*
>
--
Regards,
Zhen Lei
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 0/3] arm64: kdump: Restore the write protection for the crashkernel memory region
On 2023/7/24 21:34, Baoquan He wrote: > Hi, > > On 07/21/23 at 04:17pm, thunder.leiz...@huaweicloud.com wrote: >> From: Zhen Lei >> >> Unlike in the past, the low memory allocation direction of the crashkernel is >> changed from top-down to bottom-up. As long as the DMA zone has sufficient >> continuous free memory, the allocated crashkernel low memory must meet the >> requirements. The allocation direction of crashkernel high memory remains >> unchanged, that is, top-down. As long as the high memory(above DMA zone) has >> sufficient continuous free memory, the allocated crashkernel high memory must >> meet the requirements. In this way, with the restoration of the original >> page-level mapping and the implementation of the >> arch_kexec_protect_crashkres() >> function, write protection for the crashkernel memory region can be >> supported. >> >> Of course, if the high memory or low memory cannot meet the initial >> requirements, >> that is, fall back is required. In this case, write protection is not >> supported >> because the newly allocated memory is not page-level mapped. >> >> Because the original retry process is eliminated, the new process looks >> clearer >> and is a simple sequential flow. > > Thanks, but no. > > The pure semantics and the corresponding implementation have been > complicated, it's not worth adding so much more complication to it > just because of one inessential feature. It's just that the code looks like if..else branches are a little more, but the idea is not complicated. 1. Reserve low memory bottom-up(start from 0), reserve high memory top-down(start from CRASH_ADDR_HIGH_MAX) 2. zone_sizes_init() update arm64_dma_phys_limit, now CRASH_ADDR_LOW_MAX is known. 3. Use CRASH_ADDR_LOW_MAX to verify the preserved low memory and high memory, OK or fall back. To be honest, the code can be simplified a lot if we don't support the following: - If reservation from the high memory failed, the kernel falls back to searching the low memory with the specified size in crashkernel=,high. If it succeeds, no further reservation for low memory is needed. > > If stomp really happened and destroy the loaded kdump kernel, the write > protection truly can save kdump to make vmcore dumping succeed. While > without write protection, we at least know that stomp happened by the > later checksum verifycation. That's an advantage over write protection > which silently ignores the stomp, right? Theoretically, write protection can catch exceptions in a timely manner and ensure that kdump is successful. If the problem is easy to reproduce, it doesn't matter if it fails once. However, for versions that have been delivered for commercial use, the customer may not give the second chance. > > So, due to the low cost performance, from people maintaining and > understanding the code point of view, I would like to NACK this series. > BUT since all these code changes are added into arm64 arch, I won't > object if arm64 maintainers wants to pikc them up. This new idea is not bad. After all, before commercial use, "fall back" can be avoided by adjusting crashkernel size in command line. So the problem is pretty much solved. > > By the way, as we have talked before, arm64 lacks the loaded kernel > checksum storing and verifying, would you like to add that? OKay. > > Thanks > Baoquan > > . > -- Regards, Zhen Lei ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 1/3] arm64: kdump: Allocate crash low memory in the bottom-up direction
On 2023/7/22 5:22, kernel test robot wrote: > Hi, > > kernel test robot noticed the following build errors: > > [auto build test ERROR on arm64/for-next/core] > [also build test ERROR on linus/master v6.5-rc2 next-20230721] > [If your patch is applied to the wrong git tree, kindly drop us a note. > And when submitting patch, we suggest to use '--base' as documented in > https://git-scm.com/docs/git-format-patch#_base_tree_information] > > url: > https://github.com/intel-lab-lkp/linux/commits/thunder-leizhen-huaweicloud-com/arm64-kdump-Allocate-crash-low-memory-in-the-bottom-up-direction/20230721-162312 > base: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git > for-next/core > patch link: > https://lore.kernel.org/r/20230721081726.882-2-thunder.leizhen%40huaweicloud.com > patch subject: [PATCH 1/3] arm64: kdump: Allocate crash low memory in the > bottom-up direction > config: arm64-allnoconfig > (https://download.01.org/0day-ci/archive/20230722/202307220500.1i73fz5z-...@intel.com/config) > compiler: aarch64-linux-gcc (GCC) 12.3.0 > reproduce: > (https://download.01.org/0day-ci/archive/20230722/202307220500.1i73fz5z-...@intel.com/reproduce) > > If you fix the issue in a separate patch/commit (i.e. not just a new version > of > the same patch/commit), kindly add following tags > | Reported-by: kernel test robot > | Closes: > https://lore.kernel.org/oe-kbuild-all/202307220500.1i73fz5z-...@intel.com/ > > All errors (new ones prefixed by >>): Oh, thanks. I got it. The CONFIG_KEXEC_CORE build control is move into reserve_crashkernel(). Function late_reserve_crashkernel() needs to do the same. I forgot to test turning off options like CONFIG_KEXEC_CORE. I will do it tomorrow. Sorry. diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c index b544ed0ab04193d..d444721011d0b2f 100644 --- a/arch/arm64/mm/init.c +++ b/arch/arm64/mm/init.c @@ -122,6 +122,9 @@ static void __init late_reserve_crashkernel(void) unsigned long long low_base, low_size; unsigned long long crash_base, crash_size; + if (!IS_ENABLED(CONFIG_KEXEC_CORE)) + return; > >aarch64-linux-ld: arch/arm64/mm/init.o: in function > `late_reserve_crashkernel': >>> init.c:(.init.text+0x58): undefined reference to `crashk_res' >aarch64-linux-ld: arch/arm64/mm/init.o: relocation > R_AARCH64_ADR_PREL_PG_HI21 against symbol `crashk_res' which may bind > externally can not be used when making a shared object; recompile with -fPIC >init.c:(.init.text+0x58): dangerous relocation: unsupported relocation >>> aarch64-linux-ld: init.c:(.init.text+0x5c): undefined reference to >>> `crashk_res' >>> aarch64-linux-ld: init.c:(.init.text+0x88): undefined reference to >>> `crashk_low_res' >aarch64-linux-ld: arch/arm64/mm/init.o: relocation > R_AARCH64_ADR_PREL_PG_HI21 against symbol `crashk_low_res' which may bind > externally can not be used when making a shared object; recompile with -fPIC >init.c:(.init.text+0x88): dangerous relocation: unsupported relocation >aarch64-linux-ld: init.c:(.init.text+0x90): undefined reference to > `crashk_res' >aarch64-linux-ld: init.c:(.init.text+0x9c): undefined reference to > `crashk_low_res' >aarch64-linux-ld: init.c:(.init.text+0xd0): undefined reference to > `crashk_res' >aarch64-linux-ld: init.c:(.init.text+0x13c): undefined reference to > `crashk_res' >aarch64-linux-ld: init.c:(.init.text+0x150): undefined reference to > `crashk_res' >aarch64-linux-ld: init.c:(.init.text+0x18c): undefined reference to > `crashk_low_res' >aarch64-linux-ld: init.c:(.init.text+0x1b0): undefined reference to > `crashk_low_res' >aarch64-linux-ld: init.c:(.init.text+0x204): undefined reference to > `crashk_low_res' >aarch64-linux-ld: init.c:(.init.text+0x234): undefined reference to > `crashk_low_res' >aarch64-linux-ld: init.c:(.init.text+0x248): undefined reference to > `crashk_low_res' >aarch64-linux-ld: arch/arm64/mm/init.o:init.c:(.init.text+0x25c): more > undefined references to `crashk_low_res' follow > -- Regards, Zhen Lei ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v6 2/2] Documentation: add kdump.rst to present crashkernel reservation on arm64
On 2023/5/15 14:02, Baoquan He wrote: > People complained the crashkernel reservation code flow is hard to > follow, so add this document to explain the background, concepts and > implementation of crashkernel reservation on arm64. Hope this can help > people to understand it more easily. Reviewed-by: Zhen Lei > > Signed-off-by: Baoquan He > --- > Documentation/arm64/kdump.rst | 103 ++ > 1 file changed, 103 insertions(+) > create mode 100644 Documentation/arm64/kdump.rst > > diff --git a/Documentation/arm64/kdump.rst b/Documentation/arm64/kdump.rst > new file mode 100644 > index ..78b22017c490 > --- /dev/null > +++ b/Documentation/arm64/kdump.rst > @@ -0,0 +1,103 @@ > +=== > +crashkernel memory reservation on arm64 > +=== > + > +Author: Baoquan He > + > +Kdump mechanism is utilized to capture corrupted kernel's vmcore so > +that people can analyze it to get the root cause of corruption. In > +order to do that, a preliminarily reserved memory is needed to load > +in kdump kernel, and switch to kdump kernel to boot up and run if > +corruption happened. > + > +That reserved memory for kdump is adapted to be able to minimally > +accommodate kdump kernel to boot and run, and user space programs > +running to do the vmcore collecting. > + > +Kernel parameter > + > +Through kernel parameter like below, memory can be reserved > +accordingly during early stage of 1st kernel's bootup so that > +continuous large chunk of memomy can be found and reserved. Meanwhile, > +the need of low memory need be considered if crashkernel is reserved > +in high memory area. > + > +- crashkernel=size@offset > +- crashkernel=size > +- crashkernel=size,high crashkernel=size,low > + > +Low memory and high memory > +=== > +What is low memory and high memory? In kdump reservation, low memory > +means the memory area under a specific limitation, and it's usually > +decided by the lowest addressing bits of PCI devices which kdump kernel > +need rely on to boot up and collect vmcore successfully. Those devices > +not related to vmcore dumping can be ignored, e.g on x86, those i2c may > +only be able to access 24bits addressing area, but kdump kernel still > +take 4G as the limitation because all known devices that kdump kernel > +cares about have 32bits addressing ability. On arm64, the low memory > +upper boundary is not fixed, it's 1G on RPi4 platform, while 4G on normal > +arm64 system. On the special system with CONFIG_ZONE_DMA|DMA32 disabled, > +the whole system RAM is low memory. Except of low memory, all the rest > +of system RAM is high memory which kernel and user space programs can > +require to allocate and use. > + > +Implementation > +== > +1)crashkernel=size@offset > +- > +crashkernel memory must be reserved at the user specified region, otherwise > +fail if already occupied. > + > + > +2) crashkernel=size > +--- > +crashkernel memory region will be reserved in any available position > +according to searching order. > + > +Firstly, it searches the low memory area for an available region with > specified > +size. > + > +Secondly, if searching low memory failed, fallback to search the high memory > +area with the specified size. Meanwhile, if the reservation in high memory > +succeeds, a default reservation in low memory will be done, the current > default > +value is 128M which is satisfying the low memory needs, e.g pci device driver > +initialization. > + > +If both the above searching failed, the reservation will fail finally. > + > +Note: crashkernel=size is recommended option among crashkernel kernel > +parameters. With it, user doesn't need to know much about system memory > +information, just need to specify whatever memory kdump kernel needs to > +make vmcore dumping succeed. > + > +3) crashkernel=size,high crashkernel=size,low > + > +crashkernel=size,high is an important supplement to crashkernel=size. It > +allows user to precisely specify how much memory need be allocated from > +high memory, and how much memory is needed from low memory. On system > +with large memory, low memory is small and precious since some kernel > +feature and many devices can only request memory from the area, while > +requiring a large chunk of continuous memory from high memory area doesn't > +matter much and can satisfy most of kernel and almost all user space > +programs' requirement. In such case, only a small part of necessary memory > +from low memory area can satisfy needs. With it, the 1st kernel's normal > +running won't be impacted because of limited low memory resource. > + > +To reserve memory for crashkernel=size,high, firstly, searching is tried in > +high memory region. If reservation succeeds, low memory reservaton will be > +done subsequently. > + > +Secondly, if
Re: [PATCH v6 RESEND 1/2] arm64: kdump: simplify the reservation behaviour of crashkernel=,high
On 2023/5/15 17:54, Baoquan He wrote:
> On arm64, reservation for 'crashkernel=xM,high' is taken by searching for
> suitable memory region top down. If the 'xM' of crashkernel high memory
> is reserved from high memory successfully, it will try to reserve
> crashkernel low memory later accoringly. Otherwise, it will try to search
> low memory area for the 'xM' suitable region. Please see the details in
> Documentation/admin-guide/kernel-parameters.txt.
>
> While we observed an unexpected case where a reserved region crosses the
> high and low meomry boundary. E.g on a system with 4G as low memory end,
> user added the kernel parameters like: 'crashkernel=512M,high', it could
> finally have [4G-126M, 4G+386M], [1G, 1G+128M] regions in running kernel.
> The crashkernel high region crossing low and high memory boudary will bring
> issues:
>
> 1) For crashkernel=x,high, if getting crashkernel high region across
> low and high memory boundary, then user will see two memory regions in
> low memory, and one memory region in high memory. The two crashkernel
> low memory regions are confusing as shown in above example.
>
> 2) If people explicityly specify "crashkernel=x,high crashkernel=y,low"
> and y <= 128M, when crashkernel high region crosses low and high memory
> boundary and the part of crashkernel high reservation below boundary is
> bigger than y, the expected crahskernel low reservation will be skipped.
> But the expected crashkernel high reservation is shrank and could not
> satisfy user space requirement.
>
> 3) The crossing boundary behaviour of crahskernel high reservation is
> different than x86 arch. On x86_64, the low memory end is 4G fixedly,
> and the memory near 4G is reserved by system, e.g for mapping firmware,
> pci mapping, so the crashkernel reservation crossing boundary never happens.
>>From distros point of view, this brings inconsistency and confusion. Users
> need to dig into x86 and arm64 system details to find out why.
>
> For kernel itself, the impact of issue 3) could be slight. While issue
> 1) and 2) cause actual impact because it brings obscure semantics and
> behaviour to crashkernel=,high reservation.
>
> Here, for crashkernel=xM,high, search the high memory for the suitable
> region only in high memory. If failed, try reserving the suitable
> region only in low memory. Like this, the crashkernel high region will
> only exist in high memory, and crashkernel low region only exists in low
> memory. The reservation behaviour for crashkernel=,high is clearer and
> simpler.
>
> Note: RPi4 has different zone ranges than normal memory. Its DMA zone is
> 0~1G, and DMA32 zone is 1G~4G if CONFIG_ZONE_DMA|DMA32 are enabled by
> default. The low memory end is 1G in order to validate all devices, high
> memory starts at 1G memory. However, for being consistent with normla
normla --> normal
> arm64 system, its low memory end is still 1G, while reserving crashkernel
> high memory from 4G if crashkernel=size,high specified. This will remove
> confusion.
Reviewed-by: Zhen Lei
>
> With above change applied, summary of arm64 crashkernel reservation range:
> 1)
> RPi4(zone DMA:0~1G; DMA32:1G~4G):
> crashkernel=size
> 0~1G: low memory | 1G~top: high memory
>
> crashkernel=size,high
> 0~1G: low memory | 4G~top: high memory
>
> 2)
> Other normal system:
> crashkernel=size
> crashkernel=size,high
> 0~4G: low memory | 4G~top: high memory
>
> 3)
> Systems w/o zone DMA|DMA32
> crashkernel=size
> crashkernel=size,high
> 0~top: low memory
>
> Signed-off-by: Baoquan He
> Reviewed-by: Catalin Marinas
> ---
> v6-RESEND:
> - Remove the relic of local patch merging at the end of patch log.
> - Add Catalin's Reviewed-by tag.
>
> arch/arm64/mm/init.c | 44 ++--
> 1 file changed, 34 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 66e70ca47680..c28c2c8483cc 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -69,6 +69,7 @@ phys_addr_t __ro_after_init arm64_dma_phys_limit;
>
> #define CRASH_ADDR_LOW_MAX arm64_dma_phys_limit
> #define CRASH_ADDR_HIGH_MAX (PHYS_MASK + 1)
> +#define CRASH_HIGH_SEARCH_BASE SZ_4G
>
> #define DEFAULT_CRASH_KERNEL_LOW_SIZE(128UL << 20)
>
> @@ -101,12 +102,13 @@ static int __init reserve_crashkernel_low(unsigned long
> long low_size)
> */
> static void __init reserve_crashkernel(void)
> {
> - unsigned long long crash_base, crash_size;
> - unsigned long long crash_low_size = 0;
> + unsigned long long crash_low_size = 0, search_base = 0;
> unsigned long long crash_max = CRASH_ADDR_LOW_MAX;
> + unsigned long long crash_base, crash_size;
> char *cmdline = boot_command_line;
> - int ret;
> bool fixed_base = false;
> + bool high = false;
> + int ret;
>
> if (!IS_ENABLED(CONFIG_KEXEC_CORE))
> return;
> @@ -129,7 +131,9 @@ static
Re: [PATCH 6/6] kexec: enable kexec_crash_size to support two crash kernel regions
On 2023/5/31 17:53, Baoquan He wrote:
> On 05/27/23 at 08:34pm, Zhen Lei wrote:
>> The crashk_low_res should be considered by /sys/kernel/kexec_crash_size
>> to support two crash kernel regions. Since crashk_res manages the memory
>> with high address and crashk_low_res manages the memory with low address,
>> crashk_low_res is shrunken only when all crashk_res is shrunken. And
>> because when there is only one crash kernel region, crashk_res is always
>> used. Therefore, if all crashk_res is shrunken and crashk_low_res still
>> exists, swap them.
>
> This looks good, otherwise someone else won't stop attempting to add
> support of crashk_low_res shrinking. Not sure if this will bring corner
> case issue in testing, let's see. For the patch log, I tried to
> rephrase, feel free to refer to.
>
> =
> The crashk_low_res should be considered by /sys/kernel/kexec_crash_size
> to support two crash kernel regions shrinking if existing.
>
> While doing it, crashk_low_res will only be shrunk when the entire
> crashk_res is empty; and if the crashk_res is empty and crahk_low_res
> is not, change crashk_low_res to be crashk_res.
> =
>
> With the log updated, you can add:
>
> Acked-by: Baoquan He
OK, I will update the log and add Acked-by in v2.
>
>>
>> Signed-off-by: Zhen Lei
>> ---
>> kernel/kexec_core.c | 43 ++-
>> 1 file changed, 38 insertions(+), 5 deletions(-)
>>
>> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
>> index e82bc6d6634136a..c1d50f6566300d9 100644
>> --- a/kernel/kexec_core.c
>> +++ b/kernel/kexec_core.c
>> @@ -1091,6 +1091,11 @@ __bpf_kfunc void crash_kexec(struct pt_regs *regs)
>> }
>> }
>>
>> +static inline resource_size_t crash_resource_size(const struct resource
>> *res)
>> +{
>> +return !res->end ? 0 : resource_size(res);
>> +}
>> +
>> ssize_t crash_get_memory_size(void)
>> {
>> ssize_t size = 0;
>> @@ -1098,8 +1103,8 @@ ssize_t crash_get_memory_size(void)
>> if (!kexec_trylock())
>> return -EBUSY;
>>
>> -if (crashk_res.end != crashk_res.start)
>> -size = resource_size(_res);
>> +size += crash_resource_size(_res);
>> +size += crash_resource_size(_low_res);
>>
>> kexec_unlock();
>> return size;
>> @@ -1135,7 +1140,7 @@ int __crash_shrink_memory(struct resource *old_res,
>> unsigned long new_size)
>> int crash_shrink_memory(unsigned long new_size)
>> {
>> int ret = 0;
>> -unsigned long old_size;
>> +unsigned long old_size, low_size;
>>
>> if (!kexec_trylock())
>> return -EBUSY;
>> @@ -1144,14 +1149,42 @@ int crash_shrink_memory(unsigned long new_size)
>> ret = -ENOENT;
>> goto unlock;
>> }
>> -old_size = !crashk_res.end ? 0 : resource_size(_res);
>> +
>> +low_size = crash_resource_size(_low_res);
>> +old_size = crash_resource_size(_res) + low_size;
>> new_size = roundup(new_size, KEXEC_CRASH_MEM_ALIGN);
>> if (new_size >= old_size) {
>> ret = (new_size == old_size) ? 0 : -EINVAL;
>> goto unlock;
>> }
>>
>> -ret = __crash_shrink_memory(_res, new_size);
>> +/*
>> + * (low_size > new_size) implies that low_size is greater than zero.
>> + * This also means that if low_size is zero, the else branch is taken.
>> + *
>> + * If low_size is greater than 0, (low_size > new_size) indicates that
>> + * crashk_low_res also needs to be shrunken. Otherwise, only crashk_res
>> + * needs to be shrunken.
>> + */
>> +if (low_size > new_size) {
>> +ret = __crash_shrink_memory(_res, 0);
>> +if (ret)
>> +goto unlock;
>> +
>> +ret = __crash_shrink_memory(_low_res, new_size);
>> +} else {
>> +ret = __crash_shrink_memory(_res, new_size - low_size);
>> +}
>> +
>> +/* Swap crashk_res and crashk_low_res if needed */
>> +if (!crashk_res.end && crashk_low_res.end) {
>> +crashk_res.start = crashk_low_res.start;
>> +crashk_res.end = crashk_low_res.end;
>> +release_resource(_low_res);
>> +crashk_low_res.start = 0;
>> +crashk_low_res.end = 0;
>> +insert_resource(_resource, _res);
>> +}
>>
>> unlock:
>> kexec_unlock();
>> --
>> 2.25.1
>>
>
> .
>
--
Regards,
Zhen Lei
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 2/6] kexec: delete a useless check in crash_shrink_memory()
On 2023/5/31 15:41, Baoquan He wrote:
> On 05/31/23 at 10:19am, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2023/5/31 8:17, Baoquan He wrote:
>>> On 05/27/23 at 08:34pm, Zhen Lei wrote:
>>>> The check '(crashk_res.parent != NULL)' is added by
>>>> commit e05bd3367bd3 ("kexec: fix Oops in crash_shrink_memory()"), but it's
>>>> stale now. Because if 'crashk_res' is not reserved, it will be zero in
>>>> size and will be intercepted by the above 'if (new_size >= old_size)'.
>>>>
>>>> Ago:
>>>>if (new_size >= end - start + 1)
>>>>
>>>> Now:
>>>>old_size = (end == 0) ? 0 : end - start + 1;
>>>>if (new_size >= old_size)
>>>
>>> Hmm, I would strongly suggest we keep that check. Even though the
>>> current code like above can do the acutal checking, but its actual usage
>>> is not obvious for checking of crashk_res existence. In the future,
>>> someone may change above calculation and don't notice the hidden
>>> functionality at all behind the calculation. The cost of the check is
>>> almost zero, right?
>>
>> The cost of the check is negligible. The only downside is that it's hard to
>> understand why it's added, and I only found out why by looking at the history
>> log. In my opinion, the above 'Now:' is the right fix.
>
> It checks if the resource exists before releasing, just a normal
> checking?
If resource_size(_res) is zero, it means that crashk_res has not been
added(insert_resource) or has been deleted(release_resource). I've tested it.
It's okay.
>>
>>>
>>>>
>>>> Signed-off-by: Zhen Lei
>>>> ---
>>>> kernel/kexec_core.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
>>>> index 22acee18195a591..d1ab139dd49035e 100644
>>>> --- a/kernel/kexec_core.c
>>>> +++ b/kernel/kexec_core.c
>>>> @@ -1137,7 +1137,7 @@ int crash_shrink_memory(unsigned long new_size)
>>>>end = start + new_size;
>>>>crash_free_reserved_phys_range(end, crashk_res.end);
>>>>
>>>> - if ((start == end) && (crashk_res.parent != NULL))
>>>> + if (start == end)
>>>>release_resource(_res);
>>>>
>>>>ram_res->start = end;
>>>> --
>>>> 2.25.1
>>>>
>>>
>>> .
>>>
>>
>> --
>> Regards,
>> Zhen Lei
>>
>
>
> .
>
--
Regards,
Zhen Lei
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 2/6] kexec: delete a useless check in crash_shrink_memory()
On 2023/5/31 8:17, Baoquan He wrote:
> On 05/27/23 at 08:34pm, Zhen Lei wrote:
>> The check '(crashk_res.parent != NULL)' is added by
>> commit e05bd3367bd3 ("kexec: fix Oops in crash_shrink_memory()"), but it's
>> stale now. Because if 'crashk_res' is not reserved, it will be zero in
>> size and will be intercepted by the above 'if (new_size >= old_size)'.
>>
>> Ago:
>> if (new_size >= end - start + 1)
>>
>> Now:
>> old_size = (end == 0) ? 0 : end - start + 1;
>> if (new_size >= old_size)
>
> Hmm, I would strongly suggest we keep that check. Even though the
> current code like above can do the acutal checking, but its actual usage
> is not obvious for checking of crashk_res existence. In the future,
> someone may change above calculation and don't notice the hidden
> functionality at all behind the calculation. The cost of the check is
> almost zero, right?
The cost of the check is negligible. The only downside is that it's hard to
understand why it's added, and I only found out why by looking at the history
log. In my opinion, the above 'Now:' is the right fix.
>
>>
>> Signed-off-by: Zhen Lei
>> ---
>> kernel/kexec_core.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
>> index 22acee18195a591..d1ab139dd49035e 100644
>> --- a/kernel/kexec_core.c
>> +++ b/kernel/kexec_core.c
>> @@ -1137,7 +1137,7 @@ int crash_shrink_memory(unsigned long new_size)
>> end = start + new_size;
>> crash_free_reserved_phys_range(end, crashk_res.end);
>>
>> -if ((start == end) && (crashk_res.parent != NULL))
>> +if (start == end)
>> release_resource(_res);
>>
>> ram_res->start = end;
>> --
>> 2.25.1
>>
>
> .
>
--
Regards,
Zhen Lei
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 1/6] kexec: fix a memory leak in crash_shrink_memory()
On 2023/5/31 8:13, Baoquan He wrote:
> On 05/27/23 at 08:34pm, Zhen Lei wrote:
>> If the value of parameter 'new_size' is in the semi-open and semi-closed
>> interval (crashk_res.end - KEXEC_CRASH_MEM_ALIGN + 1, crashk_res.end], the
>> calculation result of ram_res is:
>> ram_res->start = crashk_res.end + 1
>> ram_res->end = crashk_res.end
>
> If the new_size is smaller than KEXEC_CRASH_MEM_ALIGN, does it make
> any sense except of testing purpose? Do we need to fail this kind of
> shrinking, or just shrink all the left crash memory?
We can't give a fixed value, that is, how much crash memory is reserved to
ensure that the capture kernel runs. The size of KEXEC_CRASH_MEM_ALIGN is
only one page on non-s390 platforms. So, it's better to keep the code simple,
and let the user(administrator) shrink the crash memory reasonably.
include/linux/kexec.h
#define KEXEC_CRASH_MEM_ALIGN PAGE_SIZE
>
>> The operation of function insert_resource() fails, and ram_res is not
>> added to iomem_resource. As a result, the memory of the control block
>> ram_res is leaked.
>>
>> In fact, on all architectures, the start address and size of crashk_res
>> are already aligned by KEXEC_CRASH_MEM_ALIGN. Therefore, we do not need to
>> round up crashk_res.start again. Instead, we should round up 'new_size'
>> in advance.
>>
>> Fixes: 6480e5a09237 ("kdump: add missing RAM resource in
>> crash_shrink_memory()")
>> Fixes: 06a7f711246b ("kexec: premit reduction of the reserved memory size")
>> Signed-off-by: Zhen Lei
>> ---
>> kernel/kexec_core.c | 5 ++---
>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
>> index 3d578c6fefee385..22acee18195a591 100644
>> --- a/kernel/kexec_core.c
>> +++ b/kernel/kexec_core.c
>> @@ -1122,6 +1122,7 @@ int crash_shrink_memory(unsigned long new_size)
>> start = crashk_res.start;
>> end = crashk_res.end;
>> old_size = (end == 0) ? 0 : end - start + 1;
>> +new_size = roundup(new_size, KEXEC_CRASH_MEM_ALIGN);
>> if (new_size >= old_size) {
>> ret = (new_size == old_size) ? 0 : -EINVAL;
>> goto unlock;
>> @@ -1133,9 +1134,7 @@ int crash_shrink_memory(unsigned long new_size)
>> goto unlock;
>> }
>>
>> -start = roundup(start, KEXEC_CRASH_MEM_ALIGN);
>> -end = roundup(start + new_size, KEXEC_CRASH_MEM_ALIGN);
>> -
>> +end = start + new_size;
>> crash_free_reserved_phys_range(end, crashk_res.end);
>>
>> if ((start == end) && (crashk_res.parent != NULL))
>> --
>> 2.25.1
>>
>
> .
>
--
Regards,
Zhen Lei
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 5/6] kexec: add helper __crash_shrink_memory()
On 2023/5/28 8:08, kernel test robot wrote:
> Hi Zhen,
>
> kernel test robot noticed the following build warnings:
>
> [auto build test WARNING on akpm-mm/mm-everything]
> [also build test WARNING on linus/master v6.4-rc3 next-20230525]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch#_base_tree_information]
>
> url:
> https://github.com/intel-lab-lkp/linux/commits/Zhen-Lei/kexec-fix-a-memory-leak-in-crash_shrink_memory/20230527-203821
> base: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git
> mm-everything
> patch link:
> https://lore.kernel.org/r/20230527123439.772-6-thunder.leizhen%40huawei.com
> patch subject: [PATCH 5/6] kexec: add helper __crash_shrink_memory()
> config: riscv-randconfig-r042-20230526
> (https://download.01.org/0day-ci/archive/20230528/202305280717.pw06alkz-...@intel.com/config)
> compiler: clang version 17.0.0 (https://github.com/llvm/llvm-project
> 4faf3aaf28226a4e950c103a14f6fc1d1fdabb1b)
> reproduce (this is a W=1 build):
> mkdir -p ~/bin
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # install riscv cross compiling tool for clang build
> # apt-get install binutils-riscv64-linux-gnu
> #
> https://github.com/intel-lab-lkp/linux/commit/dea97cef503d26e05d0e11818ae44176056ddf64
> git remote add linux-review https://github.com/intel-lab-lkp/linux
> git fetch --no-tags linux-review
> Zhen-Lei/kexec-fix-a-memory-leak-in-crash_shrink_memory/20230527-203821
> git checkout dea97cef503d26e05d0e11818ae44176056ddf64
> # save the config file
> mkdir build_dir && cp config build_dir/.config
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang ~/bin/make.cross W=1
> O=build_dir ARCH=riscv olddefconfig
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang ~/bin/make.cross W=1
> O=build_dir ARCH=riscv SHELL=/bin/bash
>
> If you fix the issue, kindly add following tag where applicable
> | Reported-by: kernel test robot
> | Closes:
> https://lore.kernel.org/oe-kbuild-all/202305280717.pw06alkz-...@intel.com/
>
> All warnings (new ones prefixed by >>):
>
>>> kernel/kexec_core.c:1108:5: warning: no previous prototype for function
>>> '__crash_shrink_memory' [-Wmissing-prototypes]
>int __crash_shrink_memory(struct resource *old_res, unsigned long new_size)
>^
>kernel/kexec_core.c:1108:1: note: declare 'static' if the function is not
> intended to be used outside of this translation unit
>int __crash_shrink_memory(struct resource *old_res, unsigned long new_size)
>^
>static
>1 warning generated.
Yes, thanks, a 'static' should be added.
>
>
> vim +/__crash_shrink_memory +1108 kernel/kexec_core.c
>
> 1107
>> 1108 int __crash_shrink_memory(struct resource *old_res, unsigned long
>> new_size)
> 1109{
> 1110struct resource *ram_res;
>
> 1112ram_res = kzalloc(sizeof(*ram_res), GFP_KERNEL);
> 1113if (!ram_res)
> 1114return -ENOMEM;
> 1115
> 1116ram_res->start = old_res->start + new_size;
> 1117ram_res->end = old_res->end;
> 1118ram_res->flags = IORESOURCE_BUSY |
> IORESOURCE_SYSTEM_RAM;
> 1119ram_res->name = "System RAM";
> 1120
> 1121if (!new_size) {
> 1122release_resource(old_res);
> 1123old_res->start = 0;
> 1124old_res->end = 0;
> 1125} else {
> 1126crashk_res.end = ram_res->start - 1;
> 1127}
> 1128
> 1129crash_free_reserved_phys_range(ram_res->start,
> ram_res->end);
> 1130insert_resource(_resource, ram_res);
> 1131
> 1132return 0;
> 1133}
> 1134
>
--
Regards,
Zhen Lei
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v5] arm64: kdump: simplify the reservation behaviour of crashkernel=,high
On 2023/4/13 22:30, Catalin Marinas wrote: > On Thu, Apr 13, 2023 at 03:45:50PM +0800, Baoquan He wrote: >> I am OK with this version, or the version with min(SZ_4G, >> arm64_dma_phys_limit), or v4. Please help point out if I got your idea >> correctly. Thanks a lot. > > I think we should stick to this patch. The disabling of the ZONE_DMA(32) > is fairly specialised and you are right that we should not introduce an > artificial 4GB crashkernel boundary on such systems. The slight > confusion may be that ,high triggers a search above 4GB where there's > not such boundary but this would match the documentation anyway. > Agreed, so careful. -- Regards, Zhen Lei ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH -next v3 2/2] docs: kdump: Update the crashkernel description for riscv
On 2023/4/7 6:02, Chen Jiahao wrote: > Now "crashkernel=" parameter on riscv has been updated to support > crashkernel=X,[high,low]. Through which we can reserve memory region > above/within 32bit addressible DMA zone. > > Here update the parameter description accordingly. Reviewed-by: Zhen Lei > > Signed-off-by: Chen Jiahao > --- > Documentation/admin-guide/kernel-parameters.txt | 15 --- > 1 file changed, 8 insertions(+), 7 deletions(-) > > diff --git a/Documentation/admin-guide/kernel-parameters.txt > b/Documentation/admin-guide/kernel-parameters.txt > index 54702bd488eb..41865aae9eaa 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt > @@ -866,7 +866,7 @@ > memory region [offset, offset + size] for that kernel > image. If '@offset' is omitted, then a suitable offset > is selected automatically. > - [KNL, X86-64, ARM64] Select a region under 4G first, and > + [KNL, X86-64, ARM64, RISCV] Select a region under 4G > first, and > fall back to reserve region above 4G when '@offset' > hasn't been specified. > See Documentation/admin-guide/kdump/kdump.rst for > further details. > @@ -879,14 +879,14 @@ > Documentation/admin-guide/kdump/kdump.rst for an > example. > > crashkernel=size[KMG],high > - [KNL, X86-64, ARM64] range could be above 4G. Allow > kernel > - to allocate physical memory region from top, so could > - be above 4G if system have more than 4G ram installed. > - Otherwise memory region will be allocated below 4G, if > - available. > + [KNL, X86-64, ARM64, RISCV] range could be above 4G. > + Allow kernel to allocate physical memory region from > top, > + so could be above 4G if system have more than 4G ram > + installed. Otherwise memory region will be allocated > + below 4G, if available. > It will be ignored if crashkernel=X is specified. > crashkernel=size[KMG],low > - [KNL, X86-64, ARM64] range under 4G. When > crashkernel=X,high > + [KNL, X86-64, ARM64, RISCV] range under 4G. When > crashkernel=X,high > is passed, kernel could allocate physical memory region > above 4G, that cause second kernel crash on system > that require some amount of low memory, e.g. swiotlb > @@ -897,6 +897,7 @@ > size is platform dependent. > --> x86: max(swiotlb_size_or_default() + 8MiB, 256MiB) > --> arm64: 128MiB > + --> riscv: 128MiB > This one lets the user specify own low range under 4G > for second kernel instead. > 0: to disable low allocation. > -- Regards, Zhen Lei ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH -next v3 1/2] riscv: kdump: Implement crashkernel=X,[high,low]
On 2023/4/7 20:58, Leizhen (ThunderTown) wrote:
>
>
> On 2023/4/7 20:03, Simon Horman wrote:
>> On Fri, Apr 07, 2023 at 06:02:05AM +0800, Chen Jiahao wrote:
>>> On riscv, the current crash kernel allocation logic is trying to
>>> allocate within 32bit addressible memory region by default, if
>>> failed, try to allocate without 4G restriction.
>>>
>>> In need of saving DMA zone memory while allocating a relatively large
>>> crash kernel region, allocating the reserved memory top down in
>>> high memory, without overlapping the DMA zone, is a mature solution.
>>> Here introduce the parameter option crashkernel=X,[high,low].
>>>
>>> One can reserve the crash kernel from high memory above DMA zone range
>>> by explicitly passing "crashkernel=X,high"; or reserve a memory range
>>> below 4G with "crashkernel=X,low".
>>>
>>> Signed-off-by: Chen Jiahao
>>
>> ...
>>
>>> @@ -1180,14 +1206,37 @@ static void __init reserve_crashkernel(void)
>>> return;
>>> }
>>>
>>> - ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
>>> + ret = parse_crashkernel(cmdline, memblock_phys_mem_size(),
>>> _size, _base);
>>> - if (ret || !crash_size)
>>> + if (ret == -ENOENT) {
>>> + /*
>>> +* crashkernel=X,[high,low] can be specified or not, but
>>> +* invalid value is not allowed.
>>
>> nit: Perhaps something like this would be easier to correlate with the
>> code that follows:
>>
>> /* Fallback to crashkernel=X,[high,low] */
>
> The description "crashkernel=X,[high,low] can be specified or not" is not
> correct, because crashkernel=X,high must be specified when walking into this
> branch. So use Simon's comments or copy arm64's comments(it's written for
> parse_crashkernel_low()).
I rethink it a little bit, if it's relative to crashkernel=X[@offset],
that's also true.
Reviewed-by: Zhen Lei
>
>>
>>
>>> +*/
>>> + ret = parse_crashkernel_high(cmdline, 0, _size,
>>> _base);
>>> + if (ret || !crash_size)
>>> + return;
>>> +
>>> + /*
>>> +* crashkernel=Y,low is valid only when crashkernel=X,high
>>> +* is passed and high memory is reserved successful.
>>
>> nit: s/successful/successfully/
>
> Seems like the whole "and high memory is reserved successful" needs to be
> deleted.
> Only the dependency between the two boot options should be described here,
> regardless of whether their memory is successfully allocated.
>
>>
>>> +*/
>>> + ret = parse_crashkernel_low(cmdline, 0, _low_size,
>>> _base);
>>> + if (ret == -ENOENT)
>>> + crash_low_size = DEFAULT_CRASH_KERNEL_LOW_SIZE;
>>> + else if (ret)
>>> + return;
>>> +
>>> + search_start = search_low_max;
>>> + } else if (ret || !crash_size) {
>>> + /* Invalid argument value specified */
>>> return;
>>> + }
>>
>> ...
>> .
>>
>
--
Regards,
Zhen Lei
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH -next v3 1/2] riscv: kdump: Implement crashkernel=X,[high,low]
On 2023/4/7 20:03, Simon Horman wrote:
> On Fri, Apr 07, 2023 at 06:02:05AM +0800, Chen Jiahao wrote:
>> On riscv, the current crash kernel allocation logic is trying to
>> allocate within 32bit addressible memory region by default, if
>> failed, try to allocate without 4G restriction.
>>
>> In need of saving DMA zone memory while allocating a relatively large
>> crash kernel region, allocating the reserved memory top down in
>> high memory, without overlapping the DMA zone, is a mature solution.
>> Here introduce the parameter option crashkernel=X,[high,low].
>>
>> One can reserve the crash kernel from high memory above DMA zone range
>> by explicitly passing "crashkernel=X,high"; or reserve a memory range
>> below 4G with "crashkernel=X,low".
>>
>> Signed-off-by: Chen Jiahao
>
> ...
>
>> @@ -1180,14 +1206,37 @@ static void __init reserve_crashkernel(void)
>> return;
>> }
>>
>> -ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
>> +ret = parse_crashkernel(cmdline, memblock_phys_mem_size(),
>> _size, _base);
>> -if (ret || !crash_size)
>> +if (ret == -ENOENT) {
>> +/*
>> + * crashkernel=X,[high,low] can be specified or not, but
>> + * invalid value is not allowed.
>
> nit: Perhaps something like this would be easier to correlate with the
> code that follows:
>
> /* Fallback to crashkernel=X,[high,low] */
The description "crashkernel=X,[high,low] can be specified or not" is not
correct, because crashkernel=X,high must be specified when walking into this
branch. So use Simon's comments or copy arm64's comments(it's written for
parse_crashkernel_low()).
>
>
>> + */
>> +ret = parse_crashkernel_high(cmdline, 0, _size,
>> _base);
>> +if (ret || !crash_size)
>> +return;
>> +
>> +/*
>> + * crashkernel=Y,low is valid only when crashkernel=X,high
>> + * is passed and high memory is reserved successful.
>
> nit: s/successful/successfully/
Seems like the whole "and high memory is reserved successful" needs to be
deleted.
Only the dependency between the two boot options should be described here,
regardless of whether their memory is successfully allocated.
>
>> + */
>> +ret = parse_crashkernel_low(cmdline, 0, _low_size,
>> _base);
>> +if (ret == -ENOENT)
>> +crash_low_size = DEFAULT_CRASH_KERNEL_LOW_SIZE;
>> +else if (ret)
>> +return;
>> +
>> +search_start = search_low_max;
>> +} else if (ret || !crash_size) {
>> +/* Invalid argument value specified */
>> return;
>> +}
>
> ...
> .
>
--
Regards,
Zhen Lei
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v2 3/3] arm64: kdump: defer the crashkernel reservation for platforms with no DMA memory zones
On 2023/3/26 21:02, Baoquan He wrote:
> In commit 031495635b46 ("arm64: Do not defer reserve_crashkernel() for
> platforms with no DMA memory zones"), reserve_crashkernel() is called
> much earlier in arm64_memblock_init() to avoid causing base apge
> mapping on platforms with no DMA meomry zones.
>
> With taking off protection on crashkernel memory region, no need to call
> reserve_crashkernel() specially in advance. The deferred invocation of
> reserve_crashkernel() in bootmem_init() can cover all cases. So revert
> the commit 031495635b46 now.
>
> Signed-off-by: Baoquan He
> ---
> v1->v2:
> - When trying to revert commit 031495635b46, two hunks were missed in v1
> post. Remove them in v2. Thanks to Leizhen for pointing out this.
> - Remove code comment above arm64_dma_phys_limit definition added
> in commit 031495635b46;
> - Move the arm64_dma_phys_limit assignment back into zone_sizes_init()
> when both CONFIG_ZONE_DMA and CONFIG_ZONE_DMA32 are not enabled.
Reviewed-by: Zhen Lei
>
> arch/arm64/include/asm/memory.h | 5 -
> arch/arm64/mm/init.c| 34 +++--
> 2 files changed, 3 insertions(+), 36 deletions(-)
>
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index 78e5163836a0..efcd68154a3a 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -374,11 +374,6 @@ static inline void *phys_to_virt(phys_addr_t x)
> })
>
> void dump_mem_limit(void);
> -
> -static inline bool defer_reserve_crashkernel(void)
> -{
> - return IS_ENABLED(CONFIG_ZONE_DMA) || IS_ENABLED(CONFIG_ZONE_DMA32);
> -}
> #endif /* !ASSEMBLY */
>
> /*
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 58a0bb2c17f1..66e70ca47680 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -61,34 +61,8 @@ EXPORT_SYMBOL(memstart_addr);
> * unless restricted on specific platforms (e.g. 30-bit on Raspberry Pi 4).
> * In such case, ZONE_DMA32 covers the rest of the 32-bit addressable memory,
> * otherwise it is empty.
> - *
> - * Memory reservation for crash kernel either done early or deferred
> - * depending on DMA memory zones configs (ZONE_DMA) --
> - *
> - * In absence of ZONE_DMA configs arm64_dma_phys_limit initialized
> - * here instead of max_zone_phys(). This lets early reservation of
> - * crash kernel memory which has a dependency on arm64_dma_phys_limit.
> - * Reserving memory early for crash kernel allows linear creation of block
> - * mappings (greater than page-granularity) for all the memory bank rangs.
> - * In this scheme a comparatively quicker boot is observed.
> - *
> - * If ZONE_DMA configs are defined, crash kernel memory reservation
> - * is delayed until DMA zone memory range size initialization performed in
> - * zone_sizes_init(). The defer is necessary to steer clear of DMA zone
> - * memory range to avoid overlap allocation. So crash kernel memory
> boundaries
> - * are not known when mapping all bank memory ranges, which otherwise means
> - * not possible to exclude crash kernel range from creating block mappings
> - * so page-granularity mappings are created for the entire memory range.
> - * Hence a slightly slower boot is observed.
> - *
> - * Note: Page-granularity mappings are necessary for crash kernel memory
> - * range for shrinking its size via /sys/kernel/kexec_crash_size interface.
> */
> -#if IS_ENABLED(CONFIG_ZONE_DMA) || IS_ENABLED(CONFIG_ZONE_DMA32)
> phys_addr_t __ro_after_init arm64_dma_phys_limit;
> -#else
> -phys_addr_t __ro_after_init arm64_dma_phys_limit = PHYS_MASK + 1;
> -#endif
>
> /* Current arm64 boot protocol requires 2MB alignment */
> #define CRASH_ALIGN SZ_2M
> @@ -248,6 +222,8 @@ static void __init zone_sizes_init(void)
> if (!arm64_dma_phys_limit)
> arm64_dma_phys_limit = dma32_phys_limit;
> #endif
> + if (!arm64_dma_phys_limit)
> + arm64_dma_phys_limit = PHYS_MASK + 1;
> max_zone_pfns[ZONE_NORMAL] = max_pfn;
>
> free_area_init(max_zone_pfns);
> @@ -408,9 +384,6 @@ void __init arm64_memblock_init(void)
>
> early_init_fdt_scan_reserved_mem();
>
> - if (!defer_reserve_crashkernel())
> - reserve_crashkernel();
> -
> high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
> }
>
> @@ -457,8 +430,7 @@ void __init bootmem_init(void)
>* request_standard_resources() depends on crashkernel's memory being
>* reserved, so do it here.
>*/
> - if (defer_reserve_crashkernel())
> - reserve_crashkernel();
> + reserve_crashkernel();
>
> memblock_dump_all();
> }
>
--
Regards,
Zhen Lei
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 0/3] arm64: kdump : take off the protection on crashkernel memory region
On 2023/3/25 1:11, Catalin Marinas wrote: > On Fri, Mar 24, 2023 at 09:18:35PM +0800, Baoquan He wrote: >> Baoquan He (3): >> arm64: kdump : take off the protection on crashkernel memory region >> arm64: kdump: do not map crashkernel region specifically >> arm64: kdump: defer the crashkernel reservation for platforms with no >> DMA memory zones >> >> arch/arm64/include/asm/kexec.h| 6 - >> arch/arm64/include/asm/memory.h | 5 >> arch/arm64/kernel/machine_kexec.c | 20 -- >> arch/arm64/mm/init.c | 6 + >> arch/arm64/mm/mmu.c | 43 --- >> 5 files changed, 1 insertion(+), 79 deletions(-) > > This series works for me and it has a negative diffstat as well (though > I'm sure people will try to bring it back ;)). After the write protection is removed, it is recommended that crc32 check be added. However, it can be added later. > > Acked-by: Catalin Marinas > > . > -- Regards, Zhen Lei ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 3/3] arm64: kdump: defer the crashkernel reservation for platforms with no DMA memory zones
On 2023/3/24 21:18, Baoquan He wrote:
> In commit 031495635b46 ("arm64: Do not defer reserve_crashkernel() for
> platforms with no DMA memory zones"), reserve_crashkernel() is called
> much earlier in arm64_memblock_init() to avoid causing base apge
> mapping on platforms with no DMA meomry zones.
>
> With taking off protection on crashkernel memory region, no need to call
> reserve_crashkernel() specially in advance. The deferred invocation of
> reserve_crashkernel() in bootmem_init() can cover all cases.
>
> Signed-off-by: Baoquan He
> ---
> arch/arm64/include/asm/memory.h | 5 -
> arch/arm64/mm/init.c| 6 +-
> 2 files changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index 78e5163836a0..efcd68154a3a 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -374,11 +374,6 @@ static inline void *phys_to_virt(phys_addr_t x)
> })
>
> void dump_mem_limit(void);
> -
> -static inline bool defer_reserve_crashkernel(void)
> -{
> - return IS_ENABLED(CONFIG_ZONE_DMA) || IS_ENABLED(CONFIG_ZONE_DMA32);
> -}
> #endif /* !ASSEMBLY */
>
> /*
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 58a0bb2c17f1..b888de59e0b7 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -408,9 +408,6 @@ void __init arm64_memblock_init(void)
>
> early_init_fdt_scan_reserved_mem();
>
> - if (!defer_reserve_crashkernel())
> - reserve_crashkernel();
> -
> high_memory = __va(memblock_end_of_DRAM() - 1) + 1;
> }
>
> @@ -457,8 +454,7 @@ void __init bootmem_init(void)
>* request_standard_resources() depends on crashkernel's memory being
>* reserved, so do it here.
>*/
> - if (defer_reserve_crashkernel())
> - reserve_crashkernel();
> + reserve_crashkernel();
>
> memblock_dump_all();
> }
Some comments also need to be deleted, above the definition of
arm64_dma_phys_limit
in arch/arm64/mm/init.c
>
--
Regards,
Zhen Lei
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 2/3] arm64: kdump: do not map crashkernel region specifically
On 2023/3/24 21:18, Baoquan He wrote:
> After taking off the protection functions on crashkernel memory region,
> there's no need to map crashkernel region with page granularity during
> linear mapping.
>
> With this change, the system can make use of block or section mapping
> on linear region to largely improve perforcemence during system bootup
> and running.
>
> Signed-off-by: Baoquan He
> ---
> arch/arm64/mm/mmu.c | 43 ---
> 1 file changed, 43 deletions(-)
>
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 6f9d8898a025..7556020a27b7 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -510,21 +510,6 @@ void __init mark_linear_text_alias_ro(void)
> PAGE_KERNEL_RO);
> }
>
> -static bool crash_mem_map __initdata;
> -
> -static int __init enable_crash_mem_map(char *arg)
> -{
> - /*
> - * Proper parameter parsing is done by reserve_crashkernel(). We only
> - * need to know if the linear map has to avoid block mappings so that
> - * the crashkernel reservations can be unmapped later.
> - */
> - crash_mem_map = true;
> -
> - return 0;
> -}
> -early_param("crashkernel", enable_crash_mem_map);
> -
> static void __init map_mem(pgd_t *pgdp)
> {
> static const u64 direct_map_end = _PAGE_END(VA_BITS_MIN);
> @@ -554,16 +539,6 @@ static void __init map_mem(pgd_t *pgdp)
>*/
> memblock_mark_nomap(kernel_start, kernel_end - kernel_start);
>
> -#ifdef CONFIG_KEXEC_CORE
> - if (crash_mem_map) {
> - if (defer_reserve_crashkernel())
> - flags |= NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS;
> - else if (crashk_res.end)
> - memblock_mark_nomap(crashk_res.start,
> - resource_size(_res));
> - }
> -#endif
> -
> /* map all the memory banks */
> for_each_mem_range(i, , ) {
> if (start >= end)
> @@ -590,24 +565,6 @@ static void __init map_mem(pgd_t *pgdp)
> __map_memblock(pgdp, kernel_start, kernel_end,
> PAGE_KERNEL, NO_CONT_MAPPINGS);
> memblock_clear_nomap(kernel_start, kernel_end - kernel_start);
> -
> - /*
> - * Use page-level mappings here so that we can shrink the region
> - * in page granularity and put back unused memory to buddy system
> - * through /sys/kernel/kexec_crash_size interface.
> - */
> -#ifdef CONFIG_KEXEC_CORE
> - if (crash_mem_map && !defer_reserve_crashkernel()) {
> - if (crashk_res.end) {
> - __map_memblock(pgdp, crashk_res.start,
> -crashk_res.end + 1,
> -PAGE_KERNEL,
> -NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS);
> - memblock_clear_nomap(crashk_res.start,
> - resource_size(_res));
> - }
> - }
> -#endif
> }
>
> void mark_rodata_ro(void)
>
Reviewed-by: Zhen Lei
--
Regards,
Zhen Lei
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 1/3] arm64: kdump : take off the protection on crashkernel memory region
On 2023/3/24 21:18, Baoquan He wrote:
> Problem:
> ===
> On arm64, block and section mapping is supported to build page tables.
> However, currently it enforces to take base page mapping for the whole
> linear mapping if CONFIG_ZONE_DMA or CONFIG_ZONE_DMA32 is enabled and
> crashkernel kernel parameter is set. This will cause longer time of the
> linear mapping process during bootup and severe performance degradation
> during running time.
>
> Root cause:
> ==
> On arm64, crashkernel reservation relies on knowing the upper limit of
> low memory zone because it needs to reserve memory in the zone so that
> devices' DMA addressing in kdump kernel can be satisfied. However, the
> upper limit of low memory on arm64 is variant. And the upper limit can
> only be decided late till bootmem_init() is called [1].
>
> And we need to map the crashkernel region with base page granularity when
> doing linear mapping, because kdump needs to protect the crashkernel region
> via set_memory_valid(,0) after kdump kernel loading. However, arm64 doesn't
> support well on splitting the built block or section mapping due to some
> cpu reststriction [2]. And unfortunately, the linear mapping is done before
> bootmem_init().
>
> To resolve the above conflict on arm64, the compromise is enforcing to
> take base page mapping for the entire linear mapping if crashkernel is
> set, and CONFIG_ZONE_DMA or CONFIG_ZONE_DMA32 is enabed. Hence
> performance is sacrificed.
>
> Solution:
> =
> Comparing with the base page mapping for the whole linear region, it's
> better to take off the protection on crashkernel memory region for the
> time being because the anticipated stamping on crashkernel memory region
> could only happen in a chance in one million, while the base page mapping
> for the whole linear region is mitigating arm64 systems with crashkernel
> set always.
>
> [1]
> https://lore.kernel.org/all/yriijkhkwsuaq...@arm.com/T/#u
>
> [2]
> https://lore.kernel.org/linux-arm-kernel/20190911182546.17094-1-nsaenzjulie...@suse.de/T/
>
> Signed-off-by: Baoquan He
> ---
> arch/arm64/include/asm/kexec.h| 6 --
> arch/arm64/kernel/machine_kexec.c | 20
> 2 files changed, 26 deletions(-)
>
> diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
> index 559bfae26715..9ac9572a3bbe 100644
> --- a/arch/arm64/include/asm/kexec.h
> +++ b/arch/arm64/include/asm/kexec.h
> @@ -102,12 +102,6 @@ void cpu_soft_restart(unsigned long el2_switch, unsigned
> long entry,
>
> int machine_kexec_post_load(struct kimage *image);
> #define machine_kexec_post_load machine_kexec_post_load
> -
> -void arch_kexec_protect_crashkres(void);
> -#define arch_kexec_protect_crashkres arch_kexec_protect_crashkres
> -
> -void arch_kexec_unprotect_crashkres(void);
> -#define arch_kexec_unprotect_crashkres arch_kexec_unprotect_crashkres
> #endif
>
> #define ARCH_HAS_KIMAGE_ARCH
> diff --git a/arch/arm64/kernel/machine_kexec.c
> b/arch/arm64/kernel/machine_kexec.c
> index ce3d40120f72..22da7fc1ff50 100644
> --- a/arch/arm64/kernel/machine_kexec.c
> +++ b/arch/arm64/kernel/machine_kexec.c
> @@ -268,26 +268,6 @@ void machine_crash_shutdown(struct pt_regs *regs)
> pr_info("Starting crashdump kernel...\n");
> }
>
> -void arch_kexec_protect_crashkres(void)
> -{
> - int i;
> -
> - for (i = 0; i < kexec_crash_image->nr_segments; i++)
> - set_memory_valid(
> - __phys_to_virt(kexec_crash_image->segment[i].mem),
> - kexec_crash_image->segment[i].memsz >> PAGE_SHIFT, 0);
> -}
> -
> -void arch_kexec_unprotect_crashkres(void)
> -{
> - int i;
> -
> - for (i = 0; i < kexec_crash_image->nr_segments; i++)
> - set_memory_valid(
> - __phys_to_virt(kexec_crash_image->segment[i].mem),
> - kexec_crash_image->segment[i].memsz >> PAGE_SHIFT, 1);
> -}
> -
> #ifdef CONFIG_HIBERNATION
> /*
> * To preserve the crash dump kernel image, the relevant memory segments
>
Reviewed-by: Zhen Lei
--
Regards,
Zhen Lei
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v4] arm64: kdump: simplify the reservation behaviour of crashkernel=,high
On 2023/3/24 22:53, Baoquan He wrote: > Hi Leizhen, > > On 03/24/23 at 10:47am, Leizhen (ThunderTown) wrote: > .. >>>>>> 2) with the fixed CRASH_ADDR_LOW_MAX as 4G, we can easily fix the >>>>>> problem of base page mapping for the whole linear mapping if crsahkernel= >>>>>> is set in kernel parameter shown in [1] at bottom. >>>>> >>>>> That's a different problem ;). I should re-read that thread, forgot most >>>>> of the details but I recall one of the counter arguments was that there >>>>> isn't a strong case to unmap the crashkernel reservation. Now, if we >>>>> place crashdump kernel image goes in the 'high' reservation, can we not >>>>> leave the 'low' reservation mapped? We don't really care about it as it >>>>> wouldn't have any meaningful code/data to be preserved. If the 'high' >>>>> one goes above 4G always, we don't depend on the arm64_dma_phys_limit. >>>> >>>> Yes, this looks ideal. While it only works when crashkernel=,high case and >>>> it succeeds to reserve a memory region for the specified size of >>>> crashkernel >>>> high memory. At below, we have 4 cases of crashkernel= syntax: >>>> >>>> crashkernel=size >>>> 1)first attempt: low memory under arm64_dma_phys_limit >>>> 2)fallback: finding memory above 4G >>> >>> (2) should be 'finding memory above arm64_dma_phys_limit' to keep the >>> current behaviour for RPi4. >>> >>>> crashkernel=size,high >>>> 3)first attempt: finding memory above 4G >>>> 4)fallback: low memory under arm64_dma_phys_limit >>> >>> Yes. >>> >>>> case 3) works with your suggestion. However, 1), 2), 4) all need to >>>> defer to bootmem_init(). With these cases and different handling, >>>> reserve_crashkernel() could be too complicated. >>> >>> Ah, because of the fallback below arm64_dma_phys_limit as in (4), we >>> still can't move the full crashkernel reservation early. Well, we could >>> do it in two steps: (a) early attempt at crashkernel reservation above >>> 4G if 'high' was specified and we avoid mapping it if successful and (b) >>> do the late crashkernel reservation below arm64_dma_phys_limit and skip >>> unmapping as being too late. This way most server-like platforms would >>> get a reservation above 4G, unmapped. >>> >>>> I am wondering if we can cancel the protection of crashkernel memory >>>> region on arm64 for now. In earlier discussion, people questioned if the >>>> protection is necessary on arm64. After comparison, I would rather take >>>> away the protection method of crashkernel region since they try to >>>> protect in a chance in one million , while the base page mapping for the >>>> whole linear mapping is mitigating arm64 high end server always. >>> >>> This works for me. We can add the protection later for addresses above >>> 4GB only as mentioned above. >> >> Recently, I've also been rethinking the performance issues when kdump is >> enabled. I have a new idea. For crashkernel=X, we can temporarily search >> for free memory from the low address to the high address. As below: >> >> save_bottom_up = memblock_bottom_up(); >> if (!high) >> memblock_set_bottom_up(true); >> crash_base = memblock_phys_alloc_range(crash_size, CRASH_ALIGN, crash_base, >> crash_max); >> memblock_set_bottom_up(save_bottom_up); >> >> The final code change should be small, and I'll try it today. > > I have sent a patchset to remove the crashkernel region protection code > as per Catalin's confirmation. I personally like the code conciseness w/o > protection because kinds of crahskernel reservation has been complex, > the situation on arm64 will makes it worse if we try to keep the > protection and fix the performance issue. While I am glad to see any > attempt to achieve the two goals if it's satisfactory. I saw the patchset. No protection is also a good idea, the code is simplified a lot. > > . > -- Regards, Zhen Lei ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v4] arm64: kdump: simplify the reservation behaviour of crashkernel=,high
On 2023/3/24 1:25, Catalin Marinas wrote: > On Mon, Mar 20, 2023 at 09:12:08PM +0800, Baoquan He wrote: >> On 03/17/23 at 06:05pm, Catalin Marinas wrote: >>> On Fri, Mar 17, 2023 at 11:09:13PM +0800, Baoquan He wrote: In fact, what I want to achieve is we set CRASH_ADDR_LOW_MAX to 4G fixedly on arm64, just like what we do on x86_64. As for RPi4 platform, we leave it to crashkernel=size@offset syntax. Two reasons for this: 1) crashkernel is needed on enterprise platform, such as workstation or server. While RPi4 is obviously not the target. I contacted several RPi4 players in Redhat and my friends, none of them ever played kdump testing. If they really have to, crashkernel=size@offset is enough for them to set. >>> >>> I'd like crashkernel=size (without @offset) on RPi4 to still do the >>> right thing: a low allocation at least as we had until recently (or >>> high+low where high here is maybe above 1GB). IOW, no regression for >>> this crashkernel=size case. We can then change the explicit >>> crashkernel=x,high to mean only above 4GB irrespective of the platform >>> and crashkernel=x,low to be below arm64_dma_phys_limit. >> >> Since crashkernel=,high and crashkernel=size fallback was added in arm64 >> recently, with my understanding, you are suggesting: >> >> on arm64: >> RPi4: >> crashkernel=size >> 0~1G: low memory (no regression introduced) > > And, if not enough low memory, fall back to memory above 1GB (for RPi4; > it would be above 4GB for any other system). > >> crashkernel=size,high >> 0~1G: low memory | 4G~top: high memory > > Yes. > >> Other normal system: >> crashkernel=size|crashkernel=size,high >> 0~4G: low memory | 4G~top: high memory > > Yes. > > IOW, specifying 'high' only forces the high allocation above 4GB instead > of arm64_dma_phys_limit, irrespective of the platform. If no 'high' > specified search_base remains CRASH_ADDR_LOW_MAX (1GB on RPi4, 4GB for > the rest). > 2) with the fixed CRASH_ADDR_LOW_MAX as 4G, we can easily fix the problem of base page mapping for the whole linear mapping if crsahkernel= is set in kernel parameter shown in [1] at bottom. >>> >>> That's a different problem ;). I should re-read that thread, forgot most >>> of the details but I recall one of the counter arguments was that there >>> isn't a strong case to unmap the crashkernel reservation. Now, if we >>> place crashdump kernel image goes in the 'high' reservation, can we not >>> leave the 'low' reservation mapped? We don't really care about it as it >>> wouldn't have any meaningful code/data to be preserved. If the 'high' >>> one goes above 4G always, we don't depend on the arm64_dma_phys_limit. >> >> Yes, this looks ideal. While it only works when crashkernel=,high case and >> it succeeds to reserve a memory region for the specified size of crashkernel >> high memory. At below, we have 4 cases of crashkernel= syntax: >> >> crashkernel=size >> 1)first attempt: low memory under arm64_dma_phys_limit >> 2)fallback: finding memory above 4G > > (2) should be 'finding memory above arm64_dma_phys_limit' to keep the > current behaviour for RPi4. > >> crashkernel=size,high >> 3)first attempt: finding memory above 4G >> 4)fallback: low memory under arm64_dma_phys_limit > > Yes. > >> case 3) works with your suggestion. However, 1), 2), 4) all need to >> defer to bootmem_init(). With these cases and different handling, >> reserve_crashkernel() could be too complicated. > > Ah, because of the fallback below arm64_dma_phys_limit as in (4), we > still can't move the full crashkernel reservation early. Well, we could > do it in two steps: (a) early attempt at crashkernel reservation above > 4G if 'high' was specified and we avoid mapping it if successful and (b) > do the late crashkernel reservation below arm64_dma_phys_limit and skip > unmapping as being too late. This way most server-like platforms would > get a reservation above 4G, unmapped. > >> I am wondering if we can cancel the protection of crashkernel memory >> region on arm64 for now. In earlier discussion, people questioned if the >> protection is necessary on arm64. After comparison, I would rather take >> away the protection method of crashkernel region since they try to >> protect in a chance in one million , while the base page mapping for the >> whole linear mapping is mitigating arm64 high end server always. > > This works for me. We can add the protection later for addresses above > 4GB only as mentioned above. Recently, I've also been rethinking the performance issues when kdump is enabled. I have a new idea. For crashkernel=X, we can temporarily search for free memory from the low address to the high address. As below: save_bottom_up = memblock_bottom_up(); if (!high) memblock_set_bottom_up(true); crash_base = memblock_phys_alloc_range(crash_size, CRASH_ALIGN, crash_base, crash_max); memblock_set_bottom_up(save_bottom_up); The final code change should
Re: [PATCH -next 2/2] docs: kdump: Update the crashkernel description for riscv
On 2023/3/21 4:42, Chen Jiahao wrote: > Now "crashkernel=" parameter on riscv has been updated to support > crashkernel=X,[high,low]. Through which we can reserve memory region > above/within 32bit addressible DMA zone. > > Here update the parameter description accordingly. Reviewed-by: Zhen Lei > > Signed-off-by: Chen Jiahao > --- > Documentation/admin-guide/kernel-parameters.txt | 15 --- > 1 file changed, 8 insertions(+), 7 deletions(-) > > diff --git a/Documentation/admin-guide/kernel-parameters.txt > b/Documentation/admin-guide/kernel-parameters.txt > index 6221a1d057dd..89e26a4864f8 100644 > --- a/Documentation/admin-guide/kernel-parameters.txt > +++ b/Documentation/admin-guide/kernel-parameters.txt > @@ -843,7 +843,7 @@ > memory region [offset, offset + size] for that kernel > image. If '@offset' is omitted, then a suitable offset > is selected automatically. > - [KNL, X86-64, ARM64] Select a region under 4G first, and > + [KNL, X86-64, ARM64, RISCV] Select a region under 4G > first, and > fall back to reserve region above 4G when '@offset' > hasn't been specified. > See Documentation/admin-guide/kdump/kdump.rst for > further details. > @@ -856,14 +856,14 @@ > Documentation/admin-guide/kdump/kdump.rst for an > example. > > crashkernel=size[KMG],high > - [KNL, X86-64, ARM64] range could be above 4G. Allow > kernel > - to allocate physical memory region from top, so could > - be above 4G if system have more than 4G ram installed. > - Otherwise memory region will be allocated below 4G, if > - available. > + [KNL, X86-64, ARM64, RISCV] range could be above 4G. > + Allow kernel to allocate physical memory region from > top, > + so could be above 4G if system have more than 4G ram > + installed. Otherwise memory region will be allocated > + below 4G, if available. > It will be ignored if crashkernel=X is specified. > crashkernel=size[KMG],low > - [KNL, X86-64, ARM64] range under 4G. When > crashkernel=X,high > + [KNL, X86-64, ARM64, RISCV] range under 4G. When > crashkernel=X,high > is passed, kernel could allocate physical memory region > above 4G, that cause second kernel crash on system > that require some amount of low memory, e.g. swiotlb > @@ -874,6 +874,7 @@ > size is platform dependent. > --> x86: max(swiotlb_size_or_default() + 8MiB, 256MiB) > --> arm64: 128MiB > + --> riscv: 128MiB > This one lets the user specify own low range under 4G > for second kernel instead. > 0: to disable low allocation. > -- Regards, Zhen Lei ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH -next 1/2] riscv: kdump: Implement crashkernel=X,[high,low]
On 2023/3/21 4:42, Chen Jiahao wrote:
> On riscv, the current crash kernel allocation logic is trying to
> allocate within 32bit addressible memory region by default, if
> failed, try to allocate without 4G restriction.
>
> In need of saving DMA zone memory while allocating a relatively large
> crash kernel region, allocating the reserved memory top down in
> high memory, without overlapping the DMA zone, is a mature solution.
> Here introduce the parameter option crashkernel=X,[high,low].
>
> We can reserve the crash kernel from high memory above DMA zone range
> by explicitly passing "crashkernel=X,high"; or reserve a memory range
> below 4G with "crashkernel=X,low".
>
> Signed-off-by: Chen Jiahao
> ---
> arch/riscv/kernel/setup.c | 5
> arch/riscv/mm/init.c | 56 ---
> 2 files changed, 58 insertions(+), 3 deletions(-)
>
> diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
> index 376d2827e736..d867b1535da4 100644
> --- a/arch/riscv/kernel/setup.c
> +++ b/arch/riscv/kernel/setup.c
> @@ -176,6 +176,11 @@ static void __init init_resources(void)
> if (ret < 0)
> goto error;
> }
> + if (crashk_low_res.start != crashk_low_res.end) {
> + ret = add_resource(_resource, _low_res);
> + if (ret < 0)
> + goto error;
> + }
> #endif
>
> #ifdef CONFIG_CRASH_DUMP
> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> index 478d6763a01a..5def2174b243 100644
> --- a/arch/riscv/mm/init.c
> +++ b/arch/riscv/mm/init.c
> @@ -1152,6 +1152,28 @@ static inline void setup_vm_final(void)
> }
> #endif /* CONFIG_MMU */
>
> +/* Reserve 128M low memory by default for swiotlb buffer */
> +#define DEFAULT_CRASH_KERNEL_LOW_SIZE(128UL << 20)
> +
> +static int __init reserve_crashkernel_low(unsigned long long low_size)
> +{
> + unsigned long long low_base;
> +
> + low_base = memblock_phys_alloc_range(low_size, PMD_SIZE, 0,
> dma32_phys_limit);
> + if (!low_base) {
> + pr_err("cannot allocate crashkernel low memory
> (size:0x%llx).\n", low_size);
> + return -ENOMEM;
> + }
> +
> + pr_info("crashkernel low memory reserved: 0x%08llx - 0x%08llx (%lld
> MB)\n",
For unsigned long long, 08 --> 016.
> + low_base, low_base + low_size, low_size >> 20);
> +
> + crashk_low_res.start = low_base;
> + crashk_low_res.end = low_base + low_size - 1;
> +
> + return 0;
> +}
> +
> /*
> * reserve_crashkernel() - reserves memory for crash kernel
> *
> @@ -1163,6 +1185,7 @@ static void __init reserve_crashkernel(void)
> {
> unsigned long long crash_base = 0;
> unsigned long long crash_size = 0;
> + unsigned long long crash_low_size = 0;
> unsigned long search_start = memblock_start_of_DRAM();
> unsigned long search_end = memblock_end_of_DRAM();
>
> @@ -1182,8 +1205,26 @@ static void __init reserve_crashkernel(void)
>
> ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
> _size, _base);
> - if (ret || !crash_size)
> + if (ret == -ENOENT) {
> + ret = parse_crashkernel_high(boot_command_line, 0, _size,
> _base);
> + if (ret || !crash_size)
> + return;
> +
> + /*
> + * crashkernel=Y,low can be specified or not, but invalid value
> + * is not allowed.
> + */
> + ret = parse_crashkernel_low(boot_command_line, 0,
> _low_size, _base);
> + if (ret == -ENOENT)
> + crash_low_size = DEFAULT_CRASH_KERNEL_LOW_SIZE;
> + else if (ret)
> + return;
> +
> + search_start = dma32_phys_limit;
> + } else if (ret || !crash_size) {
> + /* Invalid argument value specified */
> return;
> + }
>
> crash_size = PAGE_ALIGN(crash_size);
>
> @@ -1201,16 +1242,25 @@ static void __init reserve_crashkernel(void)
>*/
> crash_base = memblock_phys_alloc_range(crash_size, PMD_SIZE,
> search_start,
> -min(search_end, (unsigned long)
> SZ_4G));
> +min(search_end, (unsigned long)
> dma32_phys_limit));
> if (crash_base == 0) {
> /* Try again without restricting region to 32bit addressible
> memory */
> crash_base = memblock_phys_alloc_range(crash_size, PMD_SIZE,
> - search_start, search_end);
> +search_start,
> search_end);
> if (crash_base == 0) {
> pr_warn("crashkernel: couldn't allocate %lldKB\n",
> crash_size >> 10);
> return;
> }
> +
> +
Re: [PATCH v4] arm64: kdump: simplify the reservation behaviour of crashkernel=,high
On 2023/3/6 16:41, Baoquan He wrote:
> On arm64, reservation for 'crashkernel=xM,high' is taken by searching for
> suitable memory region top down. If the 'xM' of crashkernel high memory
> is reserved from high memory successfully, it will try to reserve
> crashkernel low memory later accoringly. Otherwise, it will try to search
> low memory area for the 'xM' suitable region. Please see the details in
> Documentation/admin-guide/kernel-parameters.txt.
>
> While we observed an unexpected case where a reserved region crosses the
> high and low meomry boundary. E.g on a system with 4G as low memory end,
> user added the kernel parameters like: 'crashkernel=512M,high', it could
> finally have [4G-126M, 4G+386M], [1G, 1G+128M] regions in running kernel.
> The crashkernel high region crossing low and high memory boudary will bring
> issues:
>
> 1) For crashkernel=x,high, if getting crashkernel high region across
> low and high memory boundary, then user will see two memory regions in
> low memory, and one memory region in high memory. The two crashkernel
> low memory regions are confusing as shown in above example.
>
> 2) If people explicityly specify "crashkernel=x,high crashkernel=y,low"
> and y <= 128M, when crashkernel high region crosses low and high memory
> boundary and the part of crashkernel high reservation below boundary is
> bigger than y, the expected crahskernel low reservation will be skipped.
> But the expected crashkernel high reservation is shrank and could not
> satisfy user space requirement.
>
> 3) The crossing boundary behaviour of crahskernel high reservation is
> different than x86 arch. On x86_64, the low memory end is 4G fixedly,
> and the memory near 4G is reserved by system, e.g for mapping firmware,
> pci mapping, so the crashkernel reservation crossing boundary never happens.
>>From distros point of view, this brings inconsistency and confusion. Users
> need to dig into x86 and arm64 system details to find out why.
>
> For kernel itself, the impact of issue 3) could be slight. While issue
> 1) and 2) cause actual impact because it brings obscure semantics and
> behaviour to crashkernel=,high reservation.
>
> Here, for crashkernel=xM,high, search the high memory for the suitable
> region only in high memory. If failed, try reserving the suitable
> region only in low memory. Like this, the crashkernel high region will
> only exist in high memory, and crashkernel low region only exists in low
> memory. The reservation behaviour for crashkernel=,high is clearer and
> simpler.
>
> Note: On arm64, the high and low memory boudary could be 1G if it's RPi4
> system, or 4G if other normal systems.
Reviewed-by: Zhen Lei
>
> Signed-off-by: Baoquan He
> ---
> Change history:
> v3->v4:
> - Change pr_info() to pr_warn() when fixed allocation failed. Leizhen
>pointed out this and suggested changing.
> v2->v3:
> - Rephrase patch log to clarify the current crashkernel high
>reservation could cross the high and low memory boundary, but not
>4G boundary only, because RPi4 of arm64 has high and low memory
>boudary as 1G. The v3 patch log could mislead people that the RPi4
>also use 4G as high,low memory boundary.
> v1->v2:
> - Fold patch 2 of v1 into patch 1 for better reviewing.
> - Update patch log to add more details.
>
> arch/arm64/mm/init.c | 43 +--
> 1 file changed, 33 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 58a0bb2c17f1..307763f97549 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -127,12 +127,13 @@ static int __init reserve_crashkernel_low(unsigned long
> long low_size)
> */
> static void __init reserve_crashkernel(void)
> {
> - unsigned long long crash_base, crash_size;
> - unsigned long long crash_low_size = 0;
> + unsigned long long crash_base, crash_size, search_base;
> unsigned long long crash_max = CRASH_ADDR_LOW_MAX;
> + unsigned long long crash_low_size = 0;
> char *cmdline = boot_command_line;
> - int ret;
> bool fixed_base = false;
> + bool high = false;
> + int ret;
>
> if (!IS_ENABLED(CONFIG_KEXEC_CORE))
> return;
> @@ -155,7 +156,9 @@ static void __init reserve_crashkernel(void)
> else if (ret)
> return;
>
> + search_base = CRASH_ADDR_LOW_MAX;
> crash_max = CRASH_ADDR_HIGH_MAX;
> + high = true;
> } else if (ret || !crash_size) {
> /* The specified value is invalid */
> return;
> @@ -166,31 +169,51 @@ static void __init reserve_crashkernel(void)
> /* User specifies base address explicitly. */
> if (crash_base) {
> fixed_base = true;
> + search_base = crash_base;
> crash_max = crash_base + crash_size;
> }
>
> retry:
> crash_base = memblock_phys_alloc_range(crash_size,
Re: [PATCH v3] arm64: kdump: simplify the reservation behaviour of crashkernel=,high
On 2023/3/3 11:01, Baoquan He wrote:
> On 03/02/23 at 11:32am, Leizhen (ThunderTown) wrote:
> ..
>>> @@ -166,31 +169,51 @@ static void __init reserve_crashkernel(void)
>>> /* User specifies base address explicitly. */
>>> if (crash_base) {
>>> fixed_base = true;
>>> + search_base = crash_base;
>>> crash_max = crash_base + crash_size;
>>> }
>>>
>>> retry:
>>> crash_base = memblock_phys_alloc_range(crash_size, CRASH_ALIGN,
>>> - crash_base, crash_max);
>>> + search_base, crash_max);
>>> if (!crash_base) {
>>> /*
>>> -* If the first attempt was for low memory, fall back to
>>> -* high memory, the minimum required low memory will be
>>> -* reserved later.
>>> +* For crashkernel=size[KMG]@offset[KMG], print out failure
>>> +* message if can't reserve the specified region.
>>> */
>>> - if (!fixed_base && (crash_max == CRASH_ADDR_LOW_MAX)) {
>>> + if (fixed_base) {
>>> + pr_info("crashkernel reservation failed - memory is in
>>> use.\n");
>>
>> How about changing pr_info to pr_warn?
>>
>>> + return;
>>> + }
>>> +
>>> + /*
>>> +* For crashkernel=size[KMG], if the first attempt was for
>>> +* low memory, fall back to high memory, the minimum required
>>> +* low memory will be reserved later.
>>> +*/
>>> + if (!high && crash_max == CRASH_ADDR_LOW_MAX) {
>>> crash_max = CRASH_ADDR_HIGH_MAX;
>>> + search_base = CRASH_ADDR_LOW_MAX;
>>> crash_low_size = DEFAULT_CRASH_KERNEL_LOW_SIZE;
>>> goto retry;
>>> }
>>>
>>> + /*
>>> +* For crashkernel=size[KMG],high, if the first attempt was
>>> +* for high memory, fall back to low memory.
>>> +*/
>>> + if (high && crash_max == CRASH_ADDR_HIGH_MAX) {
>>
>> Adding unlikely to indicate that it is rare would be better.
>>
>> if (unlikely(high && crash_max == CRASH_ADDR_HIGH_MAX))
>
> Rethink about this and checked code in kernel, seems likely|unlikely are
> mostly used in highly frequent execution branch optimize code path, while
> crashkernel resevatoin is one time execution during boot, we may not
> need to bother to add unlikely. What do you think?
OK.
>
>
>>
>>> + crash_max = CRASH_ADDR_LOW_MAX;
>>> + search_base = 0;
>>> + goto retry;
>>> + }
>>> pr_warn("cannot allocate crashkernel (size:0x%llx)\n",
>>> crash_size);
>>> return;
>>> }
>>>
>>> - if ((crash_base > CRASH_ADDR_LOW_MAX - crash_low_size) &&
>>> -crash_low_size && reserve_crashkernel_low(crash_low_size)) {
>>> + if ((crash_base >= CRASH_ADDR_LOW_MAX) && crash_low_size &&
>>> +reserve_crashkernel_low(crash_low_size)) {
>>> memblock_phys_free(crash_base, crash_size);
>>> return;
>>> }
>>>
>>
>> --
>> Regards,
>> Zhen Lei
>>
>
> .
>
--
Regards,
Zhen Lei
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v3] arm64: kdump: simplify the reservation behaviour of crashkernel=,high
On 2023/2/23 20:45, Baoquan He wrote:
> On arm64, reservation for 'crashkernel=xM,high' is taken by searching for
> suitable memory region top down. If the 'xM' of crashkernel high memory
> is reserved from high memory successfully, it will try to reserve
> crashkernel low memory later accoringly. Otherwise, it will try to search
> low memory area for the 'xM' suitable region. Please see the details in
> Documentation/admin-guide/kernel-parameters.txt.
>
> While we observed an unexpected case where a reserved region crosses the
> high and low meomry boundary. E.g on a system with 4G as low memory end,
> user added the kernel parameters like: 'crashkernel=512M,high', it could
> finally have [4G-126M, 4G+386M], [1G, 1G+128M] regions in running kernel.
> The crashkernel high region crossing low and high memory boudary will bring
> issues:
>
> 1) For crashkernel=x,high, if getting crashkernel high region across
> low and high memory boundary, then user will see two memory regions in
> low memory, and one memory region in high memory. The two crashkernel
> low memory regions are confusing as shown in above example.
>
> 2) If people explicityly specify "crashkernel=x,high crashkernel=y,low"
> and y <= 128M, when crashkernel high region crosses low and high memory
> boundary and the part of crashkernel high reservation below boundary is
> bigger than y, the expected crahskernel low reservation will be skipped.
> But the expected crashkernel high reservation is shrank and could not
> satisfy user space requirement.
>
> 3) The crossing boundary behaviour of crahskernel high reservation is
> different than x86 arch. On x86_64, the low memory end is 4G fixedly,
> and the memory near 4G is reserved by system, e.g for mapping firmware,
> pci mapping, so the crashkernel reservation crossing boundary never happens.
>>From distros point of view, this brings inconsistency and confusion. Users
> need to dig into x86 and arm64 system details to find out why.
>
> For kernel itself, the impact of issue 3) could be slight. While issue
> 1) and 2) cause actual impact because it brings obscure semantics and
> behaviour to crashkernel=,high reservation.
>
> Here, for crashkernel=xM,high, search the high memory for the suitable
> region only in high memory. If failed, try reserving the suitable
> region only in low memory. Like this, the crashkernel high region will
> only exist in high memory, and crashkernel low region only exists in low
> memory. The reservation behaviour for crashkernel=,high is clearer and
> simpler.
>
> Note: On arm64, the high and low memory boudary could be 1G if it's RPi4
> system, or 4G if other normal systems.
There are two minor review comments, see below. Otherwise:
Reviewed-by: Zhen Lei
>
> Signed-off-by: Baoquan He
> ---
> v2->v3:
> - Rephrase patch log to clarify the current crashkernel high
>reservation could cross the high and low memory boundary, but not
>4G boundary only, because RPi4 of arm64 has high and low memory
>boudary as 1G. The v3 patch log could mislead people that the RPi4
>also use 4G as high,low memory boundary.
> v1->v2:
> - Fold patch 2 of v1 into patch 1 for better reviewing.
> - Update patch log to add more details.
> arch/arm64/mm/init.c | 43 +--
> 1 file changed, 33 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 58a0bb2c17f1..b8cb780df0cb 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -127,12 +127,13 @@ static int __init reserve_crashkernel_low(unsigned long
> long low_size)
> */
> static void __init reserve_crashkernel(void)
> {
> - unsigned long long crash_base, crash_size;
> - unsigned long long crash_low_size = 0;
> + unsigned long long crash_base, crash_size, search_base;
> unsigned long long crash_max = CRASH_ADDR_LOW_MAX;
> + unsigned long long crash_low_size = 0;
> char *cmdline = boot_command_line;
> - int ret;
> bool fixed_base = false;
> + bool high = false;
> + int ret;
>
> if (!IS_ENABLED(CONFIG_KEXEC_CORE))
> return;
> @@ -155,7 +156,9 @@ static void __init reserve_crashkernel(void)
> else if (ret)
> return;
>
> + search_base = CRASH_ADDR_LOW_MAX;
> crash_max = CRASH_ADDR_HIGH_MAX;
> + high = true;
> } else if (ret || !crash_size) {
> /* The specified value is invalid */
> return;
> @@ -166,31 +169,51 @@ static void __init reserve_crashkernel(void)
> /* User specifies base address explicitly. */
> if (crash_base) {
> fixed_base = true;
> + search_base = crash_base;
> crash_max = crash_base + crash_size;
> }
>
> retry:
> crash_base = memblock_phys_alloc_range(crash_size, CRASH_ALIGN,
> -crash_base, crash_max);
> +
Re: [PATCH v4 2/2] arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones
On 2022/11/21 16:31, Baoquan He wrote:
> On 11/16/22 at 08:10pm, Zhen Lei wrote:
>> For crashkernel=X without '@offset', select a region within DMA zones
>> first, and fall back to reserve region above DMA zones. This allows
>> users to use the same configuration on multiple platforms.
>>
>> Signed-off-by: Zhen Lei
>> Acked-by: Baoquan He
>> ---
>> Documentation/admin-guide/kernel-parameters.txt | 2 +-
>> arch/arm64/mm/init.c| 17 -
>> 2 files changed, 17 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt
>> b/Documentation/admin-guide/kernel-parameters.txt
>> index a7b7147447b8bf8..ef6d922ed26b9dc 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -842,7 +842,7 @@
>> memory region [offset, offset + size] for that kernel
>> image. If '@offset' is omitted, then a suitable offset
>> is selected automatically.
>> -[KNL, X86-64] Select a region under 4G first, and
>> +[KNL, X86-64, ARM64] Select a region under 4G first, and
>> fall back to reserve region above 4G when '@offset'
>> hasn't been specified.
>> See Documentation/admin-guide/kdump/kdump.rst for
>> further details.
>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>> index ba7227179822d10..58a0bb2c17f18cf 100644
>> --- a/arch/arm64/mm/init.c
>> +++ b/arch/arm64/mm/init.c
>> @@ -132,6 +132,7 @@ static void __init reserve_crashkernel(void)
>> unsigned long long crash_max = CRASH_ADDR_LOW_MAX;
>> char *cmdline = boot_command_line;
>> int ret;
>> +bool fixed_base = false;
>>
>> if (!IS_ENABLED(CONFIG_KEXEC_CORE))
>> return;
>> @@ -163,12 +164,26 @@ static void __init reserve_crashkernel(void)
>> crash_size = PAGE_ALIGN(crash_size);
>>
>> /* User specifies base address explicitly. */
>> -if (crash_base)
>> +if (crash_base) {
>> +fixed_base = true;
>> crash_max = crash_base + crash_size;
>> +}
>>
>> +retry:
>> crash_base = memblock_phys_alloc_range(crash_size, CRASH_ALIGN,
>> crash_base, crash_max);
>
> This pachset looks good to me. While we observed a unexpected case,
> where a reserved region cross the high and low meomry region. I noticed
> Catalin has pointed that out. Even with the suggested code, we could
> have the kernel parameters like: crashkernel=512M,high
> crashkernel=128M,low, we finally have [4G-126M, 4G+386M], [1G, 1G+128M]
> regions in running kernel. This looks strange.
Is high-end memory fragmented? Add boot option memblock=debug and watch?
>
> I am wondering if we can specify explicit search_base in
> memblock_phys_alloc_range() to avoid above case. Like this,
> crashkernel,high region will only exist in high memory, crashkernel,low
> region only exists in low memory region. I made a draft patch based on
> this patchset to present what the code looks like.
Looks good to me.
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 58a0bb2c17f1..fd9d35e17a62 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -127,7 +127,7 @@ static int __init reserve_crashkernel_low(unsigned long
> long low_size)
> */
> static void __init reserve_crashkernel(void)
> {
> - unsigned long long crash_base, crash_size;
> + unsigned long long crash_base, crash_size, search_base;
search_base needs to be initialized to 0.
> unsigned long long crash_low_size = 0;
> unsigned long long crash_max = CRASH_ADDR_LOW_MAX;
> char *cmdline = boot_command_line;
> @@ -155,6 +155,7 @@ static void __init reserve_crashkernel(void)
> else if (ret)
> return;
>
> + search_base = CRASH_ADDR_LOW_MAX;
> crash_max = CRASH_ADDR_HIGH_MAX;
> } else if (ret || !crash_size) {
> /* The specified value is invalid */
> @@ -166,12 +167,13 @@ static void __init reserve_crashkernel(void)
> /* User specifies base address explicitly. */
> if (crash_base) {
> fixed_base = true;
> + search_base = crash_base;
> crash_max = crash_base + crash_size;
> }
>
> retry:
> crash_base = memblock_phys_alloc_range(crash_size, CRASH_ALIGN,
> -crash_base, crash_max);
> +search_base, crash_max);
> if (!crash_base) {
> /*
>* If the first attempt was for low memory, fall back to
> @@ -180,6 +182,7 @@ static void __init reserve_crashkernel(void)
>*/
> if (!fixed_base && (crash_max == CRASH_ADDR_LOW_MAX)) {
> crash_max = CRASH_ADDR_HIGH_MAX;
> +
Re: [PATCH v3 1/2] arm64: kdump: Provide default size when crashkernel=Y,low is not specified
On 2022/11/7 22:07, Catalin Marinas wrote: > On Mon, Jul 11, 2022 at 05:03:18PM +0800, Zhen Lei wrote: >> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c >> index 339ee84e5a61a0b..5390f361208ccf7 100644 >> --- a/arch/arm64/mm/init.c >> +++ b/arch/arm64/mm/init.c >> @@ -96,6 +96,14 @@ phys_addr_t __ro_after_init arm64_dma_phys_limit = >> PHYS_MASK + 1; >> #define CRASH_ADDR_LOW_MAX arm64_dma_phys_limit >> #define CRASH_ADDR_HIGH_MAX (PHYS_MASK + 1) >> >> +/* >> + * This is an empirical value in x86_64 and taken here directly. Please >> + * refer to the code comment in reserve_crashkernel_low() of x86_64 for more >> + * details. >> + */ >> +#define DEFAULT_CRASH_KERNEL_LOW_SIZE \ >> +max(swiotlb_size_or_default() + (8UL << 20), 256UL << 20) > > I agree with Will here, we need a better comment and we might as well > change the default value to something else until someone tells us that > the default is not large enough. The default swiotlb size is 64M, so we > need to cover that. The extra 8MB for any additional low allocations are > ok as well but the 256MB doesn't make much sense to me, or at least not > together with the rest. > > If the main kernel got a command line option for a larger swiotlb, does > the crash kernel boot with the same command line? If not, we can just go Sometimes the image is shared, but the command line is often different. The command line of the crash kernel is specified by kexec --append=. > for a fixed 128M value here, which is double the default swiotlb buffer. Sorry, I missed this e-mail. Yes, fixed 128M would be better. I haven't seen anyone adding "swiotlb=" to the crash kernel. And, if the default size isn't enough, he can use crashkernel=Y,low. > -- Regards, Zhen Lei ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v3 0/2] arm64: kdump: Function supplement and performance optimization
On 2022/11/15 21:30, Catalin Marinas wrote: > On Tue, Nov 15, 2022 at 08:18:21PM +0800, Leizhen (ThunderTown) wrote: >> On 2022/11/15 19:58, Will Deacon wrote: >>> On Mon, Jul 11, 2022 at 05:03:17PM +0800, Zhen Lei wrote: >>>> v2 --> v3: >>>> 1. Discard patch 3 in v2, a cleanup patch. >>> >>> Do you plan to respin this series, addressing the various comments on v3? >> >> Yes, I haven't figured out where to make DEFAULT_CRASH_KERNEL_LOW_SIZE >> generic. > > Do we need to? I'd just go with something like 128MB, specific to arm64, > and we can increase it later if anyone comes up with a good argument. Okay, then v3's easy. I'll do it tomorrow. I've tried it before. 128M is enough. > -- Regards, Zhen Lei ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v3 0/2] arm64: kdump: Function supplement and performance optimization
On 2022/11/15 19:58, Will Deacon wrote: > On Mon, Jul 11, 2022 at 05:03:17PM +0800, Zhen Lei wrote: >> v2 --> v3: >> 1. Discard patch 3 in v2, a cleanup patch. > > Do you plan to respin this series, addressing the various comments on v3? Yes, I haven't figured out where to make DEFAULT_CRASH_KERNEL_LOW_SIZE generic. > > Will > . > -- Regards, Zhen Lei ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v3 1/2] arm64: kdump: Provide default size when crashkernel=Y,low is not specified
On 2022/11/8 1:18, Catalin Marinas wrote:
> On Mon, Jul 11, 2022 at 05:03:18PM +0800, Zhen Lei wrote:
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt
>> b/Documentation/admin-guide/kernel-parameters.txt
>> index 2522b11e593f239..65a2c3a22a4b57d 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -843,7 +843,7 @@
>> available.
>> It will be ignored if crashkernel=X is specified.
>> crashkernel=size[KMG],low
>> -[KNL, X86-64] range under 4G. When crashkernel=X,high
>> +[KNL, X86-64, ARM64] range under 4G. When
>> crashkernel=X,high
>> is passed, kernel could allocate physical memory region
>> above 4G, that cause second kernel crash on system
>> that require some amount of low memory, e.g. swiotlb
>> @@ -857,12 +857,6 @@
>> It will be ignored when crashkernel=X,high is not used
>> or memory reserved is below 4G.
>>
>> -[KNL, ARM64] range in low memory.
>> -This one lets the user specify a low range in the
>> -DMA zone for the crash dump kernel.
>> -It will be ignored when crashkernel=X,high is not used
>> -or memory reserved is located in the DMA zones.
>> -
>> cryptomgr.notests
>> [KNL] Disable crypto self-tests
>>
>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>> index 339ee84e5a61a0b..5390f361208ccf7 100644
>> --- a/arch/arm64/mm/init.c
>> +++ b/arch/arm64/mm/init.c
>> @@ -96,6 +96,14 @@ phys_addr_t __ro_after_init arm64_dma_phys_limit =
>> PHYS_MASK + 1;
>> #define CRASH_ADDR_LOW_MAX arm64_dma_phys_limit
>> #define CRASH_ADDR_HIGH_MAX (PHYS_MASK + 1)
>>
>> +/*
>> + * This is an empirical value in x86_64 and taken here directly. Please
>> + * refer to the code comment in reserve_crashkernel_low() of x86_64 for more
>> + * details.
>> + */
>> +#define DEFAULT_CRASH_KERNEL_LOW_SIZE \
>> +max(swiotlb_size_or_default() + (8UL << 20), 256UL << 20)
>> +
>> static int __init reserve_crashkernel_low(unsigned long long low_size)
>> {
>> unsigned long long low_base;
>> @@ -147,7 +155,9 @@ static void __init reserve_crashkernel(void)
>> * is not allowed.
>> */
>> ret = parse_crashkernel_low(cmdline, 0, _low_size,
>> _base);
>> -if (ret && (ret != -ENOENT))
>> +if (ret == -ENOENT)
>> +crash_low_size = DEFAULT_CRASH_KERNEL_LOW_SIZE;
>> +else if (ret)
>> return;
>
> BTW, since we want a default low allocation, I think we should change
> the checking logic slightly. Currently we have:
>
> if ((crash_base >= CRASH_ADDR_LOW_MAX) &&
>crash_low_size && reserve_crashkernel_low(crash_low_size)) {
> ...
>
> If crash_base is just below CRASH_ADDR_LOW_MAX, we deem it sufficient
> but a crashkernel trying to allocate 64MB of swiotlb may fail. So maybe
> change this to crash_base >= CRASH_ADDR_LOW_MAX - crash_low_size.
The equal sign needs to be removed.
The situation should be the allocation of "crashkernel=X,high".
This possibility is too small, the high memory is unlikely to be that small.
memblock_phys_alloc_range() always search for memory block from high addresses
to low addresses. In the initial phase, high-end memory is not fragmented.
Of course, the modification can make people look more reassuring. OK, I'll
update it.
>
--
Regards,
Zhen Lei
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v3 2/2] arm64: kdump: Support crashkernel=X fall back to reserve region above DMA zones
On 2022/11/8 1:13, Catalin Marinas wrote:
> On Mon, Jul 11, 2022 at 05:03:19PM +0800, Zhen Lei wrote:
>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>> index 5390f361208ccf7..8539598f9e58b4d 100644
>> --- a/arch/arm64/mm/init.c
>> +++ b/arch/arm64/mm/init.c
>> @@ -138,6 +138,7 @@ static void __init reserve_crashkernel(void)
>> unsigned long long crash_max = CRASH_ADDR_LOW_MAX;
>> char *cmdline = boot_command_line;
>> int ret;
>> +bool fixed_base;
>>
>> if (!IS_ENABLED(CONFIG_KEXEC_CORE))
>> return;
>> @@ -166,15 +167,28 @@ static void __init reserve_crashkernel(void)
>> return;
>> }
>>
>> +fixed_base = !!crash_base;
>> crash_size = PAGE_ALIGN(crash_size);
>>
>> /* User specifies base address explicitly. */
>> -if (crash_base)
>> +if (fixed_base)
>> crash_max = crash_base + crash_size;
>
> Not a fan of '!!', it is converted automatically. If you don't like the
> conversion, just initialise fixed_base to false and here:
>
> if (crash_base) {
> fixed_base = true;
OK, This way would be better.
> crash_max = crash_base + crash_size;
> }
>
>> +retry:
>> crash_base = memblock_phys_alloc_range(crash_size, CRASH_ALIGN,
>> crash_base, crash_max);
>> if (!crash_base) {
>> +/*
>> + * Attempt to fully allocate low memory failed, fall back
>> + * to high memory, the minimum required low memory will be
>> + * reserved later.
>> + */
>
> I'm not sure this comment makes sense. If !crash_base, it doesn't mean
> the kernel failed to fully allocate low memory. crash_max here could be
> CRASH_ADDR_HIGH_MAX if crashkerne=X,high was specified. Maybe says
> something like "If the first attempt was for low memory, fall back to
> high ..."
This description is accurate. I'll update. Thanks.
>
>> +if (!fixed_base && (crash_max == CRASH_ADDR_LOW_MAX)) {
>> +crash_max = CRASH_ADDR_HIGH_MAX;
>> +crash_low_size = DEFAULT_CRASH_KERNEL_LOW_SIZE;
>> +goto retry;
>> +}
>
> The retry logic looks fine, it only happens once as crash_max is
> updated.
>
--
Regards,
Zhen Lei
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v21 0/5] support reserving crashkernel above 4G on arm64 kdump
On 2022/4/8 17:32, Baoquan He wrote:
> Hi, Lei
>
> On 02/27/22 at 11:07am, Zhen Lei wrote:
>> Changes since [v20]:
>> 1. Check whether crashkernel=Y,low is incorrectly configured or not
>> configured. Do different processing.
>> 2. Share the existing description of x86. The configuration of arm64 is the
>> same as that of x86.
>> 3. Define the value of macro CRASH_ADDR_HIGH_MAX as memblock.current_limit,
>> instead of MEMBLOCK_ALLOC_ACCESSIBLE.
>> 4. To improve readability, some lightweight code adjustments have been made
>> to reserve_craskernel(), including comments.
>> 5. The defined value of DEFAULT_CRASH_KERNEL_LOW_SIZE reconsiders swiotlb,
>> just like x86, to share documents.
>
> 5.18 rc1 is already done, do you have plan to post a new version for
> reviewing?
Yes, v5.18-rc1 has added a new patch
commit 031495635b46 ("arm64: Do not defer reserve_crashkernel() for platforms
with no DMA memory zones")
to allow block mapping again, so my patches need to be modified. It should be
post next week.
>
> Thanks
> Baoquan
>
> .
>
--
Regards,
Zhen Lei
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v21 3/5] arm64: kdump: reimplement crashkernel=X
On 2022/3/21 21:29, John Donnelly wrote:
> On 2/26/22 9:07 PM, Zhen Lei wrote:
>> From: Chen Zhou
>>
>> There are following issues in arm64 kdump:
>> 1. We use crashkernel=X to reserve crashkernel below 4G, which
>> will fail when there is no enough low memory.
>
> " Not enough "
OK, thanks
>> 2. If reserving crashkernel above 4G, in this case, crash dump
>> kernel will boot failure because there is no low memory available
>> for allocation.
>
> We can't have a "boot failure". If the requested reservation
> can not be met, the kdump configuration is not setup.
>>
>> To solve these issues, change the behavior of crashkernel=X and
>> introduce crashkernel=X,[high,low]. crashkernel=X tries low allocation
>> in DMA zone, and fall back to high allocation if it fails.
>> We can also use "crashkernel=X,high" to select a region above DMA zone,
>> which also tries to allocate at least 256M in DMA zone automatically.
>> "crashkernel=Y,low" can be used to allocate specified size low memory.
>
> Is there going to be documentation on what values certain Arm platforms are
> going to use this on ?
There is no exact formula.
>
>>
>> Signed-off-by: Chen Zhou
>> Co-developed-by: Zhen Lei
>> Signed-off-by: Zhen Lei
>> ---
>> arch/arm64/kernel/machine_kexec.c | 9 ++-
>> arch/arm64/kernel/machine_kexec_file.c | 12 ++-
>> arch/arm64/mm/init.c | 106 +++--
>> 3 files changed, 115 insertions(+), 12 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/machine_kexec.c
>> b/arch/arm64/kernel/machine_kexec.c
>> index e16b248699d5c3c..19c2d487cb08feb 100644
>> --- a/arch/arm64/kernel/machine_kexec.c
>> +++ b/arch/arm64/kernel/machine_kexec.c
>> @@ -329,8 +329,13 @@ bool crash_is_nosave(unsigned long pfn)
>> /* in reserved memory? */
>> addr = __pfn_to_phys(pfn);
>> - if ((addr < crashk_res.start) || (crashk_res.end < addr))
>> - return false;
>> + if ((addr < crashk_res.start) || (crashk_res.end < addr)) {
>> + if (!crashk_low_res.end)
>> + return false;
>> +
>> + if ((addr < crashk_low_res.start) || (crashk_low_res.end < addr))
>> + return false;
>> + }
>> if (!kexec_crash_image)
>> return true;
>> diff --git a/arch/arm64/kernel/machine_kexec_file.c
>> b/arch/arm64/kernel/machine_kexec_file.c
>> index 59c648d51848886..889951291cc0f9c 100644
>> --- a/arch/arm64/kernel/machine_kexec_file.c
>> +++ b/arch/arm64/kernel/machine_kexec_file.c
>> @@ -65,10 +65,18 @@ static int prepare_elf_headers(void **addr, unsigned
>> long *sz)
>> /* Exclude crashkernel region */
>> ret = crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
>> + if (ret)
>> + goto out;
>> +
>> + if (crashk_low_res.end) {
>> + ret = crash_exclude_mem_range(cmem, crashk_low_res.start,
>> crashk_low_res.end);
>> + if (ret)
>> + goto out;
>> + }
>> - if (!ret)
>> - ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
>> + ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
>> +out:
>> kfree(cmem);
>> return ret;
>> }
>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>> index 90f276d46b93bc6..30ae6638ff54c47 100644
>> --- a/arch/arm64/mm/init.c
>> +++ b/arch/arm64/mm/init.c
>> @@ -65,6 +65,44 @@ EXPORT_SYMBOL(memstart_addr);
>> phys_addr_t arm64_dma_phys_limit __ro_after_init;
>> #ifdef CONFIG_KEXEC_CORE
>> +/* Current arm64 boot protocol requires 2MB alignment */
>> +#define CRASH_ALIGN SZ_2M
>> +
>> +#define CRASH_ADDR_LOW_MAX arm64_dma_phys_limit
>> +#define CRASH_ADDR_HIGH_MAX memblock.current_limit
>> +
>> +/*
>> + * This is an empirical value in x86_64 and taken here directly. Please
>> + * refer to the code comment in reserve_crashkernel_low() of x86_64 for more
>> + * details.
>> + */
>> +#define DEFAULT_CRASH_KERNEL_LOW_SIZE \
>> + max(swiotlb_size_or_default() + (8UL << 20), 256UL << 20)
>> +
>> +static int __init reserve_crashkernel_low(unsigned long long low_size)
>> +{
>> + unsigned long long low_base;
>> +
>> + /* passed with crashkernel=0,low ? */
>> + if (!low_size)
>> + return 0;
>> +
>> + low_base = memblock_phys_alloc_range(low_size, CRASH_ALIGN, 0,
>> CRASH_ADDR_LOW_MAX);
>> + if (!low_base) {
>> + pr_err("cannot allocate crashkernel low memory (size:0x%llx).\n",
>> low_size);
>> + return -ENOMEM;
>> + }
>> +
>> + pr_info("crashkernel low memory reserved: 0x%08llx - 0x%08llx (%lld
>> MB)\n",
>> + low_base, low_base + low_size, low_size >> 20);
>> +
>> + crashk_low_res.start = low_base;
>> + crashk_low_res.end = low_base + low_size - 1;
>> + insert_resource(_resource, _low_res);
>> +
>> + return 0;
>> +}
>> +
>> /*
>> * reserve_crashkernel() - reserves memory for crash kernel
>> *
>> @@ -75,30 +113,79 @@ phys_addr_t arm64_dma_phys_limit __ro_after_init;
>>
Re: [PATCH v21 3/5] arm64: kdump: reimplement crashkernel=X
On 2022/3/17 11:47, Baoquan He wrote:
> On 03/17/22 at 11:19am, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2022/3/17 10:36, Baoquan He wrote:
>>> On 03/16/22 at 09:11pm, Leizhen (ThunderTown) wrote:
>>>>
>>>>
>>>> On 2022/3/16 20:11, Baoquan He wrote:
>>>>> On 02/27/22 at 11:07am, Zhen Lei wrote:
>>> ..
>>>
>>>>> Hi leizhen,
>>>>>
>>>>> I made change on reserve_crashkenrel(), inline comment may be slow.
>>>>> Please check and consider if they can be taken.
>>>>
>>>> That's great. Thank you very much.
>>>>
>>>>>
>>>>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>>>>> index 30ae6638ff54..f96351da1e3e 100644
>>>>> --- a/arch/arm64/mm/init.c
>>>>> +++ b/arch/arm64/mm/init.c
>>>>> @@ -109,38 +109,43 @@ static int __init reserve_crashkernel_low(unsigned
>>>>> long long low_size)
>>>>> * This function reserves memory area given in "crashkernel=" kernel
>>>>> command
>>>>> * line parameter. The memory reserved is used by dump capture kernel
>>>>> when
>>>>> * primary kernel is crashing.
>>>>> + *
>>>>> + * NOTE: Reservation of crashkernel,low is special since its existence
>>>>> + * is not independent, need rely on the existence of crashkernel,high.
>>>>> + * Hence there are different cases for crashkernel,low reservation:
>>>
>>> Considering to update the 3rd line as below:
>>>
>>> * NOTE: Reservation of crashkernel,low is special since its existence
>>> * is not independent, need rely on the existence of crashkernel,high.
>>> * Here, four cases of crashkernel,low reservation are summarized:
>>
>> OK. How about change "crashkernel,low" to "crashkernel low memory"?
>> "crashkernel=Y,low", "crashkernel=,low" and "crashkernel,low" are very
>> similar,
>> may dazzle the reader.
>
> Fine by me. 'crashkernel low memory' is formal, just make sentence a
> little longer. Please take what you think fitter.
OK, I will send v22 after v5.18-rc1.
>
>>
>>>
>>>>> + * 1) crashkernel=Y,low is specified explicitly, crashkernel,low takes Y;
>>>>> + * 2) crashkernel=,low is not given, while crashkernel=,high is
>>>>> specified,
>>>>> + *take the default crashkernel,low value;
>>>>> + * 3) crashkernel=X is specified, while fallback to get a memory region
>>>>> + *in high memory, take the default crashkernel,low value;
>>>>> + * 4) crashkernel='invalid value',low is specified, failed the whole
>>>>> + *crashkernel reservation and bail out.
>>>>> */
>>>>> static void __init reserve_crashkernel(void)
>>>>> {
>>>>> unsigned long long crash_base, crash_size;
>>>>> unsigned long long crash_low_size;
>>>>> unsigned long long crash_max = CRASH_ADDR_LOW_MAX;
>>>>> - int ret;
>>>>> bool fixed_base, high = false;
>>>>> char *cmdline = boot_command_line;
>>>>> + int ret;
>>>>>
>>>>> /* crashkernel=X[@offset] */
>>>>> ret = parse_crashkernel(cmdline, memblock_phys_mem_size(),
>>>>> _size, _base);
>>>>> if (ret || !crash_size) {
>>>>> - /* crashkernel=X,high */
>>>>> ret = parse_crashkernel_high(cmdline, 0, _size,
>>>>> _base);
>>>>> if (ret || !crash_size)
>>>>> return;
>>>>>
>>>>> - /* crashkernel=Y,low */
>>>>> ret = parse_crashkernel_low(cmdline, 0, _low_size,
>>>>> _base);
>>>>> if (ret == -ENOENT)
>>>>> - /*
>>>>> - * crashkernel=Y,low is not specified explicitly, use
>>>>> - * default size automatically.
>>>>> - */
>>>>> + /* case #2 of crashkernel,low reservation */
>>>>> crash_low_size = DEFAULT_CRASH_KERNEL_LOW_SIZE;
>>>>> else if (ret)
>>>>> - /* crashkernel=Y,low is specified but Y is invalid */
>>>>> + /
Re: [PATCH v21 3/5] arm64: kdump: reimplement crashkernel=X
On 2022/3/17 10:38, Baoquan He wrote: > On 02/27/22 at 11:07am, Zhen Lei wrote: >> From: Chen Zhou >> >> There are following issues in arm64 kdump: >> 1. We use crashkernel=X to reserve crashkernel below 4G, which >> will fail when there is no enough low memory. >> 2. If reserving crashkernel above 4G, in this case, crash dump >> kernel will boot failure because there is no low memory available > ~~ change it to "get boot failure" or "fail to boot" OK. I'm going to use "fail to boot". >> for allocation. >> >> To solve these issues, change the behavior of crashkernel=X and >> introduce crashkernel=X,[high,low]. crashkernel=X tries low allocation >> in DMA zone, and fall back to high allocation if it fails. >> We can also use "crashkernel=X,high" to select a region above DMA zone, >> which also tries to allocate at least 256M in DMA zone automatically. >> "crashkernel=Y,low" can be used to allocate specified size low memory. >> >> Signed-off-by: Chen Zhou >> Co-developed-by: Zhen Lei >> Signed-off-by: Zhen Lei > > . > -- Regards, Zhen Lei ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v21 3/5] arm64: kdump: reimplement crashkernel=X
On 2022/3/17 10:36, Baoquan He wrote:
> On 03/16/22 at 09:11pm, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2022/3/16 20:11, Baoquan He wrote:
>>> On 02/27/22 at 11:07am, Zhen Lei wrote:
> ..
>
>>> Hi leizhen,
>>>
>>> I made change on reserve_crashkenrel(), inline comment may be slow.
>>> Please check and consider if they can be taken.
>>
>> That's great. Thank you very much.
>>
>>>
>>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>>> index 30ae6638ff54..f96351da1e3e 100644
>>> --- a/arch/arm64/mm/init.c
>>> +++ b/arch/arm64/mm/init.c
>>> @@ -109,38 +109,43 @@ static int __init reserve_crashkernel_low(unsigned
>>> long long low_size)
>>> * This function reserves memory area given in "crashkernel=" kernel
>>> command
>>> * line parameter. The memory reserved is used by dump capture kernel when
>>> * primary kernel is crashing.
>>> + *
>>> + * NOTE: Reservation of crashkernel,low is special since its existence
>>> + * is not independent, need rely on the existence of crashkernel,high.
>>> + * Hence there are different cases for crashkernel,low reservation:
>
> Considering to update the 3rd line as below:
>
> * NOTE: Reservation of crashkernel,low is special since its existence
> * is not independent, need rely on the existence of crashkernel,high.
> * Here, four cases of crashkernel,low reservation are summarized:
OK. How about change "crashkernel,low" to "crashkernel low memory"?
"crashkernel=Y,low", "crashkernel=,low" and "crashkernel,low" are very similar,
may dazzle the reader.
>
>>> + * 1) crashkernel=Y,low is specified explicitly, crashkernel,low takes Y;
>>> + * 2) crashkernel=,low is not given, while crashkernel=,high is specified,
>>> + *take the default crashkernel,low value;
>>> + * 3) crashkernel=X is specified, while fallback to get a memory region
>>> + *in high memory, take the default crashkernel,low value;
>>> + * 4) crashkernel='invalid value',low is specified, failed the whole
>>> + *crashkernel reservation and bail out.
>>> */
>>> static void __init reserve_crashkernel(void)
>>> {
>>> unsigned long long crash_base, crash_size;
>>> unsigned long long crash_low_size;
>>> unsigned long long crash_max = CRASH_ADDR_LOW_MAX;
>>> - int ret;
>>> bool fixed_base, high = false;
>>> char *cmdline = boot_command_line;
>>> + int ret;
>>>
>>> /* crashkernel=X[@offset] */
>>> ret = parse_crashkernel(cmdline, memblock_phys_mem_size(),
>>> _size, _base);
>>> if (ret || !crash_size) {
>>> - /* crashkernel=X,high */
>>> ret = parse_crashkernel_high(cmdline, 0, _size,
>>> _base);
>>> if (ret || !crash_size)
>>> return;
>>>
>>> - /* crashkernel=Y,low */
>>> ret = parse_crashkernel_low(cmdline, 0, _low_size,
>>> _base);
>>> if (ret == -ENOENT)
>>> - /*
>>> -* crashkernel=Y,low is not specified explicitly, use
>>> -* default size automatically.
>>> -*/
>>> + /* case #2 of crashkernel,low reservation */
>>> crash_low_size = DEFAULT_CRASH_KERNEL_LOW_SIZE;
>>> else if (ret)
>>> - /* crashkernel=Y,low is specified but Y is invalid */
>>> + /* case #4 of crashkernel,low reservation */
>>> return;
>>>
>>> - /* Mark crashkernel=X,high is specified */
>>> high = true;
>>> crash_max = CRASH_ADDR_HIGH_MAX;
>>> }
>>> @@ -148,7 +153,6 @@ static void __init reserve_crashkernel(void)
>>> fixed_base = !!crash_base;
>>> crash_size = PAGE_ALIGN(crash_size);
>>>
>>> - /* User specifies base address explicitly. */
>>> if (fixed_base)
>>> crash_max = crash_base + crash_size;
>>>
>>> @@ -172,11 +176,7 @@ static void __init reserve_crashkernel(void)
>>> }
>>>
>>> if (crash_base >= SZ_4G) {
>>> - /*
>>> -* For case crashkernel=X, low memory is not enough and fall
Re: [PATCH v21 3/5] arm64: kdump: reimplement crashkernel=X
On 2022/3/16 20:11, Baoquan He wrote:
> On 02/27/22 at 11:07am, Zhen Lei wrote:
>> From: Chen Zhou
>>
>> There are following issues in arm64 kdump:
>> 1. We use crashkernel=X to reserve crashkernel below 4G, which
>> will fail when there is no enough low memory.
>> 2. If reserving crashkernel above 4G, in this case, crash dump
>> kernel will boot failure because there is no low memory available
>> for allocation.
>>
>> To solve these issues, change the behavior of crashkernel=X and
>> introduce crashkernel=X,[high,low]. crashkernel=X tries low allocation
>> in DMA zone, and fall back to high allocation if it fails.
>> We can also use "crashkernel=X,high" to select a region above DMA zone,
>> which also tries to allocate at least 256M in DMA zone automatically.
>> "crashkernel=Y,low" can be used to allocate specified size low memory.
>>
>> Signed-off-by: Chen Zhou
>> Co-developed-by: Zhen Lei
>> Signed-off-by: Zhen Lei
>> ---
>> arch/arm64/kernel/machine_kexec.c | 9 ++-
>> arch/arm64/kernel/machine_kexec_file.c | 12 ++-
>> arch/arm64/mm/init.c | 106 +++--
>> 3 files changed, 115 insertions(+), 12 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/machine_kexec.c
>> b/arch/arm64/kernel/machine_kexec.c
>> index e16b248699d5c3c..19c2d487cb08feb 100644
>> --- a/arch/arm64/kernel/machine_kexec.c
>> +++ b/arch/arm64/kernel/machine_kexec.c
>> @@ -329,8 +329,13 @@ bool crash_is_nosave(unsigned long pfn)
>>
>> /* in reserved memory? */
>> addr = __pfn_to_phys(pfn);
>> -if ((addr < crashk_res.start) || (crashk_res.end < addr))
>> -return false;
>> +if ((addr < crashk_res.start) || (crashk_res.end < addr)) {
>> +if (!crashk_low_res.end)
>> +return false;
>> +
>> +if ((addr < crashk_low_res.start) || (crashk_low_res.end <
>> addr))
>> +return false;
>> +}
>>
>> if (!kexec_crash_image)
>> return true;
>> diff --git a/arch/arm64/kernel/machine_kexec_file.c
>> b/arch/arm64/kernel/machine_kexec_file.c
>> index 59c648d51848886..889951291cc0f9c 100644
>> --- a/arch/arm64/kernel/machine_kexec_file.c
>> +++ b/arch/arm64/kernel/machine_kexec_file.c
>> @@ -65,10 +65,18 @@ static int prepare_elf_headers(void **addr, unsigned
>> long *sz)
>>
>> /* Exclude crashkernel region */
>> ret = crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
>> +if (ret)
>> +goto out;
>> +
>> +if (crashk_low_res.end) {
>> +ret = crash_exclude_mem_range(cmem, crashk_low_res.start,
>> crashk_low_res.end);
>> +if (ret)
>> +goto out;
>> +}
>>
>> -if (!ret)
>> -ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
>> +ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
>>
>> +out:
>> kfree(cmem);
>> return ret;
>> }
>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>> index 90f276d46b93bc6..30ae6638ff54c47 100644
>> --- a/arch/arm64/mm/init.c
>> +++ b/arch/arm64/mm/init.c
>> @@ -65,6 +65,44 @@ EXPORT_SYMBOL(memstart_addr);
>> phys_addr_t arm64_dma_phys_limit __ro_after_init;
>>
>> #ifdef CONFIG_KEXEC_CORE
>> +/* Current arm64 boot protocol requires 2MB alignment */
>> +#define CRASH_ALIGN SZ_2M
>> +
>> +#define CRASH_ADDR_LOW_MAX arm64_dma_phys_limit
>> +#define CRASH_ADDR_HIGH_MAX memblock.current_limit
>> +
>> +/*
>> + * This is an empirical value in x86_64 and taken here directly. Please
>> + * refer to the code comment in reserve_crashkernel_low() of x86_64 for more
>> + * details.
>> + */
>> +#define DEFAULT_CRASH_KERNEL_LOW_SIZE \
>> +max(swiotlb_size_or_default() + (8UL << 20), 256UL << 20)
>> +
>> +static int __init reserve_crashkernel_low(unsigned long long low_size)
>> +{
>> +unsigned long long low_base;
>> +
>> +/* passed with crashkernel=0,low ? */
>> +if (!low_size)
>> +return 0;
>> +
>> +low_base = memblock_phys_alloc_range(low_size, CRASH_ALIGN, 0,
>> CRASH_ADDR_LOW_MAX);
>> +if (!low_base) {
>> +pr_err("cannot allocate crashkernel low memory
>> (size:0x%llx).\n", low_size);
>> +return -ENOMEM;
>> +}
>> +
>> +pr_info("crashkernel low memory reserved: 0x%08llx - 0x%08llx (%lld
>> MB)\n",
>> +low_base, low_base + low_size, low_size >> 20);
>> +
>> +crashk_low_res.start = low_base;
>> +crashk_low_res.end = low_base + low_size - 1;
>> +insert_resource(_resource, _low_res);
>> +
>> +return 0;
>> +}
>> +
>> /*
>> * reserve_crashkernel() - reserves memory for crash kernel
>> *
>> @@ -75,30 +113,79 @@ phys_addr_t arm64_dma_phys_limit __ro_after_init;
>> static void __init reserve_crashkernel(void)
>> {
>> unsigned long long crash_base, crash_size;
>> -unsigned long long crash_max = arm64_dma_phys_limit;
>> +unsigned long long crash_low_size;
>> +unsigned long
Re: [PATCH v21 1/5] kdump: return -ENOENT if required cmdline option does not exist
On 2022/3/16 13:39, Baoquan He wrote: > On 02/27/22 at 11:07am, Zhen Lei wrote: >> The crashkernel=Y,low is an optional command-line option. When it doesn't >> exist, kernel will try to allocate minimum required memory below 4G >> automatically. Give it a unique error code to distinguish it from other >> error scenarios. > > This log is a little confusing. __parse_crashkernel() has three callers. > - parse_crashkernel() > - parse_crashkernel_high() > - parse_crashkernel_low() > > How about tuning the git log as below: Sure. Your description is much clearer than mine. > > == > According to the current crashkernel=Y,low support in other ARCHes, it's > an optional command-line option. When it doesn't exist, kernel will try > to allocate minimum required memory below 4G automatically. > > However, __parse_crashkernel() returns '-EINVAL' for all error cases. It > can't distinguish the nonexistent option from invalid option. > > Change __parse_crashkernel() to return '-ENOENT' for the nonexistent option > case. With this change, crashkernel,low memory will take the default > value if crashkernel=,low is not specified; while crashkernel reservation > will fail and bail out if an invalid option is specified. > == > >> >> Signed-off-by: Zhen Lei >> --- >> kernel/crash_core.c | 3 +-- >> 1 file changed, 1 insertion(+), 2 deletions(-) >> >> >> Signed-off-by: Zhen Lei >> --- >> kernel/crash_core.c | 3 +-- >> 1 file changed, 1 insertion(+), 2 deletions(-) >> >> diff --git a/kernel/crash_core.c b/kernel/crash_core.c >> index 256cf6db573cd09..4d57c03714f4e13 100644 >> --- a/kernel/crash_core.c >> +++ b/kernel/crash_core.c >> @@ -243,9 +243,8 @@ static int __init __parse_crashkernel(char *cmdline, >> *crash_base = 0; >> >> ck_cmdline = get_last_crashkernel(cmdline, name, suffix); >> - >> if (!ck_cmdline) >> -return -EINVAL; >> +return -ENOENT; >> >> ck_cmdline += strlen(name); >> >> -- >> 2.25.1 >> > > . > -- Regards, Zhen Lei ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v21 1/5] kdump: return -ENOENT if required cmdline option does not exist
On 2022/3/15 20:21, Baoquan He wrote:
> On 03/15/22 at 07:57pm, Baoquan He wrote:
>> On 02/27/22 at 11:07am, Zhen Lei wrote:
>>> The crashkernel=Y,low is an optional command-line option. When it doesn't
>>> exist, kernel will try to allocate minimum required memory below 4G
>>> automatically. Give it a unique error code to distinguish it from other
>>> error scenarios.
>>>
>>> Signed-off-by: Zhen Lei
>>> ---
>>> kernel/crash_core.c | 3 +--
>>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
>>> index 256cf6db573cd09..4d57c03714f4e13 100644
>>> --- a/kernel/crash_core.c
>>> +++ b/kernel/crash_core.c
>>> @@ -243,9 +243,8 @@ static int __init __parse_crashkernel(char *cmdline,
>>> *crash_base = 0;
>>>
>>> ck_cmdline = get_last_crashkernel(cmdline, name, suffix);
>>> -
>>> if (!ck_cmdline)
>>> - return -EINVAL;
>>> + return -ENOENT;
>>
>> Firstly, I am not sure if '-ENOENT' is a right value to return. From the
>> code comment of ENOENT, it's used for file or dir?
>> #define ENOENT 2 /* No such file or directory */
This error code does not return to user mode, so there is no problem.
There are a lot of places in the kernel that are used this way. For example:
int stop_one_cpu(unsigned int cpu, cpu_stop_fn_t fn, void *arg)
{
if (!cpu_stop_queue_work(cpu, ))
return -ENOENT;
>>
>> Secondly, we ever discussed the case including
>> - no crashkernel=,low is provided;
>> - messy code is provied, e.g crashkernel=aa,low
>
> Checking the 3rd pach, this is handled. Take back my below words,
> continue reviewing.
Yes.
>
>>
>> The 2nd one is not handled in this patchset. How about taking the
>> handling into another round of patches. This patchset just adds
>> crashkernel=,high purely.
>>
>>>
>>> ck_cmdline += strlen(name);
>>>
>>> --
>>> 2.25.1
>>>
>>
>
> .
>
--
Regards,
Zhen Lei
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v20 5/5] kdump: update Documentation about crashkernel
On 2022/2/21 11:48, Baoquan He wrote: > On 01/24/22 at 04:47pm, Zhen Lei wrote: >> From: Chen Zhou >> >> For arm64, the behavior of crashkernel=X has been changed, which >> tries low allocation in DMA zone and fall back to high allocation >> if it fails. >> >> We can also use "crashkernel=X,high" to select a high region above >> DMA zone, which also tries to allocate at least 256M low memory in >> DMA zone automatically and "crashkernel=Y,low" can be used to allocate >> specified size low memory. >> >> So update the Documentation. >> >> Signed-off-by: Chen Zhou >> Signed-off-by: Zhen Lei >> --- >> Documentation/admin-guide/kdump/kdump.rst | 11 +-- >> Documentation/admin-guide/kernel-parameters.txt | 11 +-- >> 2 files changed, 18 insertions(+), 4 deletions(-) >> >> diff --git a/Documentation/admin-guide/kdump/kdump.rst >> b/Documentation/admin-guide/kdump/kdump.rst >> index cb30ca3df27c9b2..d4c287044be0c70 100644 >> --- a/Documentation/admin-guide/kdump/kdump.rst >> +++ b/Documentation/admin-guide/kdump/kdump.rst >> @@ -361,8 +361,15 @@ Boot into System Kernel >> kernel will automatically locate the crash kernel image within the >> first 512MB of RAM if X is not given. >> >> - On arm64, use "crashkernel=Y[@X]". Note that the start address of >> - the kernel, X if explicitly specified, must be aligned to 2MiB >> (0x20). >> + On arm64, use "crashkernel=X" to try low allocation in DMA zone and >> + fall back to high allocation if it fails. >> + We can also use "crashkernel=X,high" to select a high region above >> + DMA zone, which also tries to allocate at least 256M low memory in >> + DMA zone automatically. >> + "crashkernel=Y,low" can be used to allocate specified size low memory. >> + Use "crashkernel=Y@X" if you really have to reserve memory from >> + specified start address X. Note that the start address of the kernel, >> + X if explicitly specified, must be aligned to 2MiB (0x20). > > Hmm, we may not need the details related to crashkernel,high|low in this > section. This just gives examples of basic configation for each ARCH. > The detailed configuration of all crashkernel setting can be found in > "crashkernel syntax" section, I don't think arm64 is so special to need > a specific one. > >> >> Load the Dump-capture Kernel >> >> diff --git a/Documentation/admin-guide/kernel-parameters.txt >> b/Documentation/admin-guide/kernel-parameters.txt >> index f5a27f067db9ed9..65780c2ca830be0 100644 >> --- a/Documentation/admin-guide/kernel-parameters.txt >> +++ b/Documentation/admin-guide/kernel-parameters.txt >> @@ -792,6 +792,9 @@ >> [KNL, X86-64] Select a region under 4G first, and >> fall back to reserve region above 4G when '@offset' >> hasn't been specified. >> +[KNL, ARM64] Try low allocation in DMA zone and fall >> back >> +to high allocation if it fails when '@offset' hasn't >> been >> +specified. >> See Documentation/admin-guide/kdump/kdump.rst for >> further details. > > How about add ARM64 like below to avoid redundant words? > [KNL, X86-64, ARM64] Select a region under 4G first, and > fall back to reserve region above 4G when '@offset' > hasn't been specified. I agree very much, and I think that's the right thing to do. Thanks. I wanted to do the same before, just wasn't sure if the format was correct. I just looked at the other descriptions in kernel-parameters.txt and found that there are many precedents. "movablecore=[KNL,X86,IA-64,PPC]" > >> >> crashkernel=range1:size1[,range2:size2,...][@offset] >> @@ -808,6 +811,8 @@ >> Otherwise memory region will be allocated below 4G, if >> available. >> It will be ignored if crashkernel=X is specified. >> +[KNL, ARM64] range in high memory. >> +Allow kernel to allocate physical memory region from >> top. > > Ditto, please don't add redundent words if it's similar to x86_64 > handling. > >> crashkernel=size[KMG],low >> [KNL, X86-64] range under 4G. When crashkernel=X,high >> is passed, kernel could allocate physical memory region >> @@ -816,13 +821,15 @@ >> requires at least 64M+32K low memory, also enough extra >> low memory is needed to make sure DMA buffers for 32-bit >> devices won't run out. Kernel would try to allocate at >> -at least 256M below 4G automatically. >> +least 256M below 4G automatically. >> This one let user to specify own low range under 4G >> for second kernel instead. >> 0: to disable
Re: [PATCH v20 2/5] arm64: kdump: introduce some macros for crash kernel reservation
On 2022/2/21 11:22, Baoquan He wrote: > On 02/14/22 at 02:22pm, Leizhen (ThunderTown) wrote: >> >> >> On 2022/2/11 18:39, Baoquan He wrote: >>> On 01/24/22 at 04:47pm, Zhen Lei wrote: >>>> From: Chen Zhou >>>> >>>> Introduce macro CRASH_ALIGN for alignment, macro CRASH_ADDR_LOW_MAX >>>> for upper bound of low crash memory, macro CRASH_ADDR_HIGH_MAX for >>>> upper bound of high crash memory, use macros instead. >>>> >>>> Signed-off-by: Chen Zhou >>>> Signed-off-by: Zhen Lei >>>> Tested-by: John Donnelly >>>> Tested-by: Dave Kleikamp >>>> --- >>>> arch/arm64/mm/init.c | 11 --- >>>> 1 file changed, 8 insertions(+), 3 deletions(-) >>>> >>>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c >>>> index 90f276d46b93bc6..6c653a2c7cff052 100644 >>>> --- a/arch/arm64/mm/init.c >>>> +++ b/arch/arm64/mm/init.c >>>> @@ -65,6 +65,12 @@ EXPORT_SYMBOL(memstart_addr); >>>> phys_addr_t arm64_dma_phys_limit __ro_after_init; >>>> >>>> #ifdef CONFIG_KEXEC_CORE >>>> +/* Current arm64 boot protocol requires 2MB alignment */ >>>> +#define CRASH_ALIGN SZ_2M >>>> + >>>> +#define CRASH_ADDR_LOW_MAXarm64_dma_phys_limit >>>> +#define CRASH_ADDR_HIGH_MAX MEMBLOCK_ALLOC_ACCESSIBLE >>> >>> MEMBLOCK_ALLOC_ACCESSIBLE is obvoiously a alloc flag for memblock >>> allocator, I don't think it's appropriate to make HIGH_MAX get its value. >> >> Right, thanks. >> >>> You can make it as memblock.current_limit, or do not define it, but using >>> MEMBLOCK_ALLOC_ACCESSIBLE direclty in memblock_phys_alloc_range() with >>> a code comment. >> >> This patch is not required at present. These macros are added to eliminate >> differences to share code with x86. > > So this patch may not be needed in this series. It can be added in > another post when you start to do the clean up and code unification > among ARCHes, with my udnerstanding. At that time you can consider how > to abstract the common code to handle the difference. Yes, it should be merged with the v20 3/5. > > . > -- Regards, Zhen Lei ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v20 3/5] arm64: kdump: reimplement crashkernel=X
On 2022/2/16 18:20, Baoquan He wrote:
> On 02/16/22 at 10:58am, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2022/2/14 15:53, Leizhen (ThunderTown) wrote:
>>>
>>>
>>> On 2022/2/14 11:52, Baoquan He wrote:
>>>> On 01/24/22 at 04:47pm, Zhen Lei wrote:
>>>> ..
>>>>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>>>>> index 6c653a2c7cff052..a5d43feac0d7d96 100644
>>>>> --- a/arch/arm64/mm/init.c
>>>>> +++ b/arch/arm64/mm/init.c
>>>>> @@ -71,6 +71,30 @@ phys_addr_t arm64_dma_phys_limit __ro_after_init;
>>>>> #define CRASH_ADDR_LOW_MAX arm64_dma_phys_limit
>>>>> #define CRASH_ADDR_HIGH_MAX MEMBLOCK_ALLOC_ACCESSIBLE
>>>>>
>>>>> +static int __init reserve_crashkernel_low(unsigned long long low_size)
>>>>> +{
>>>>> + unsigned long long low_base;
>>>>> +
>>>>> + /* passed with crashkernel=0,low ? */
>>>>> + if (!low_size)
>>>>> + return 0;
>>>>> +
>>>>> + low_base = memblock_phys_alloc_range(low_size, CRASH_ALIGN, 0,
>>>>> CRASH_ADDR_LOW_MAX);
>>>>> + if (!low_base) {
>>>>> + pr_err("cannot allocate crashkernel low memory
>>>>> (size:0x%llx).\n", low_size);
>>>>> + return -ENOMEM;
>>>>> + }
>>>>> +
>>>>> + pr_info("crashkernel low memory reserved: 0x%llx - 0x%llx (%lld MB)\n",
>>>>> + low_base, low_base + low_size, low_size >> 20);
>>>>> +
>>>>> + crashk_low_res.start = low_base;
>>>>> + crashk_low_res.end = low_base + low_size - 1;
>>>>> + insert_resource(_resource, _low_res);
>>>>> +
>>>>> + return 0;
>>>>> +}
>>>>> +
>>>>> /*
>>>>> * reserve_crashkernel() - reserves memory for crash kernel
>>>>
>>>> My another concern is the crashkernel=,low handling. In this patch, the
>>>> code related to low memory is obscure. Wondering if we should make them
>>>> explicit with a little redundant but very clear code flows. Saying this
>>>> because the code must be very clear to you and reviewers, it may be
>>>> harder for later code reader or anyone interested to understand.
>>>>
>>>> 1) crashkernel=X,high
>>>> 2) crashkernel=X,high crashkernel=Y,low
>>>> 3) crashkernel=X,high crashkernel=0,low
>>>> 4) crashkernel=X,high crashkernel='messy code',low
>>>> 5) crashkernel=X //fall back to high memory, low memory is required then.
>>>>
>>>> It could be me thinking about it too much. I made changes to your patch
>>>> with a tuning, not sure if it's OK to you. Otherwise, this patchset
>>>
>>> I think it's good.
>>>
>>>> works very well for all above test cases, it's ripe to be merged for
>>>> wider testing.
>>>
>>> I will test it tomorrow. I've prepared a little more use cases than yours.
>>
>> After the following modifications, I have tested it and it works well. Passed
>> all the test cases I prepared.
>
> That's great.
>
> You might need to add 'crashkernel=xM, crashkernel=0,low',
> 'crashkernel=xM, crashkernel='messy code',low' to your test cases.
Oh, right, I will add them.
>
>>
>>>
>>> 1) crashkernel=4G //high=4G,
>>> low=256M
>>> 2) crashkernel=4G crashkernel=512M,high crashkernel=512M,low
>>> //high=4G, low=256M, high and low are ignored
>>> 3) crashkernel=4G crashkernel=512M,high
>>> //high=4G, low=256M, high is ignored
>>> 4) crashkernel=4G crashkernel=512M,low
>>> //high=4G, low=256M, low is ignored
>>> 5) crashkernel=4G@0xe000
>>> //high=0G, low=0M, cannot allocate, failed
>>> 6) crashkernel=512M //high=0G,
>>> low=512M
>>> 7) crashkernel=128M //high=0G,
>>> low=128M
>>> 8) crashkernel=512M@0xde00 //512M@3552M
>>> //high=0G, low=512M
>>> 9) crashkernel=4G,high
>>> //high=4G, low=256M
>>> a) crashkernel=4G,high crashkernel=512M,low
Re: [PATCH v20 3/5] arm64: kdump: reimplement crashkernel=X
On 2022/2/14 15:53, Leizhen (ThunderTown) wrote:
>
>
> On 2022/2/14 11:52, Baoquan He wrote:
>> On 01/24/22 at 04:47pm, Zhen Lei wrote:
>> ..
>>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>>> index 6c653a2c7cff052..a5d43feac0d7d96 100644
>>> --- a/arch/arm64/mm/init.c
>>> +++ b/arch/arm64/mm/init.c
>>> @@ -71,6 +71,30 @@ phys_addr_t arm64_dma_phys_limit __ro_after_init;
>>> #define CRASH_ADDR_LOW_MAX arm64_dma_phys_limit
>>> #define CRASH_ADDR_HIGH_MAXMEMBLOCK_ALLOC_ACCESSIBLE
>>>
>>> +static int __init reserve_crashkernel_low(unsigned long long low_size)
>>> +{
>>> + unsigned long long low_base;
>>> +
>>> + /* passed with crashkernel=0,low ? */
>>> + if (!low_size)
>>> + return 0;
>>> +
>>> + low_base = memblock_phys_alloc_range(low_size, CRASH_ALIGN, 0,
>>> CRASH_ADDR_LOW_MAX);
>>> + if (!low_base) {
>>> + pr_err("cannot allocate crashkernel low memory
>>> (size:0x%llx).\n", low_size);
>>> + return -ENOMEM;
>>> + }
>>> +
>>> + pr_info("crashkernel low memory reserved: 0x%llx - 0x%llx (%lld MB)\n",
>>> + low_base, low_base + low_size, low_size >> 20);
>>> +
>>> + crashk_low_res.start = low_base;
>>> + crashk_low_res.end = low_base + low_size - 1;
>>> + insert_resource(_resource, _low_res);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> /*
>>> * reserve_crashkernel() - reserves memory for crash kernel
>>
>> My another concern is the crashkernel=,low handling. In this patch, the
>> code related to low memory is obscure. Wondering if we should make them
>> explicit with a little redundant but very clear code flows. Saying this
>> because the code must be very clear to you and reviewers, it may be
>> harder for later code reader or anyone interested to understand.
>>
>> 1) crashkernel=X,high
>> 2) crashkernel=X,high crashkernel=Y,low
>> 3) crashkernel=X,high crashkernel=0,low
>> 4) crashkernel=X,high crashkernel='messy code',low
>> 5) crashkernel=X //fall back to high memory, low memory is required then.
>>
>> It could be me thinking about it too much. I made changes to your patch
>> with a tuning, not sure if it's OK to you. Otherwise, this patchset
>
> I think it's good.
>
>> works very well for all above test cases, it's ripe to be merged for
>> wider testing.
>
> I will test it tomorrow. I've prepared a little more use cases than yours.
After the following modifications, I have tested it and it works well. Passed
all the test cases I prepared.
>
> 1) crashkernel=4G //high=4G,
> low=256M
> 2) crashkernel=4G crashkernel=512M,high crashkernel=512M,low //high=4G,
> low=256M, high and low are ignored
> 3) crashkernel=4G crashkernel=512M,high
> //high=4G, low=256M, high is ignored
> 4) crashkernel=4G crashkernel=512M,low
> //high=4G, low=256M, low is ignored
> 5) crashkernel=4G@0xe000 //high=0G,
> low=0M, cannot allocate, failed
> 6) crashkernel=512M //high=0G,
> low=512M
> 7) crashkernel=128M //high=0G,
> low=128M
> 8) crashkernel=512M@0xde00//512M@3552M
> //high=0G, low=512M
> 9) crashkernel=4G,high
> //high=4G, low=256M
> a) crashkernel=4G,high crashkernel=512M,low //high=4G,
> low=512M
> b) crashkernel=512M,high crashkernel=128M,low //high=512M,
> low=128M
> c) crashkernel=512M,low
> //high=0G, low=0M, invalid
>
>
>>
>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>> index a5d43feac0d7..671862c56d7d 100644
>> --- a/arch/arm64/mm/init.c
>> +++ b/arch/arm64/mm/init.c
>> @@ -94,7 +94,8 @@ static int __init reserve_crashkernel_low(unsigned long
>> long low_size)
>>
>> return 0;
>> }
>> -
>> +/*Words explaining why it's 256M*/
>> +#define DEFAULT_CRASH_KERNEL_LOW_SIZE SZ_256M
It's an empirical value.
94fb9334182284e8e7e4bcb9125c25dc33af19d4 x86/crash: Allocate enough low memory
when crashkernel=high
When the crash kernel is loaded above 4GiB in memory, the
first kernel allocates only 72MiB of low-memory for the DMA
requirements of the second
Re: [PATCH v20 3/5] arm64: kdump: reimplement crashkernel=X
On 2022/2/14 11:52, Baoquan He wrote:
> On 01/24/22 at 04:47pm, Zhen Lei wrote:
> ..
>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>> index 6c653a2c7cff052..a5d43feac0d7d96 100644
>> --- a/arch/arm64/mm/init.c
>> +++ b/arch/arm64/mm/init.c
>> @@ -71,6 +71,30 @@ phys_addr_t arm64_dma_phys_limit __ro_after_init;
>> #define CRASH_ADDR_LOW_MAX arm64_dma_phys_limit
>> #define CRASH_ADDR_HIGH_MAX MEMBLOCK_ALLOC_ACCESSIBLE
>>
>> +static int __init reserve_crashkernel_low(unsigned long long low_size)
>> +{
>> +unsigned long long low_base;
>> +
>> +/* passed with crashkernel=0,low ? */
>> +if (!low_size)
>> +return 0;
>> +
>> +low_base = memblock_phys_alloc_range(low_size, CRASH_ALIGN, 0,
>> CRASH_ADDR_LOW_MAX);
>> +if (!low_base) {
>> +pr_err("cannot allocate crashkernel low memory
>> (size:0x%llx).\n", low_size);
>> +return -ENOMEM;
>> +}
>> +
>> +pr_info("crashkernel low memory reserved: 0x%llx - 0x%llx (%lld MB)\n",
>> +low_base, low_base + low_size, low_size >> 20);
>> +
>> +crashk_low_res.start = low_base;
>> +crashk_low_res.end = low_base + low_size - 1;
>> +insert_resource(_resource, _low_res);
>> +
>> +return 0;
>> +}
>> +
>> /*
>> * reserve_crashkernel() - reserves memory for crash kernel
>
> My another concern is the crashkernel=,low handling. In this patch, the
> code related to low memory is obscure. Wondering if we should make them
> explicit with a little redundant but very clear code flows. Saying this
> because the code must be very clear to you and reviewers, it may be
> harder for later code reader or anyone interested to understand.
>
> 1) crashkernel=X,high
> 2) crashkernel=X,high crashkernel=Y,low
> 3) crashkernel=X,high crashkernel=0,low
> 4) crashkernel=X,high crashkernel='messy code',low
> 5) crashkernel=X //fall back to high memory, low memory is required then.
>
> It could be me thinking about it too much. I made changes to your patch
> with a tuning, not sure if it's OK to you. Otherwise, this patchset
I think it's good.
> works very well for all above test cases, it's ripe to be merged for
> wider testing.
I will test it tomorrow. I've prepared a little more use cases than yours.
1) crashkernel=4G //high=4G,
low=256M
2) crashkernel=4G crashkernel=512M,high crashkernel=512M,low//high=4G,
low=256M, high and low are ignored
3) crashkernel=4G crashkernel=512M,high //high=4G,
low=256M, high is ignored
4) crashkernel=4G crashkernel=512M,low //high=4G,
low=256M, low is ignored
5) crashkernel=4G@0xe000//high=0G,
low=0M, cannot allocate, failed
6) crashkernel=512M //high=0G,
low=512M
7) crashkernel=128M //high=0G,
low=128M
8) crashkernel=512M@0xde00 //512M@3552M//high=0G,
low=512M
9) crashkernel=4G,high //high=4G,
low=256M
a) crashkernel=4G,high crashkernel=512M,low //high=4G,
low=512M
b) crashkernel=512M,high crashkernel=128M,low //high=512M,
low=128M
c) crashkernel=512M,low //high=0G,
low=0M, invalid
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index a5d43feac0d7..671862c56d7d 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -94,7 +94,8 @@ static int __init reserve_crashkernel_low(unsigned long
> long low_size)
>
> return 0;
> }
> -
> +/*Words explaining why it's 256M*/
> +#define DEFAULT_CRASH_KERNEL_LOW_SIZE SZ_256M
> /*
> * reserve_crashkernel() - reserves memory for crash kernel
> *
> @@ -105,10 +106,10 @@ static int __init reserve_crashkernel_low(unsigned long
> long low_size)
> static void __init reserve_crashkernel(void)
> {
> unsigned long long crash_base, crash_size;
> - unsigned long long crash_low_size = SZ_256M;
> + unsigned long long crash_low_size;
> unsigned long long crash_max = CRASH_ADDR_LOW_MAX;
> int ret;
> - bool fixed_base;
> + bool fixed_base, high;
> char *cmdline = boot_command_line;
>
> /* crashkernel=X[@offset] */
> @@ -126,7 +127,10 @@ static void __init reserve_crashkernel(void)
> ret = parse_crashkernel_low(cmdline, 0, _size, _base);
> if (!ret)
> crash_low_size = low_size;
> + else
> + crash_low_size = DEFAULT_CRASH_KERNEL_LOW_SIZE;
>
> + high = true;
> crash_max = CRASH_ADDR_HIGH_MAX;
> }
>
> @@ -134,7 +138,7 @@ static void __init reserve_crashkernel(void)
> crash_size = PAGE_ALIGN(crash_size);
>
> /* User specifies base address explicitly. */
> - if (crash_base)
> + if (fixed_base)
> crash_max =
Re: [PATCH v20 3/5] arm64: kdump: reimplement crashkernel=X
On 2022/2/11 18:51, Baoquan He wrote:
> On 02/11/22 at 06:41pm, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2022/2/11 18:30, Baoquan He wrote:
>>> On 01/24/22 at 04:47pm, Zhen Lei wrote:
>>>> From: Chen Zhou
>>> ..
>>>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>>>> index 6c653a2c7cff052..a5d43feac0d7d96 100644
>>>> --- a/arch/arm64/mm/init.c
>>>> +++ b/arch/arm64/mm/init.c
>>>> @@ -71,6 +71,30 @@ phys_addr_t arm64_dma_phys_limit __ro_after_init;
>>>> #define CRASH_ADDR_LOW_MAXarm64_dma_phys_limit
>>>> #define CRASH_ADDR_HIGH_MAX MEMBLOCK_ALLOC_ACCESSIBLE
>>>>
>>>> +static int __init reserve_crashkernel_low(unsigned long long low_size)
>>>> +{
>>>> + unsigned long long low_base;
>>>> +
>>>> + /* passed with crashkernel=0,low ? */
>>>> + if (!low_size)
>>>> + return 0;
>>>> +
>>>> + low_base = memblock_phys_alloc_range(low_size, CRASH_ALIGN, 0,
>>>> CRASH_ADDR_LOW_MAX);
>>>> + if (!low_base) {
>>>> + pr_err("cannot allocate crashkernel low memory
>>>> (size:0x%llx).\n", low_size);
>>>> + return -ENOMEM;
>>>> + }
>>>> +
>>>> + pr_info("crashkernel low memory reserved: 0x%llx - 0x%llx (%lld MB)\n",
>>>> + low_base, low_base + low_size, low_size >> 20);
>>>> +
>>>> + crashk_low_res.start = low_base;
>>>> + crashk_low_res.end = low_base + low_size - 1;
>>>> + insert_resource(_resource, _low_res);
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>> /*
>>>> * reserve_crashkernel() - reserves memory for crash kernel
>>>> *
>>>> @@ -81,29 +105,62 @@ phys_addr_t arm64_dma_phys_limit __ro_after_init;
>>>> static void __init reserve_crashkernel(void)
>>>> {
>>>>unsigned long long crash_base, crash_size;
>>>> + unsigned long long crash_low_size = SZ_256M;
>>>>unsigned long long crash_max = CRASH_ADDR_LOW_MAX;
>>>>int ret;
>>>> + bool fixed_base;
>>>> + char *cmdline = boot_command_line;
>>>>
>>>> - ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
>>>> + /* crashkernel=X[@offset] */
>>>> + ret = parse_crashkernel(cmdline, memblock_phys_mem_size(),
>>>>_size, _base);
>>>> - /* no crashkernel= or invalid value specified */
>>>> - if (ret || !crash_size)
>>>> - return;
>>>> + if (ret || !crash_size) {
>>>> + unsigned long long low_size;
>>>>
>>>> + /* crashkernel=X,high */
>>>> + ret = parse_crashkernel_high(cmdline, 0, _size,
>>>> _base);
>>>> + if (ret || !crash_size)
>>>> + return;
>>>> +
>>>> + /* crashkernel=X,low */
>>>> + ret = parse_crashkernel_low(cmdline, 0, _size, _base);
>>>> + if (!ret)
>>>> + crash_low_size = low_size;
>>>
>>> Here, the error case is not checked and handled. But it still gets
>>> expeced result which is the default SZ_256M. Is this designed on
>>> purpose?
>>
>> Yes, we can specify only "crashkernel=X,high".
>>
>> This is mentioned in Documentation/admin-guide/kernel-parameters.txt
>>
>> crashkernel=size[KMG],low
>> [KNL, X86-64] range under 4G. When crashkernel=X,high
>> is passed, kernel could allocate physical memory
>> region
>> above 4G, that cause second kernel crash on system
>> that require some amount of low memory, e.g. swiotlb
>> requires at least 64M+32K low memory, also enough
>> extra
>> low memory is needed to make sure DMA buffers for
>> 32-bit
>> devices won't run out. Kernel would try to allocate
>> at <-
>> least 256M below 4G automatically.
>> <-
>
> Yeah, that is expected becasue no crahskernel=,low is a right usage. The
> 'ret' is 0 in the case. If I gave below string, it works too.
> "crashkernel=256M,high crashke
Re: [PATCH v20 2/5] arm64: kdump: introduce some macros for crash kernel reservation
On 2022/2/11 18:39, Baoquan He wrote:
> On 01/24/22 at 04:47pm, Zhen Lei wrote:
>> From: Chen Zhou
>>
>> Introduce macro CRASH_ALIGN for alignment, macro CRASH_ADDR_LOW_MAX
>> for upper bound of low crash memory, macro CRASH_ADDR_HIGH_MAX for
>> upper bound of high crash memory, use macros instead.
>>
>> Signed-off-by: Chen Zhou
>> Signed-off-by: Zhen Lei
>> Tested-by: John Donnelly
>> Tested-by: Dave Kleikamp
>> ---
>> arch/arm64/mm/init.c | 11 ---
>> 1 file changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>> index 90f276d46b93bc6..6c653a2c7cff052 100644
>> --- a/arch/arm64/mm/init.c
>> +++ b/arch/arm64/mm/init.c
>> @@ -65,6 +65,12 @@ EXPORT_SYMBOL(memstart_addr);
>> phys_addr_t arm64_dma_phys_limit __ro_after_init;
>>
>> #ifdef CONFIG_KEXEC_CORE
>> +/* Current arm64 boot protocol requires 2MB alignment */
>> +#define CRASH_ALIGN SZ_2M
>> +
>> +#define CRASH_ADDR_LOW_MAX arm64_dma_phys_limit
>> +#define CRASH_ADDR_HIGH_MAX MEMBLOCK_ALLOC_ACCESSIBLE
>
> MEMBLOCK_ALLOC_ACCESSIBLE is obvoiously a alloc flag for memblock
> allocator, I don't think it's appropriate to make HIGH_MAX get its value.
Right, thanks.
> You can make it as memblock.current_limit, or do not define it, but using
> MEMBLOCK_ALLOC_ACCESSIBLE direclty in memblock_phys_alloc_range() with
> a code comment.
This patch is not required at present. These macros are added to eliminate
differences to share code with x86.
>
>
>> +
>> /*
>> * reserve_crashkernel() - reserves memory for crash kernel
>> *
>> @@ -75,7 +81,7 @@ phys_addr_t arm64_dma_phys_limit __ro_after_init;
>> static void __init reserve_crashkernel(void)
>> {
>> unsigned long long crash_base, crash_size;
>> -unsigned long long crash_max = arm64_dma_phys_limit;
>> +unsigned long long crash_max = CRASH_ADDR_LOW_MAX;
>> int ret;
>>
>> ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
>> @@ -90,8 +96,7 @@ static void __init reserve_crashkernel(void)
>> if (crash_base)
>> crash_max = crash_base + crash_size;
>>
>> -/* Current arm64 boot protocol requires 2MB alignment */
>> -crash_base = memblock_phys_alloc_range(crash_size, SZ_2M,
>> +crash_base = memblock_phys_alloc_range(crash_size, CRASH_ALIGN,
>> crash_base, crash_max);
>> if (!crash_base) {
>> pr_warn("cannot allocate crashkernel (size:0x%llx)\n",
>> --
>> 2.25.1
>>
>
> .
>
--
Regards,
Zhen Lei
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v20 3/5] arm64: kdump: reimplement crashkernel=X
On 2022/2/11 18:30, Baoquan He wrote:
> On 01/24/22 at 04:47pm, Zhen Lei wrote:
>> From: Chen Zhou
> ..
>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>> index 6c653a2c7cff052..a5d43feac0d7d96 100644
>> --- a/arch/arm64/mm/init.c
>> +++ b/arch/arm64/mm/init.c
>> @@ -71,6 +71,30 @@ phys_addr_t arm64_dma_phys_limit __ro_after_init;
>> #define CRASH_ADDR_LOW_MAX arm64_dma_phys_limit
>> #define CRASH_ADDR_HIGH_MAX MEMBLOCK_ALLOC_ACCESSIBLE
>>
>> +static int __init reserve_crashkernel_low(unsigned long long low_size)
>> +{
>> +unsigned long long low_base;
>> +
>> +/* passed with crashkernel=0,low ? */
>> +if (!low_size)
>> +return 0;
>> +
>> +low_base = memblock_phys_alloc_range(low_size, CRASH_ALIGN, 0,
>> CRASH_ADDR_LOW_MAX);
>> +if (!low_base) {
>> +pr_err("cannot allocate crashkernel low memory
>> (size:0x%llx).\n", low_size);
>> +return -ENOMEM;
>> +}
>> +
>> +pr_info("crashkernel low memory reserved: 0x%llx - 0x%llx (%lld MB)\n",
>> +low_base, low_base + low_size, low_size >> 20);
>> +
>> +crashk_low_res.start = low_base;
>> +crashk_low_res.end = low_base + low_size - 1;
>> +insert_resource(_resource, _low_res);
>> +
>> +return 0;
>> +}
>> +
>> /*
>> * reserve_crashkernel() - reserves memory for crash kernel
>> *
>> @@ -81,29 +105,62 @@ phys_addr_t arm64_dma_phys_limit __ro_after_init;
>> static void __init reserve_crashkernel(void)
>> {
>> unsigned long long crash_base, crash_size;
>> +unsigned long long crash_low_size = SZ_256M;
>> unsigned long long crash_max = CRASH_ADDR_LOW_MAX;
>> int ret;
>> +bool fixed_base;
>> +char *cmdline = boot_command_line;
>>
>> -ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(),
>> +/* crashkernel=X[@offset] */
>> +ret = parse_crashkernel(cmdline, memblock_phys_mem_size(),
>> _size, _base);
>> -/* no crashkernel= or invalid value specified */
>> -if (ret || !crash_size)
>> -return;
>> +if (ret || !crash_size) {
>> +unsigned long long low_size;
>>
>> +/* crashkernel=X,high */
>> +ret = parse_crashkernel_high(cmdline, 0, _size,
>> _base);
>> +if (ret || !crash_size)
>> +return;
>> +
>> +/* crashkernel=X,low */
>> +ret = parse_crashkernel_low(cmdline, 0, _size, _base);
>> +if (!ret)
>> +crash_low_size = low_size;
>
> Here, the error case is not checked and handled. But it still gets
> expeced result which is the default SZ_256M. Is this designed on
> purpose?
Yes, we can specify only "crashkernel=X,high".
This is mentioned in Documentation/admin-guide/kernel-parameters.txt
crashkernel=size[KMG],low
[KNL, X86-64] range under 4G. When crashkernel=X,high
is passed, kernel could allocate physical memory region
above 4G, that cause second kernel crash on system
that require some amount of low memory, e.g. swiotlb
requires at least 64M+32K low memory, also enough extra
low memory is needed to make sure DMA buffers for 32-bit
devices won't run out. Kernel would try to allocate at
<-
least 256M below 4G automatically.
<-
>
>> +
>> +crash_max = CRASH_ADDR_HIGH_MAX;
>> +}
>> +
>> +fixed_base = !!crash_base;
>> crash_size = PAGE_ALIGN(crash_size);
>>
>> /* User specifies base address explicitly. */
>> if (crash_base)
>> crash_max = crash_base + crash_size;
>>
>> +retry:
>> crash_base = memblock_phys_alloc_range(crash_size, CRASH_ALIGN,
>> crash_base, crash_max);
>> if (!crash_base) {
>> +/*
>> + * Attempt to fully allocate low memory failed, fall back
>> + * to high memory, the minimum required low memory will be
>> + * reserved later.
>> + */
>> +if (!fixed_base && (crash_max == CRASH_ADDR_LOW_MAX)) {
>> +crash_max = CRASH_ADDR_HIGH_MAX;
>> +goto retry;
>> +}
>> +
>> pr_warn("cannot allocate crashkernel (size:0x%llx)\n",
>> crash_size);
>> return;
>> }
>>
>> +if (crash_base >= SZ_4G && reserve_crashkernel_low(crash_low_size)) {
>> +memblock_phys_free(crash_base, crash_size);
>> +return;
>> +}
>> +
>> pr_info("crashkernel reserved: 0x%016llx - 0x%016llx (%lld MB)\n",
>> crash_base, crash_base + crash_size, crash_size >> 20);
>>
>> @@ -112,6 +169,9 @@ static void __init reserve_crashkernel(void)
>> * map. Inform kmemleak so that it won't try
Re: [PATCH v19 11/13] arm64: kdump: reimplement crashkernel=X
On 2022/1/12 22:45, Dave Kleikamp wrote:
> On 12/28/21 7:26AM, Zhen Lei wrote:
>> From: Chen Zhou
>>
>> There are following issues in arm64 kdump:
>> 1. We use crashkernel=X to reserve crashkernel below 4G, which
>> will fail when there is no enough low memory.
>> 2. If reserving crashkernel above 4G, in this case, crash dump
>> kernel will boot failure because there is no low memory available
>> for allocation.
>>
>> To solve these issues, change the behavior of crashkernel=X and
>> introduce crashkernel=X,[high,low]. crashkernel=X tries low allocation
>> in DMA zone, and fall back to high allocation if it fails.
>> We can also use "crashkernel=X,high" to select a region above DMA zone,
>> which also tries to allocate at least 256M in DMA zone automatically.
>> "crashkernel=Y,low" can be used to allocate specified size low memory.
>>
>> Another minor change, there may be two regions reserved for crash
>> dump kernel, in order to distinct from the high region and make no
>> effect to the use of existing kexec-tools, rename the low region as
>> "Crash kernel (low)".
>>
>> Signed-off-by: Chen Zhou
>> Co-developed-by: Zhen Lei
>> Signed-off-by: Zhen Lei
>> ---
>> arch/arm64/kernel/machine_kexec.c | 5 +++-
>> arch/arm64/kernel/machine_kexec_file.c | 12 ++--
>> arch/arm64/kernel/setup.c | 13 +++-
>> arch/arm64/mm/init.c | 41 ++
>> 4 files changed, 42 insertions(+), 29 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/machine_kexec.c
>> b/arch/arm64/kernel/machine_kexec.c
>> index 6fb31c117ebe08c..6665bf31f6b6a19 100644
>> --- a/arch/arm64/kernel/machine_kexec.c
>> +++ b/arch/arm64/kernel/machine_kexec.c
>> @@ -327,7 +327,10 @@ bool crash_is_nosave(unsigned long pfn)
>> /* in reserved memory? */
>> addr = __pfn_to_phys(pfn);
>> - if ((addr < crashk_res.start) || (crashk_res.end < addr))
>> + if (((addr < crashk_res.start) || (crashk_res.end < addr)) &&
>> !crashk_low_res.end)
>> + return false;
>> +
>> + if ((addr < crashk_low_res.start) || (crashk_low_res.end < addr))
>> return false;
>> if (!kexec_crash_image)
>> diff --git a/arch/arm64/kernel/machine_kexec_file.c
>> b/arch/arm64/kernel/machine_kexec_file.c
>> index 59c648d51848886..889951291cc0f9c 100644
>> --- a/arch/arm64/kernel/machine_kexec_file.c
>> +++ b/arch/arm64/kernel/machine_kexec_file.c
>> @@ -65,10 +65,18 @@ static int prepare_elf_headers(void **addr, unsigned
>> long *sz)
>> /* Exclude crashkernel region */
>> ret = crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
>> + if (ret)
>> + goto out;
>> +
>> + if (crashk_low_res.end) {
>> + ret = crash_exclude_mem_range(cmem, crashk_low_res.start,
>> crashk_low_res.end);
>> + if (ret)
>> + goto out;
>> + }
>> - if (!ret)
>> - ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
>> + ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
>> +out:
>> kfree(cmem);
>> return ret;
>> }
>> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
>> index be5f85b0a24de69..4bb2e55366be64d 100644
>> --- a/arch/arm64/kernel/setup.c
>> +++ b/arch/arm64/kernel/setup.c
>> @@ -248,7 +248,18 @@ static void __init request_standard_resources(void)
>> kernel_data.end <= res->end)
>> request_resource(res, _data);
>> #ifdef CONFIG_KEXEC_CORE
>> - /* Userspace will find "Crash kernel" region in /proc/iomem. */
>> + /*
>> + * Userspace will find "Crash kernel" or "Crash kernel (low)"
>> + * region in /proc/iomem.
>> + * In order to distinct from the high region and make no effect
>> + * to the use of existing kexec-tools, rename the low region as
>> + * "Crash kernel (low)".
>> + */
>> + if (crashk_low_res.end && crashk_low_res.start >= res->start &&
>> + crashk_low_res.end <= res->end) {
>> + crashk_low_res.name = "Crash kernel (low)";
>> + request_resource(res, _low_res);
>> + }
>> if (crashk_res.end && crashk_res.start >= res->start &&
>> crashk_res.end <= res->end)
>> request_resource(res, _res);
>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>> index be4595dc7459115..91b8038a1529068 100644
>> --- a/arch/arm64/mm/init.c
>> +++ b/arch/arm64/mm/init.c
>> @@ -74,41 +74,32 @@ phys_addr_t arm64_dma_phys_limit __ro_after_init;
>> */
>> static void __init reserve_crashkernel(void)
>> {
>> - unsigned long long crash_base, crash_size;
>> - unsigned long long crash_max = CRASH_ADDR_LOW_MAX;
>> + unsigned long long crash_size, crash_base, total_mem, low_size;
>
> low_size needs to be initialized to -1.
>
> If parse_crashkernel() succeeds, then an uninitialized low_size will be
> passed to reserve_crashkernel_mem().
Right, thanks, I noticed that too. I'm waiting for
Re: [PATCH v18 02/17] x86/setup: Move xen_pv_domain() check and insert_resource() to setup_arch()
On 2022/1/7 16:13, Leizhen (ThunderTown) wrote:
>
>
> On 2021/12/25 9:53, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2021/12/24 14:36, Leizhen (ThunderTown) wrote:
>>>
>>>
>>> On 2021/12/24 1:26, Borislav Petkov wrote:
>>>> On Wed, Dec 22, 2021 at 09:08:05PM +0800, Zhen Lei wrote:
>>>>> From: Chen Zhou
>>>>>
>>>>> We will make the functions reserve_crashkernel() as generic, the
>>>>> xen_pv_domain() check in reserve_crashkernel() is relevant only to
>>>>> x86,
>>>>
>>>> Why is that so? Is Xen-PV x86-only?
>>>>
>>>>> the same as insert_resource() in reserve_crashkernel[_low]().
>>>>
>>>> Why?
>>>>
>>>> Looking at
>>>>
>>>> 0212f9159694 ("x86: Add Crash kernel low reservation")
>>>>
>>>> it *surprisingly* explains why that resources thing is being added:
>>>>
>>>> We need to add another range in /proc/iomem like "Crash kernel low",
>>>> so kexec-tools could find that info and append to kdump kernel
>>>> command line.
>>>>
>>>> Then,
>>>>
>>>> 157752d84f5d ("kexec: use Crash kernel for Crash kernel low")
>>>>
>>>> renamed it because, as it states, kexec-tools was taught to handle
>>>> multiple resources of the same name.
>>>>
>>>> So why does kexec-tools on arm *not* need those iomem resources? How
>>>> does it parse the ranges there? Questions over questions...
>
> Hi Borislav:
> The reason why insert_resource() cannot be used in
> reserve_crashkernel[_low]()
> on arm64 is clear. The parent resource node of crashk[_low]_res is added by
> request_resource() in request_standard_resources(), so that it will be
> conflicted.
> All request_resource() in request_standard_resources() should be changed to
> insert_resource(), to make insert_resource() can be used in
> reserve_crashkernel[_low]().
>
> I found commit e25e6e7593ca ("kdump, x86: Process multiple Crash kernel in
> /proc/iomem")
> in kexec-tools. I'm trying to port it to arm64, or make it generic.
Chen Zhou's done it before. But the "Crash kernel (low)" can really be
eliminated. Chen
Zhou just used it to distinguish whether the crashkernel memory range is
crashkernel load
range or not. We can use get_crash_kernel_load_range() to get and check the
load range.
>
> Thanks.
>
>>
>> It's a good question worth figuring out. I'm going to dig into this.
>> I admire your rigorous style and sharp vision.
>>
>
>
--
Regards,
Zhen Lei
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v18 02/17] x86/setup: Move xen_pv_domain() check and insert_resource() to setup_arch()
On 2021/12/25 9:53, Leizhen (ThunderTown) wrote:
>
>
> On 2021/12/24 14:36, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2021/12/24 1:26, Borislav Petkov wrote:
>>> On Wed, Dec 22, 2021 at 09:08:05PM +0800, Zhen Lei wrote:
>>>> From: Chen Zhou
>>>>
>>>> We will make the functions reserve_crashkernel() as generic, the
>>>> xen_pv_domain() check in reserve_crashkernel() is relevant only to
>>>> x86,
>>>
>>> Why is that so? Is Xen-PV x86-only?
>>>
>>>> the same as insert_resource() in reserve_crashkernel[_low]().
>>>
>>> Why?
>>>
>>> Looking at
>>>
>>> 0212f9159694 ("x86: Add Crash kernel low reservation")
>>>
>>> it *surprisingly* explains why that resources thing is being added:
>>>
>>> We need to add another range in /proc/iomem like "Crash kernel low",
>>> so kexec-tools could find that info and append to kdump kernel
>>> command line.
>>>
>>> Then,
>>>
>>> 157752d84f5d ("kexec: use Crash kernel for Crash kernel low")
>>>
>>> renamed it because, as it states, kexec-tools was taught to handle
>>> multiple resources of the same name.
>>>
>>> So why does kexec-tools on arm *not* need those iomem resources? How
>>> does it parse the ranges there? Questions over questions...
Hi Borislav:
The reason why insert_resource() cannot be used in reserve_crashkernel[_low]()
on arm64 is clear. The parent resource node of crashk[_low]_res is added by
request_resource() in request_standard_resources(), so that it will be
conflicted.
All request_resource() in request_standard_resources() should be changed to
insert_resource(), to make insert_resource() can be used in
reserve_crashkernel[_low]().
I found commit e25e6e7593ca ("kdump, x86: Process multiple Crash kernel in
/proc/iomem")
in kexec-tools. I'm trying to port it to arm64, or make it generic.
Thanks.
>
> It's a good question worth figuring out. I'm going to dig into this.
> I admire your rigorous style and sharp vision.
>
--
Regards,
Zhen Lei
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v19 01/13] kdump: add helper parse_crashkernel_high_low()
On 2021/12/31 17:22, Leizhen (ThunderTown) wrote:
>
>
> On 2021/12/30 19:08, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2021/12/30 18:40, Borislav Petkov wrote:
>>> On Thu, Dec 30, 2021 at 06:14:59PM +0800, Leizhen (ThunderTown) wrote:
>>>>
>>>> Hi, Dave, Baoquan, Borislav:
>>>> What do you think about the introduction of
>>>> parse_crashkernel_high_low()? If everyone
>>>> doesn't object, I'll bring it to the next version. But I'll make some
>>>> adjustments to the
>>>> patches, see below. If there's any objection, I still strongly recommend
>>>> removing the
>>>> parameters "system_ram" and "crash_base" of parse_crashkernel_{high,low}().
>>>>
>>>> How about splitting __parse_crashkernel() into two parts? One for parsing
>>>> "crashkernel=X[@offset]", another one for parsing
>>>> "crashkernel=X,{high,low}" and other
>>>> suffixes in the future. So the parameter requirements are clear at the
>>>> lowest level.
>>>
>>> First of all, please do not top post!
>>>
>>> Now, I already explained to you what I'd like to see:
>>>
>>> https://lore.kernel.org/r/Ycs3kpZD/vpoo...@zn.tnic
>>>
>>> yet you still don't get it.
>>>
>>> So let me make myself clear: in its current form, this is not really an
>>> improvement so for all x86 changes:
>>>
>>> NAKed-by: Borislav Petkov
>
> Hi Borislav:
> I'm sorry to bother you again. Do you mind if I make the following changes?
> I can't stand so many comments appearing twice. Even if the size needs to be
> changed in the future, mode "low_size = CRASH_LOW_SIZE_MIN + " can
> be used for adaptation without affecting other architectures.
I rethink it, the default value of default_nslabs is IO_TLB_DEFAULT_SIZE=64M.
The value of default_nslabs can only be changed by swiotlb_adjust_size() and
bootup command line option "swiotlb=". Currently, swiotlb_adjust_size() is
invoked only on x86, so I can just ignore it on arm64. Then, 64M is much
smaller than 256M, the first kernel works fine with the default 64M on arm64,
and I don't think the second kernel needs to grow to 256M. Therefore, I think
swiotlb_adjust_size() is probably a pseudo requirement for arm64.
So I will directly use 256M on arm64. If anyone gets into trouble, he/she can
add it back. Besides, there is also "crashkernel=Y,low" can be used.
>
>
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index e04f5e6eb33f453..da485ee51a9929e 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -428,16 +428,7 @@ static int __init reserve_crashkernel_low(void)
> /* crashkernel=Y,low */
> ret = parse_crashkernel_low(boot_command_line, low_mem_limit,
> _size, );
> if (ret) {
> - /*
> -* two parts from kernel/dma/swiotlb.c:
> -* -swiotlb size: user-specified with swiotlb= or default.
> -*
> -* -swiotlb overflow buffer: now hardcoded to 32k. We round it
> -* to 8M for other buffers that may need to stay low too. Also
> -* make sure we allocate enough extra low memory so that we
> -* don't run out of DMA buffers for 32-bit devices.
> -*/
> - low_size = max(swiotlb_size_or_default() + (8UL << 20), 256UL
> << 20);
> + low_size = CRASH_LOW_SIZE_MIN;
> } else {
> /* passed with crashkernel=0,low ? */
> if (!low_size)
> diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
> index de62a722431e7db..c85b15814312b7e 100644
> --- a/include/linux/crash_core.h
> +++ b/include/linux/crash_core.h
> @@ -69,6 +69,17 @@ phys_addr_t paddr_vmcoreinfo_note(void);
> #define VMCOREINFO_CONFIG(name) \
> vmcoreinfo_append_str("CONFIG_%s=y\n", #name)
>
> +/*
> + * two parts from kernel/dma/swiotlb.c:
> + * -swiotlb size: user-specified with swiotlb= or default.
> + *
> + * -swiotlb overflow buffer: now hardcoded to 32k. We round it
> + * to 8M for other buffers that may need to stay low too. Also
> + * make sure we allocate enough extra low memory so that we
> + * don't run out of DMA buffers for 32-bit devices.
> + */
> +#define CRASH_LOW_SIZE_MIN max(swiotlb_size_or_default() + (8UL << 20),
> 256UL << 20)
> +
> extern unsigned char *vmcoreinfo_data;
> extern size_t vmcoreinfo_size;
> extern u32 *vmcoreinfo_note;
>
>
>>>
>>
>> OK, thanks for your immediate reply, so I can take less detours.
>>
>
--
Regards,
Zhen Lei
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v19 01/13] kdump: add helper parse_crashkernel_high_low()
On 2021/12/30 19:08, Leizhen (ThunderTown) wrote:
>
>
> On 2021/12/30 18:40, Borislav Petkov wrote:
>> On Thu, Dec 30, 2021 at 06:14:59PM +0800, Leizhen (ThunderTown) wrote:
>>>
>>> Hi, Dave, Baoquan, Borislav:
>>> What do you think about the introduction of parse_crashkernel_high_low()?
>>> If everyone
>>> doesn't object, I'll bring it to the next version. But I'll make some
>>> adjustments to the
>>> patches, see below. If there's any objection, I still strongly recommend
>>> removing the
>>> parameters "system_ram" and "crash_base" of parse_crashkernel_{high,low}().
>>>
>>> How about splitting __parse_crashkernel() into two parts? One for parsing
>>> "crashkernel=X[@offset]", another one for parsing
>>> "crashkernel=X,{high,low}" and other
>>> suffixes in the future. So the parameter requirements are clear at the
>>> lowest level.
>>
>> First of all, please do not top post!
>>
>> Now, I already explained to you what I'd like to see:
>>
>> https://lore.kernel.org/r/Ycs3kpZD/vpoo...@zn.tnic
>>
>> yet you still don't get it.
>>
>> So let me make myself clear: in its current form, this is not really an
>> improvement so for all x86 changes:
>>
>> NAKed-by: Borislav Petkov
Hi Borislav:
I'm sorry to bother you again. Do you mind if I make the following changes?
I can't stand so many comments appearing twice. Even if the size needs to be
changed in the future, mode "low_size = CRASH_LOW_SIZE_MIN + " can
be used for adaptation without affecting other architectures.
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index e04f5e6eb33f453..da485ee51a9929e 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -428,16 +428,7 @@ static int __init reserve_crashkernel_low(void)
/* crashkernel=Y,low */
ret = parse_crashkernel_low(boot_command_line, low_mem_limit,
_size, );
if (ret) {
- /*
-* two parts from kernel/dma/swiotlb.c:
-* -swiotlb size: user-specified with swiotlb= or default.
-*
-* -swiotlb overflow buffer: now hardcoded to 32k. We round it
-* to 8M for other buffers that may need to stay low too. Also
-* make sure we allocate enough extra low memory so that we
-* don't run out of DMA buffers for 32-bit devices.
-*/
- low_size = max(swiotlb_size_or_default() + (8UL << 20), 256UL
<< 20);
+ low_size = CRASH_LOW_SIZE_MIN;
} else {
/* passed with crashkernel=0,low ? */
if (!low_size)
diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
index de62a722431e7db..c85b15814312b7e 100644
--- a/include/linux/crash_core.h
+++ b/include/linux/crash_core.h
@@ -69,6 +69,17 @@ phys_addr_t paddr_vmcoreinfo_note(void);
#define VMCOREINFO_CONFIG(name) \
vmcoreinfo_append_str("CONFIG_%s=y\n", #name)
+/*
+ * two parts from kernel/dma/swiotlb.c:
+ * -swiotlb size: user-specified with swiotlb= or default.
+ *
+ * -swiotlb overflow buffer: now hardcoded to 32k. We round it
+ * to 8M for other buffers that may need to stay low too. Also
+ * make sure we allocate enough extra low memory so that we
+ * don't run out of DMA buffers for 32-bit devices.
+ */
+#define CRASH_LOW_SIZE_MIN max(swiotlb_size_or_default() + (8UL << 20),
256UL << 20)
+
extern unsigned char *vmcoreinfo_data;
extern size_t vmcoreinfo_size;
extern u32 *vmcoreinfo_note;
>>
>
> OK, thanks for your immediate reply, so I can take less detours.
>
--
Regards,
Zhen Lei
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v19 01/13] kdump: add helper parse_crashkernel_high_low()
On 2021/12/30 18:40, Borislav Petkov wrote:
> On Thu, Dec 30, 2021 at 06:14:59PM +0800, Leizhen (ThunderTown) wrote:
>>
>> Hi, Dave, Baoquan, Borislav:
>> What do you think about the introduction of parse_crashkernel_high_low()?
>> If everyone
>> doesn't object, I'll bring it to the next version. But I'll make some
>> adjustments to the
>> patches, see below. If there's any objection, I still strongly recommend
>> removing the
>> parameters "system_ram" and "crash_base" of parse_crashkernel_{high,low}().
>>
>> How about splitting __parse_crashkernel() into two parts? One for parsing
>> "crashkernel=X[@offset]", another one for parsing "crashkernel=X,{high,low}"
>> and other
>> suffixes in the future. So the parameter requirements are clear at the
>> lowest level.
>
> First of all, please do not top post!
>
> Now, I already explained to you what I'd like to see:
>
> https://lore.kernel.org/r/Ycs3kpZD/vpoo...@zn.tnic
>
> yet you still don't get it.
>
> So let me make myself clear: in its current form, this is not really an
> improvement so for all x86 changes:
>
> NAKed-by: Borislav Petkov
>
OK, thanks for your immediate reply, so I can take less detours.
--
Regards,
Zhen Lei
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v19 01/13] kdump: add helper parse_crashkernel_high_low()
Hi, Dave, Baoquan, Borislav:
What do you think about the introduction of parse_crashkernel_high_low()? If
everyone
doesn't object, I'll bring it to the next version. But I'll make some
adjustments to the
patches, see below. If there's any objection, I still strongly recommend
removing the
parameters "system_ram" and "crash_base" of parse_crashkernel_{high,low}().
How about splitting __parse_crashkernel() into two parts? One for parsing
"crashkernel=X[@offset]", another one for parsing "crashkernel=X,{high,low}"
and other
suffixes in the future. So the parameter requirements are clear at the lowest
level.
On 2021/12/28 21:26, Zhen Lei wrote:
> The bootup command line option crashkernel=Y,low is valid only when
> crashkernel=X,high is specified. Putting their parsing into a separate
> function makes the code logic clearer and easier to understand the strong
> dependencies between them.
>
> Signed-off-by: Zhen Lei
> ---
> include/linux/crash_core.h | 3 +++
> kernel/crash_core.c| 35 +++
> 2 files changed, 38 insertions(+)
>
> diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
> index de62a722431e7db..2d3a64761d18998 100644
> --- a/include/linux/crash_core.h
> +++ b/include/linux/crash_core.h
> @@ -83,5 +83,8 @@ int parse_crashkernel_high(char *cmdline, unsigned long
> long system_ram,
> unsigned long long *crash_size, unsigned long long *crash_base);
> int parse_crashkernel_low(char *cmdline, unsigned long long system_ram,
> unsigned long long *crash_size, unsigned long long *crash_base);
> +int __init parse_crashkernel_high_low(char *cmdline,
> + unsigned long long *high_size,
> + unsigned long long *low_size);
>
> #endif /* LINUX_CRASH_CORE_H */
> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
> index eb53f5ec62c900f..8966beaf7c4fd52 100644
> --- a/kernel/crash_core.c
> +++ b/kernel/crash_core.c
> @@ -295,6 +295,41 @@ int __init parse_crashkernel_low(char *cmdline,
> "crashkernel=", suffix_tbl[SUFFIX_LOW]);
> }
>
> +/**
> + * parse_crashkernel_high_low - Parsing "crashkernel=X,high" and possible
> + * "crashkernel=Y,low".
> + * @cmdline: The bootup command line.
> + * @high_size: Save the memory size specified by "crashkernel=X,high".
> + * @low_size:Save the memory size specified by "crashkernel=Y,low"
> or "-1"
> + * if it's not specified.
> + *
> + * Returns 0 on success, else a negative status code.
> + */
> +int __init parse_crashkernel_high_low(char *cmdline,
> + unsigned long long *high_size,
> + unsigned long long *low_size)
> +{
> + int ret;
> + unsigned long long base;
> +
> + BUG_ON(!high_size || !low_size);
> +
> + /* crashkernel=X,high */
> + ret = parse_crashkernel_high(cmdline, 0, high_size, );
> + if (ret)
> + return ret;
> +
> + if (*high_size <= 0)
> + return -EINVAL;
> +
> + /* crashkernel=Y,low */
> + ret = parse_crashkernel_low(cmdline, 0, low_size, );
> + if (ret)
> + *low_size = -1;
> +
> + return 0;
> +}
> +
> Elf_Word *append_elf_note(Elf_Word *buf, char *name, unsigned int type,
> void *data, size_t data_len)
> {
>
--
Regards,
Zhen Lei
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v19 02/13] x86/setup: Use parse_crashkernel_high_low() to simplify code
On 2021/12/30 10:39, Leizhen (ThunderTown) wrote:
>
>
> On 2021/12/30 0:51, Borislav Petkov wrote:
>> On Wed, Dec 29, 2021 at 11:04:21PM +0800, Leizhen (ThunderTown) wrote:
>>> Chen Zhou and I tried to share the code because of a suggestion. After so
>>> many
>>> attempts, it doesn't seem to fit to make generic. Or maybe I haven't figured
>>> out a good solution yet.
>>
>> Well, you learned a very important lesson and the many attempts are not
>> in vain: code sharing does not make sense in every case.
>>
>>> I will put the patches that make arm64 support crashkernel...high,low to
>>> the front, then the parse_crashkernel() unification patches. Even if the
>>> second half of the patches is not ready for v5.18, the first half of the
>>> patches is ready.
>>
>> I think you should concentrate on the arm64 side which is, AFAICT, what
>> you're trying to achieve.
>
> Right, a patchset should focus on just one thing.
>
>>
>> The "parse_crashkernel() unification" needs more thought because, as I
>> said already, that doesn't make a whole lot of sense to me.
>
> Yes, because it's not a functional improvement, it's not a performance
> optimization,
> it's also not a fix for a known bug, it's just a programmer's artistic
> pursuit.
>
>>
>> If you want to enforce the fact that "low" makes sense only when "high"
>> is supplied, parse_crashkernel_high_low() is not the right thing to do.
>> You need to have a *single* function which does all the parsing where
>> you can decide what to do: "if high, parse low", "if no high supplied,
>> ignore low" and so on.
In fact, this is how my current function parse_crashkernel_high_low() is
implemented.
+ /* crashkernel=X,high */
+ ret = parse_crashkernel_high(cmdline, 0, high_size, );
+ if (ret)//crashkernel=X,high is not specified
+ return ret;
+
+ if (*high_size <= 0)//crashkernel=X,high is specified but
the value is invalid
+ return -EINVAL; //Sorry, the type of high_size is
"unsigned long long *", so less than zero is impossible
+
+ /* crashkernel=Y,low */
+ ret = parse_crashkernel_low(cmdline, 0, low_size, ); //If
crashkernel=Y,low is specified, the parsed value is stored in *low_size
+ if (ret)
+ *low_size = -1; //crashkernel=Y,low is not specified
>
> I understand your proposal, but parse_crashkernel_high_low() is a
> cost-effective
> and profitable change, it makes the current code a little clearer, and avoid
> passing
> unnecessary parameters "system_ram" and "crash_base" when other architectures
> use
> parse_crashkernel_{high|low}().
>
> I actually followed your advice in the beginning to do "parse_crashkernel()
> and
> parse_crashkernel_{high|low}() unification". But I found it's difficult and
> the
> end result may not be as good as expected. So I introduced
> parse_crashkernel_high_low().
>
> The parameter "system_ram" and "crash_base" of parse_crashkernel() is not
> need by
> "crashkernel=X,[high,low]". And parameter "low_size" of
> parse_crashkernel_high_low()
> is not need by "crashkernel=X[@offset]". The "parse_crashkernel() unification"
> complicates things. For example, the parameter "crash_size" means "low or
> high" memory
> size for "crashkernel=X[@offset]", but only means "high" memory size for
> "crashkernel=X,high".
> So we'd better give it two names with union.
>
>>
>> And if those are supported on certain architectures only, you can do
>> ifdeffery...
>
> I don't think so. These __init functions are small and
> architecture-independent, and do not
> affect compilation of other architectures. There may be other architectures
> that use
> it in the future, such as the current arm64.
>
>>
>> But I think I already stated that I don't like such unifications which
>> introduce unnecessary dependencies between architectures. Therefore, I
>> won't accept them into x86 unless there's a strong compelling reason.
>> Which I don't see ATM.
>
> OK.
>
>>
>> Thx.
>>
>
--
Regards,
Zhen Lei
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v19 02/13] x86/setup: Use parse_crashkernel_high_low() to simplify code
On 2021/12/30 0:51, Borislav Petkov wrote:
> On Wed, Dec 29, 2021 at 11:04:21PM +0800, Leizhen (ThunderTown) wrote:
>> Chen Zhou and I tried to share the code because of a suggestion. After so
>> many
>> attempts, it doesn't seem to fit to make generic. Or maybe I haven't figured
>> out a good solution yet.
>
> Well, you learned a very important lesson and the many attempts are not
> in vain: code sharing does not make sense in every case.
>
>> I will put the patches that make arm64 support crashkernel...high,low to
>> the front, then the parse_crashkernel() unification patches. Even if the
>> second half of the patches is not ready for v5.18, the first half of the
>> patches is ready.
>
> I think you should concentrate on the arm64 side which is, AFAICT, what
> you're trying to achieve.
Right, a patchset should focus on just one thing.
>
> The "parse_crashkernel() unification" needs more thought because, as I
> said already, that doesn't make a whole lot of sense to me.
Yes, because it's not a functional improvement, it's not a performance
optimization,
it's also not a fix for a known bug, it's just a programmer's artistic pursuit.
>
> If you want to enforce the fact that "low" makes sense only when "high"
> is supplied, parse_crashkernel_high_low() is not the right thing to do.
> You need to have a *single* function which does all the parsing where
> you can decide what to do: "if high, parse low", "if no high supplied,
> ignore low" and so on.
I understand your proposal, but parse_crashkernel_high_low() is a cost-effective
and profitable change, it makes the current code a little clearer, and avoid
passing
unnecessary parameters "system_ram" and "crash_base" when other architectures
use
parse_crashkernel_{high|low}().
I actually followed your advice in the beginning to do "parse_crashkernel() and
parse_crashkernel_{high|low}() unification". But I found it's difficult and the
end result may not be as good as expected. So I introduced
parse_crashkernel_high_low().
The parameter "system_ram" and "crash_base" of parse_crashkernel() is not need
by
"crashkernel=X,[high,low]". And parameter "low_size" of
parse_crashkernel_high_low()
is not need by "crashkernel=X[@offset]". The "parse_crashkernel() unification"
complicates things. For example, the parameter "crash_size" means "low or high"
memory
size for "crashkernel=X[@offset]", but only means "high" memory size for
"crashkernel=X,high".
So we'd better give it two names with union.
>
> And if those are supported on certain architectures only, you can do
> ifdeffery...
I don't think so. These __init functions are small and
architecture-independent, and do not
affect compilation of other architectures. There may be other architectures
that use
it in the future, such as the current arm64.
>
> But I think I already stated that I don't like such unifications which
> introduce unnecessary dependencies between architectures. Therefore, I
> won't accept them into x86 unless there's a strong compelling reason.
> Which I don't see ATM.
OK.
>
> Thx.
>
--
Regards,
Zhen Lei
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v19 02/13] x86/setup: Use parse_crashkernel_high_low() to simplify code
On 2021/12/29 18:46, Dave Young wrote: > On 12/29/21 at 11:03am, Borislav Petkov wrote: >> On Wed, Dec 29, 2021 at 03:27:48PM +0800, Dave Young wrote: >>> So I think you can unify the parse_crashkernel* in x86 first with just >>> one function. And leave the further improvements to later work. But >>> let's see how Boris think about this. >> >> Well, I think this all unnecessary work. Why? >> >> If the goal is to support crashkernel...high,low on arm64, then you >> should simply *copy* the functionality on arm64 and be done with it. >> >> Unification is done by looking at code which is duplicated across >> architectures and which has been untouched for a while now, i.e., no >> new or arch-specific changes are going to it so a unification can be >> as simple as trivially switching the architectures to call a generic >> function. >> >> What this does is carve out the "generic" parts and then try not to >> break existing usage. >> >> Which is a total waste of energy and resources. And it is casting that >> functionality in stone so that when x86 wants to change something there, >> it should do it in a way not to break arm64. And I fail to see the >> advantage of all that. Code sharing ain't it. It's just a worry, there's uncertainty about whether it's going to be. I think the only thing that might change is the default value of "low_size". Of course, the alignment size and start address may also change, but most of them can be controlled by macros. Chen Zhou and I tried to share the code because of a suggestion. After so many attempts, it doesn't seem to fit to make generic. Or maybe I haven't figured out a good solution yet. >> >> So what it should do is simply copy the necessary code to arm64. >> Unifications can always be done later, when the dust settles. > > I think I agree with you about the better way is to doing some > improvements so that arches can logically doing things better. I can > leave with the way I suggested although it is not the best. But I think > Leizhen needs a clear direction about how to do it. It is very clear > now. See how he will handle this. Surviving, then pursuing ideals. I will put the patches that make arm64 support crashkernel...high,low to the front, then the parse_crashkernel() unification patches. Even if the second half of the patches is not ready for v5.18, the first half of the patches is ready. > >> >> IMNSVHO. >> >> -- >> Regards/Gruss, >> Boris. >> >> https://people.kernel.org/tglx/notes-about-netiquette >> > > . > -- Regards, Zhen Lei ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v19 02/13] x86/setup: Use parse_crashkernel_high_low() to simplify code
On 2021/12/29 18:38, Dave Young wrote: > On 12/29/21 at 11:11am, Borislav Petkov wrote: >> On Wed, Dec 29, 2021 at 03:45:12PM +0800, Dave Young wrote: >>> BTW, I would suggest to wait for reviewers to response (eg. one week at >>> least, or more due to the holidays) before updating another version >>> >>> Do not worry to miss the 5.17. I would say take it easy if it will >>> miss then let's just leave with it and continue to work on the future >>> improvements. I think one reason this issue takes too long time is that it >>> was >>> discussed some time but no followup and later people need to warm up >>> again. Just keep it warm and continue to engage in the improvements, do >>> not hurry for the specific mainline release. >> >> Can you tell this to *all* patch submitters please? > > I appreciate you further explanation below to describe the situation. I do > not > see how can I tell this to *all* submitters, but I am and I will try to do > this > as far as I can. Maintainers and patch submitters, it would help for both > parties show sympathy with each other, some soft reminders will help > people to understand each other, especially for new comers. > >> >> I can't count the times where people simply hurry to send the new >> revision just to get it in the next kernel, and make silly mistakes >> while doing so. Or not think things straight and misdesign it all. >> >> And what this causes is the opposite of what they wanna achieve - pissed >> maintainers and ignored threads. I just hope the first 4 patches can be merged into v5.17. It seems to me that it is quite clear. Although the goal of the final stage is to modify function parse_crashkernel() according to the current opinion. But that's not a lightweight change after all. The final parse_crashkernel() change may take one version or two. In this process, it maybe OK to do a part of cleanup first. It's like someone who wants to buy a luxury car to commute to work six months later. He buys a cheap used car and sells it six months later. It sounds right to me, don't you think? >> >> And they all *know* that the next kernel is around the corner. So why >> the hell does it even matter when? Because all programmers should have confidence in the code they write. I have a new idea, and I'm free these days, so I updated v19. I can't rely on people telling me to take a step forward, then take a step forward. Otherwise, stand still. >> >> What most submitters fail to realize is, the moment your code hits >> upstream, it becomes the maintainers' problem and submitters can relax. Sorry, I'll make sure all the comments are collected and then send the next edition. >> >> But maintainers get to deal with this code forever. So after a while >> maintainers learn that they either accept ready code and it all just >> works or they make the mistake to take half-baked crap in and then they >> themselves get to clean it up and fix it. >> >> So maintainers learn quickly to push back. >> >> But it is annoying and it would help immensely if submitters would >> consider this and stop hurrying the code in but try to do a *good* job >> first, design-wise and code-wise by thinking hard about what they're >> trying to do. >> >> Yeah, things could be a lot simpler and easier - it only takes a little >> bit of effort... >> >> -- >> Regards/Gruss, >> Boris. >> >> https://people.kernel.org/tglx/notes-about-netiquette >> > > Thanks > Dave > > . > -- Regards, Zhen Lei ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v19 02/13] x86/setup: Use parse_crashkernel_high_low() to simplify code
On 2021/12/29 15:27, Dave Young wrote:
> On 12/29/21 at 10:27am, Leizhen (ThunderTown) wrote:
>>
>>
>> On 2021/12/29 0:13, Borislav Petkov wrote:
>>> On Tue, Dec 28, 2021 at 09:26:01PM +0800, Zhen Lei wrote:
>>>> Use parse_crashkernel_high_low() to bring the parsing of
>>>> "crashkernel=X,high" and the parsing of "crashkernel=Y,low" together, they
>>>> are strongly dependent, make code logic clear and more readable.
>>>>
>>>> Suggested-by: Borislav Petkov
>>>
>>> Yeah, doesn't look like something I suggested...
>>>
>>>> @@ -474,10 +472,9 @@ static void __init reserve_crashkernel(void)
>>>>/* crashkernel=XM */
>>>>ret = parse_crashkernel(boot_command_line, total_mem, _size,
>>>> _base);
>>>>if (ret != 0 || crash_size <= 0) {
>>>> - /* crashkernel=X,high */
>>>> - ret = parse_crashkernel_high(boot_command_line, total_mem,
>>>> - _size, _base);
>>>> - if (ret != 0 || crash_size <= 0)
>>>> + /* crashkernel=X,high and possible crashkernel=Y,low */
>>>> + ret = parse_crashkernel_high_low(boot_command_line,
>>>> _size, _size);
>>>
>>> So this calls parse_crashkernel() and when that one fails, it calls this
>>> new weird parse high/low helper you added.
>>>
>>> But then all three end up in the same __parse_crashkernel() worker
>>> function which seems to do the actual parsing.
>>>
>>> What I suggested and what would be real clean is if the arches would
>>> simply call a *single*
>>>
>>> parse_crashkernel()
>>>
>>> function and when that one returns, *all* crashkernel= options would
>>> have been parsed properly, low, high, middle crashkernel, whatever...
>>> and the caller would know what crash kernel needs to be allocated.
>>>
>>> Then each arch can do its memory allocations and checks based on that
>>> parsed data and decide to allocate or bail.
>>
>> However, only x86 currently supports "crashkernel=X,high" and
>> "crashkernel=Y,low", and arm64
>> will also support it. It is not supported on other architectures. So
>> changing parse_crashkernel()
>> is not appropriate unless a new function is introduced. But naming this new
>> function isn't easy,
>> and the name parse_crashkernel_in_order() that I've named before doesn't
>> seem to be good.
>> Of course, we can also consider changing parse_crashkernel() to another
>> name, then use
>> parse_crashkernel() to parse all possible "crashkernel=" options in order,
>> but this will cause
>> other architectures to change as well.
>
> Hi, I did not follow up all discussions, but if the only difference is
> about the low -> high fallback, I think you can add another argument in
> parse_crashkernel(..., *fallback_high), and doing some changes in
> __parse_crashkernel() before it returns. But since there are two
> many arguments, you could need a wrapper struct for crashkernel_param if
> needed.
A wrapper struct is needed. Because at least two new output parameters need to
be added:
1. high, to indicate whether "crashkernel=X,high" is specified
2. low_size, to save the memory size specified by "crashkernel=Y,low"
>
> If you do not want to touch other arches, another function maybe
> something like parse_crashkernel_fallback() for x86 and arm64 to use.
>
> But I may not get all the context, please ignore if this is not the
> case. I agree that calling parse_crash_kernel* in the
> reserve_crashkernel funtions looks not good though.
>
> OTOH there are bunch of other logics in param parsing code,
> eg. determin the final size and offset etc. To split the logic out more
> things need to be done, eg. firstly parsing function just get all the
> inputs from cmdline string eg. an array of struct crashkernel_param with
> mem_range, expected size, expected offset, high, or low, and do not do
> any other things. Then pass these parsed inputs to another function to
> determine the final crash_size and crash_base, that part can be arch
> specific somehow.
Yes, this way makes the code logic clear. But there's a bit of trouble with
"crashkernel=range1:size1[,range2:size2,...][@offset]", the array size is
dynamic.
>
> So I think you can unify the parse_crashkernel* in x86 first with just
> one function. And leave the further improvements to later work. But
> let's see how Boris think about this.
>
>>
>>>
>>> So it is getting there but it needs more surgery...
>>>
>>> Thx.
>>>
>>
>> --
>> Regards,
>> Zhen Lei
>>
>
> Thanks
> Dave
>
> .
>
--
Regards,
Zhen Lei
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v19 02/13] x86/setup: Use parse_crashkernel_high_low() to simplify code
On 2021/12/29 0:13, Borislav Petkov wrote:
> On Tue, Dec 28, 2021 at 09:26:01PM +0800, Zhen Lei wrote:
>> Use parse_crashkernel_high_low() to bring the parsing of
>> "crashkernel=X,high" and the parsing of "crashkernel=Y,low" together, they
>> are strongly dependent, make code logic clear and more readable.
>>
>> Suggested-by: Borislav Petkov
>
> Yeah, doesn't look like something I suggested...
>
>> @@ -474,10 +472,9 @@ static void __init reserve_crashkernel(void)
>> /* crashkernel=XM */
>> ret = parse_crashkernel(boot_command_line, total_mem, _size,
>> _base);
>> if (ret != 0 || crash_size <= 0) {
>> -/* crashkernel=X,high */
>> -ret = parse_crashkernel_high(boot_command_line, total_mem,
>> - _size, _base);
>> -if (ret != 0 || crash_size <= 0)
>> +/* crashkernel=X,high and possible crashkernel=Y,low */
>> +ret = parse_crashkernel_high_low(boot_command_line,
>> _size, _size);
>
> So this calls parse_crashkernel() and when that one fails, it calls this
> new weird parse high/low helper you added.
>
> But then all three end up in the same __parse_crashkernel() worker
> function which seems to do the actual parsing.
>
> What I suggested and what would be real clean is if the arches would
> simply call a *single*
>
> parse_crashkernel()
>
> function and when that one returns, *all* crashkernel= options would
> have been parsed properly, low, high, middle crashkernel, whatever...
> and the caller would know what crash kernel needs to be allocated.
>
> Then each arch can do its memory allocations and checks based on that
> parsed data and decide to allocate or bail.
However, only x86 currently supports "crashkernel=X,high" and
"crashkernel=Y,low", and arm64
will also support it. It is not supported on other architectures. So changing
parse_crashkernel()
is not appropriate unless a new function is introduced. But naming this new
function isn't easy,
and the name parse_crashkernel_in_order() that I've named before doesn't seem
to be good.
Of course, we can also consider changing parse_crashkernel() to another name,
then use
parse_crashkernel() to parse all possible "crashkernel=" options in order, but
this will cause
other architectures to change as well.
>
> So it is getting there but it needs more surgery...
>
> Thx.
>
--
Regards,
Zhen Lei
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v18 02/17] x86/setup: Move xen_pv_domain() check and insert_resource() to setup_arch()
On 2021/12/25 9:53, Leizhen (ThunderTown) wrote:
>>> This is exactly why I say that making those functions generic and shared
>>> might not be such a good idea, after all, because then you'd have to
>>> sprinkle around arch-specific stuff.
Hi Borislav and all:
Merry Christmas!
I have a new idea now. It helps us get around all the arguments and
minimizes changes to the x86 (also to arm64).
Previously, Chen Zhou and I tried to share the entire function
reserve_crashkernel(), which led to the following series of problems:
1. reserve_crashkernel() is also defined on other architectures, so we should
add build option ARCH_WANT_RESERVE_CRASH_KERNEL to avoid conflicts.
2. Move xen_pv_domain() check out of reserve_crashkernel().
3. Move insert_resource() out of reserve_crashkernel()
Others:
4. start = memblock_phys_alloc_range(crash_size, SZ_1M, crash_base,
crash_base + crash_size);
Change SZ_1M to CRASH_ALIGN, or keep it no change.
The current conclusion is no change. But I think adding a new macro
CRASH_FIXED_ALIGN is also a way. 2M alignment allows page tables to
use block mappings for most architectures.
5. if (crash_base >= (1ULL << 32) && reserve_crashkernel_low())
Change (1ULL << 32) to CRASH_ADDR_LOW_MAX, or keep it no change.
I reanalyzed it, and this doesn't need to be changed.
So for 1-3，why not add a new function reserve_crashkernel_mem() and rename
reserve_crashkernel_low() to reserve_crashkernel_mem_low().
On x86:
static void __init reserve_crashkernel(void)
{
//Parse all "crashkernel=" configurations in priority order until
//a valid combination is found. Or return upon failure.
if (xen_pv_domain()) {
pr_info("Ignoring crashkernel for a Xen PV domain\n");
return;
}
//Call reserve_crashkernel_mem() to reserve crashkernel memory, it will
//call reserve_crashkernel_mem_low() if needed.
if (crashk_low_res.end)
insert_resource(_resource, _low_res);
insert_resource(_resource, _res);
}
On arm64:
static void __init reserve_crashkernel(void)
{
//Parse all "crashkernel=" configurations in priority order until
//a valid combination is found. Or return upon failure.
//Call reserve_crashkernel_mem() to reserve crashkernel memory, it will
//call reserve_crashkernel_mem_low() if needed.
}
1. reserve_crashkernel() is still static, so that there is no
need to add ARCH_WANT_RESERVE_CRASH_KERNEL.
2. The xen_pv_domain() check have not been affected in any way.
Hi Borislav:
As you mentioned, this check may also be needed on arm64. But it may be
better not to add it until the problem is actually triggered on arm64.
3. insert_resource() is not moved outside reserve_crashkernel() on x86.
Hi Borislav:
Currently, I haven't figured out why request_resource() can't be replaced
with insert_resource() on arm64. But I have a hunch that the kexec tool may
be involved. The cost of modification on arm64 is definitely higher than that
on x86. Other architectures that want to use reserve_crashkernel_mem() may
also face the same problem. So it's probably better that function
reserve_crashkernel_mem() doesn't invoke insert_resource().
I guess you have a long Christmas holiday. So I'm going to send the next version
without waiting for your response.
>> Yes, I'm thinking about that too. Perhaps they are not suitable for full
>> code sharing, but it looks like there's some code that can be shared.
>> For example, the function parse_crashkernel_in_order() that I extracted
>> based on your suggestion, it could also be parse_crashkernel_high_low().
>> Or the function reserve_crashkernel_low().
>>
>> There are two ways to reserve memory above 4G:
>> 1. Use crashkernel=X,high, with or without crashkernel=X,low
>> 2. Use crashkernel=X,[offset], but try low memory first. If failed, then
>>try high memory, and retry at least 256M low memory.
>>
>> I plan to only implement 2 in the next version so that there can be fewer
>> changes. Then implement 1 after 2 is applied.
> I tried it yesterday and it didn't work. I still have to deal with the
> problem of adjusting insert_resource().
>
> How about I isolate some cleanup patches first? Strive for them to be
> merged into v5.17. This way, we can focus on the core changes in the
> next version. And I can also save some repetitive rebase workload.
>
--
Regards,
Zhen Lei
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v18 04/17] x86/setup: Add helper parse_crashkernel_in_order()
On 2021/12/22 21:08, Zhen Lei wrote:
> Currently, there are two possible combinations of configurations.
> (1) crashkernel=X[@offset]
> (2) crashkernel=X,high, with or without crashkernel=X,low
>
> (1) has the highest priority, if it is configured correctly, (2) will be
> ignored. Similarly, in combination (2), crashkernel=X,low is valid only
> when crashkernel=X,high is valid.
>
> Putting the operations of parsing all "crashkernel=" configurations in one
> function helps to sort out the strong dependency.
>
> So add helper parse_crashkernel_in_order(). The "__maybe_unused" will be
> removed in the next patch.
>
> Signed-off-by: Zhen Lei
> ---
> arch/x86/kernel/setup.c | 51 +
> 1 file changed, 51 insertions(+)
>
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index d9080bfa131a654..f997074d36f2484 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -439,6 +439,57 @@ static int __init reserve_crashkernel_low(void)
> }
> #endif
>
> +#define CRASHKERNEL_MEM_NONE 0x0 /* crashkernel= is not exist or
> invalid */
> +#define CRASHKERNEL_MEM_CLASSIC 0x1 /*
> crashkernel=X[@offset] is valid */
> +#define CRASHKERNEL_MEM_HIGH 0x2 /* crashkernel=X,high is valid
> */
> +#define CRASHKERNEL_MEM_LOW 0x4 /* crashkernel=X,low is valid */
> +
> +/**
> + * parse_crashkernel_in_order - Parse all "crashkernel=" configurations in
> + * priority order until a valid combination is
> found.
> + * @cmdline: The bootup command line.
> + * @system_ram: Total system memory size.
> + * @crash_size: Save the memory size specified by "crashkernel=X[@offset]" or
> + * "crashkernel=X,high".
> + * @crash_base: Save the base address specified by "crashkernel=X@offset"
> + * @low_size:Save the memory size specified by "crashkernel=X,low"
> + *
> + * Returns the status flag of the parsing result of "crashkernel=", such as
> + * CRASHKERNEL_MEM_NONE, CRASHKERNEL_MEM_HIGH.
> + */
> +__maybe_unused
> +static int __init parse_crashkernel_in_order(char *cmdline,
> + unsigned long long system_ram,
> + unsigned long long *crash_size,
> + unsigned long long *crash_base,
> + unsigned long long *low_size)
I rethought yesterday that this function name is not self-annotated. In
addition,
the meaning of the return value is not mainstream. It would be better to change
it
to parse_crashkernel_high_low().
> +{
> + int ret, flag = CRASHKERNEL_MEM_NONE;
> +
> + BUG_ON(!crash_size || !crash_base || !low_size);
> +
> + /* crashkernel=X[@offset] */
> + ret = parse_crashkernel(cmdline, system_ram, crash_size, crash_base);
> + if (!ret && crash_size > 0)
> + return CRASHKERNEL_MEM_CLASSIC;
> +
> +#ifdef CONFIG_X86_64
> + /* crashkernel=X,high */
> + ret = parse_crashkernel_high(cmdline, system_ram, crash_size,
> crash_base);
> + if (ret || crash_size <= 0)
> + return CRASHKERNEL_MEM_NONE;
> +
> + flag = CRASHKERNEL_MEM_HIGH;
> +
> + /* crashkernel=Y,low */
> + ret = parse_crashkernel_low(cmdline, system_ram, low_size, crash_base);
> + if (!ret)
> + flag |= CRASHKERNEL_MEM_LOW;
> +#endif
> +
> + return flag;
> +}
> +
> static void __init reserve_crashkernel(void)
> {
> unsigned long long crash_size, crash_base, total_mem;
>
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v18 02/17] x86/setup: Move xen_pv_domain() check and insert_resource() to setup_arch()
On 2021/12/24 14:36, Leizhen (ThunderTown) wrote:
>
>
> On 2021/12/24 1:26, Borislav Petkov wrote:
>> On Wed, Dec 22, 2021 at 09:08:05PM +0800, Zhen Lei wrote:
>>> From: Chen Zhou
>>>
>>> We will make the functions reserve_crashkernel() as generic, the
>>> xen_pv_domain() check in reserve_crashkernel() is relevant only to
>>> x86,
>>
>> Why is that so? Is Xen-PV x86-only?
>>
>>> the same as insert_resource() in reserve_crashkernel[_low]().
>>
>> Why?
>>
>> Looking at
>>
>> 0212f9159694 ("x86: Add Crash kernel low reservation")
>>
>> it *surprisingly* explains why that resources thing is being added:
>>
>> We need to add another range in /proc/iomem like "Crash kernel low",
>> so kexec-tools could find that info and append to kdump kernel
>> command line.
>>
>> Then,
>>
>> 157752d84f5d ("kexec: use Crash kernel for Crash kernel low")
>>
>> renamed it because, as it states, kexec-tools was taught to handle
>> multiple resources of the same name.
>>
>> So why does kexec-tools on arm *not* need those iomem resources? How
>> does it parse the ranges there? Questions over questions...
It's a good question worth figuring out. I'm going to dig into this.
I admire your rigorous style and sharp vision.
>
> https://lkml.org/lkml/2019/4/4/1758
>
> Chen Zhou has explained before, see below. I'll analyze why x86 and arm64 need
> to process iomem resources at different times.
>
> < This very reminds what x86 does. Any chance some of the code can be reused
> < rather than duplicated?
> As i said in the comment, i transport reserve_crashkernel_low() from x86_64.
> There are minor
> differences. In arm64, we don't need to do insert_resource(), we do
> request_resource()
> in request_standard_resources() later.
>
>>
>> So last time I told you to sit down and take your time with this cleanup.
>> >From reading this here, it doesn't look like it. Rather, it looks like
>> hastily done in a hurry and hurrying stuff doesn't help you one bit - it
>> actually makes it worse.
>>
>> Your commit messages need to explain *why* a change is being done and
>> why is that ok. This one doesn't.
>
> OK, I'll do this in follow-up patches.
>
>>
>>> @@ -1120,7 +1109,17 @@ void __init setup_arch(char **cmdline_p)
>>> * Reserve memory for crash kernel after SRAT is parsed so that it
>>> * won't consume hotpluggable memory.
>>> */
>>> - reserve_crashkernel();
>>> +#ifdef CONFIG_KEXEC_CORE
>>> + if (xen_pv_domain())
>>> + pr_info("Ignoring crashkernel for a Xen PV domain\n");
Right, these two lines of code do not need to be moved. xen_pv_domain() is
a friendly macro function.
>>
>> This is wrong - the check is currently being done inside
>> reserve_crashkernel(), *after* it has parsed a crashkernel= cmdline
>> correctly - and not before.
>>
>> Your change would print on Xen PV, regardless of whether it has received
>> crashkernel= on the cmdline or not.
>
> Yes, you're right. There are changes in code logic, but the print doesn't
> seem to cause any misunderstanding.
>
>>
>> This is exactly why I say that making those functions generic and shared
>> might not be such a good idea, after all, because then you'd have to
>> sprinkle around arch-specific stuff.
>
> Yes, I'm thinking about that too. Perhaps they are not suitable for full
> code sharing, but it looks like there's some code that can be shared.
> For example, the function parse_crashkernel_in_order() that I extracted
> based on your suggestion, it could also be parse_crashkernel_high_low().
> Or the function reserve_crashkernel_low().
>
> There are two ways to reserve memory above 4G:
> 1. Use crashkernel=X,high, with or without crashkernel=X,low
> 2. Use crashkernel=X,[offset], but try low memory first. If failed, then
>try high memory, and retry at least 256M low memory.
>
> I plan to only implement 2 in the next version so that there can be fewer
> changes. Then implement 1 after 2 is applied.
I tried it yesterday and it didn't work. I still have to deal with the
problem of adjusting insert_resource().
How about I isolate some cleanup patches first? Strive for them to be
merged into v5.17. This way, we can focus on the core changes in the
next version. And I can also save some repetitive rebase workload.
>
>>
>> One of the ways how to address this particular case here would be:
>>
>> 1. Add a x86-specific wrapper around parse_crashkernel() which does
>> all the parsing. When that wrapper finishes, you should have parsed
>> everything that has crashkernel= on the cmdline.
>>
>> 2. At the end of that wrapper, you do arch-specific checks and setup
>> like the xen_pv_domain() one.
>>
>> 3. Now, you do reserve_crashkernel(), if those checks pass.
>>
>> The question is, whether the flow on arm64 can do the same. Probably but
>> it needs careful auditing.
>>
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v18 02/17] x86/setup: Move xen_pv_domain() check and insert_resource() to setup_arch()
On 2021/12/24 1:26, Borislav Petkov wrote:
> On Wed, Dec 22, 2021 at 09:08:05PM +0800, Zhen Lei wrote:
>> From: Chen Zhou
>>
>> We will make the functions reserve_crashkernel() as generic, the
>> xen_pv_domain() check in reserve_crashkernel() is relevant only to
>> x86,
>
> Why is that so? Is Xen-PV x86-only?
>
>> the same as insert_resource() in reserve_crashkernel[_low]().
>
> Why?
>
> Looking at
>
> 0212f9159694 ("x86: Add Crash kernel low reservation")
>
> it *surprisingly* explains why that resources thing is being added:
>
> We need to add another range in /proc/iomem like "Crash kernel low",
> so kexec-tools could find that info and append to kdump kernel
> command line.
>
> Then,
>
> 157752d84f5d ("kexec: use Crash kernel for Crash kernel low")
>
> renamed it because, as it states, kexec-tools was taught to handle
> multiple resources of the same name.
>
> So why does kexec-tools on arm *not* need those iomem resources? How
> does it parse the ranges there? Questions over questions...
https://lkml.org/lkml/2019/4/4/1758
Chen Zhou has explained before, see below. I'll analyze why x86 and arm64 need
to process iomem resources at different times.
< This very reminds what x86 does. Any chance some of the code can be reused
< rather than duplicated?
As i said in the comment, i transport reserve_crashkernel_low() from x86_64.
There are minor
differences. In arm64, we don't need to do insert_resource(), we do
request_resource()
in request_standard_resources() later.
>
> So last time I told you to sit down and take your time with this cleanup.
>>From reading this here, it doesn't look like it. Rather, it looks like
> hastily done in a hurry and hurrying stuff doesn't help you one bit - it
> actually makes it worse.
>
> Your commit messages need to explain *why* a change is being done and
> why is that ok. This one doesn't.
OK, I'll do this in follow-up patches.
>
>> @@ -1120,7 +1109,17 @@ void __init setup_arch(char **cmdline_p)
>> * Reserve memory for crash kernel after SRAT is parsed so that it
>> * won't consume hotpluggable memory.
>> */
>> -reserve_crashkernel();
>> +#ifdef CONFIG_KEXEC_CORE
>> +if (xen_pv_domain())
>> +pr_info("Ignoring crashkernel for a Xen PV domain\n");
>
> This is wrong - the check is currently being done inside
> reserve_crashkernel(), *after* it has parsed a crashkernel= cmdline
> correctly - and not before.
>
> Your change would print on Xen PV, regardless of whether it has received
> crashkernel= on the cmdline or not.
Yes, you're right. There are changes in code logic, but the print doesn't
seem to cause any misunderstanding.
>
> This is exactly why I say that making those functions generic and shared
> might not be such a good idea, after all, because then you'd have to
> sprinkle around arch-specific stuff.
Yes, I'm thinking about that too. Perhaps they are not suitable for full
code sharing, but it looks like there's some code that can be shared.
For example, the function parse_crashkernel_in_order() that I extracted
based on your suggestion, it could also be parse_crashkernel_high_low().
Or the function reserve_crashkernel_low().
There are two ways to reserve memory above 4G:
1. Use crashkernel=X,high, with or without crashkernel=X,low
2. Use crashkernel=X,[offset], but try low memory first. If failed, then
try high memory, and retry at least 256M low memory.
I plan to only implement 2 in the next version so that there can be fewer
changes. Then implement 1 after 2 is applied.
>
> One of the ways how to address this particular case here would be:
>
> 1. Add a x86-specific wrapper around parse_crashkernel() which does
> all the parsing. When that wrapper finishes, you should have parsed
> everything that has crashkernel= on the cmdline.
>
> 2. At the end of that wrapper, you do arch-specific checks and setup
> like the xen_pv_domain() one.
>
> 3. Now, you do reserve_crashkernel(), if those checks pass.
>
> The question is, whether the flow on arm64 can do the same. Probably but
> it needs careful auditing.
>
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v18 15/17] of: fdt: Aggregate the processing of "linux,usable-memory-range"
On 2021/12/23 23:48, Dave Kleikamp wrote:
> On 12/22/21 7:08AM, Zhen Lei wrote:
>> Currently, we parse the "linux,usable-memory-range" property in
>> early_init_dt_scan_chosen(), to obtain the specified memory range of the
>> crash kernel. We then reserve the required memory after
>> early_init_dt_scan_memory() has identified all available physical memory.
>> Because the two pieces of code are separated far, the readability and
>> maintainability are reduced. So bring them together.
>
> Rob Herring is pushing a modified version of this patch (changes made by
> Pingfan Liu) to fix a regression. This will cause a conflict when it hits
> mainline.
Yes, I saw it yesterday, and I'll delete it in the next version. Thanks.
>
> https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git/log/?h=dt/linus
>
> https://lore.kernel.org/linux-arm-kernel/20211214040157.27443-1-kernelf...@gmail.com/
>
>>
>> Suggested-by: Rob Herring
>> Signed-off-by: Zhen Lei
>> Reviewed-by: Rob Herring
>> Tested-by: Dave Kleikamp
>> ---
>> drivers/of/fdt.c | 15 +++
>> 1 file changed, 11 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
>> index bdca35284cebd56..37b477a51175359 100644
>> --- a/drivers/of/fdt.c
>> +++ b/drivers/of/fdt.c
>> @@ -965,8 +965,7 @@ static void __init
>> early_init_dt_check_for_elfcorehdr(unsigned long node)
>> elfcorehdr_addr, elfcorehdr_size);
>> }
>> -static phys_addr_t cap_mem_addr;
>> -static phys_addr_t cap_mem_size;
>> +static unsigned long chosen_node_offset = -FDT_ERR_NOTFOUND;
>> /**
>> * early_init_dt_check_for_usable_mem_range - Decode usable memory range
>> @@ -977,6 +976,11 @@ static void __init
>> early_init_dt_check_for_usable_mem_range(unsigned long node)
>> {
>> const __be32 *prop;
>> int len;
>> + phys_addr_t cap_mem_addr;
>> + phys_addr_t cap_mem_size;
>> +
>> + if ((long)node < 0)
>> + return;
>> pr_debug("Looking for usable-memory-range property... ");
>> @@ -989,6 +993,8 @@ static void __init
>> early_init_dt_check_for_usable_mem_range(unsigned long node)
>> pr_debug("cap_mem_start=%pa cap_mem_size=%pa\n", _mem_addr,
>> _mem_size);
>> +
>> + memblock_cap_memory_range(cap_mem_addr, cap_mem_size);
>> }
>> #ifdef CONFIG_SERIAL_EARLYCON
>> @@ -1137,9 +1143,10 @@ int __init early_init_dt_scan_chosen(unsigned long
>> node, const char *uname,
>> (strcmp(uname, "chosen") != 0 && strcmp(uname, "chosen@0") != 0))
>> return 0;
>> + chosen_node_offset = node;
>> +
>> early_init_dt_check_for_initrd(node);
>> early_init_dt_check_for_elfcorehdr(node);
>> - early_init_dt_check_for_usable_mem_range(node);
>> /* Retrieve command line */
>> p = of_get_flat_dt_prop(node, "bootargs", );
>> @@ -1275,7 +1282,7 @@ void __init early_init_dt_scan_nodes(void)
>> of_scan_flat_dt(early_init_dt_scan_memory, NULL);
>> /* Handle linux,usable-memory-range property */
>> - memblock_cap_memory_range(cap_mem_addr, cap_mem_size);
>> + early_init_dt_check_for_usable_mem_range(chosen_node_offset);
>> }
>> bool __init early_init_dt_scan(void *params)
>
> .
>
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v18 01/17] x86/setup: Move CRASH_ALIGN and CRASH_ADDR_{LOW|HIGH}_MAX to asm/kexec.h
On 2021/12/23 4:43, Borislav Petkov wrote:
> On Wed, Dec 22, 2021 at 09:08:04PM +0800, Zhen Lei wrote:
>> From: Chen Zhou
>>
>> We want to make function reserve_crashkernel[_low](), which is implemented
> ^^
>
> Please use passive voice in your commit message: no "we" or "I", etc,
> and describe your changes in imperative mood.
My bad language habits. I've made this mistake several times.
>
> Also, pls read section "2) Describe your changes" in
> Documentation/process/submitting-patches.rst for more details.
>
> Bottom line is: personal pronouns are ambiguous in text, especially with
> so many parties/companies/etc developing the kernel so let's avoid them
> please.
OK, I'll check the description of the other patches.
>
>> by X86, available to other architectures. It references macro CRASH_ALIGN
>
> "x86"
OK
>
>> and will be moved to public crash_core.c. But the defined values of
>> CRASH_ALIGN may be different in different architectures. So moving the
>> definition of CRASH_ALIGN to asm/kexec.h is a good choice.
>>
>> The reason for moving CRASH_ADDR_{LOW|HIGH}_MAX is the same as above.
>
> This commit message needs to say something along the lines of:
>
> "Move CRASH_ALIGN and ... to the arch-specific header in preparation
> of making reserve_crashkernel[_low]() generic, used by other
> architectures."
OK, I will use this one, thanks.
By the way, patch 0004-0006 were written based on your suggestion. Can you
take a moment to review it? I think I forgot to add "Suggested-by".
>
> or so.
>
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v17 03/10] x86: kdump: use macro CRASH_ADDR_LOW_MAX in functions reserve_crashkernel()
On 2021/12/16 22:48, Borislav Petkov wrote:
> On Thu, Dec 16, 2021 at 08:08:30PM +0800, Leizhen (ThunderTown) wrote:
>> If the memory of 'crash_base' is successfully allocated at (1), because the
>> last
>> parameter CRASH_ADDR_LOW_MAX is the upper bound, so we can sure that
>> "crash_base < CRASH_ADDR_LOW_MAX". So that, reserve_crashkernel_low() will
>> not be
>> invoked at (3). That's why I said (1ULL << 32) is inaccurate and enlarge the
>> CRASH_ADDR_LOW
>> upper limit.
>
> No, this is actually wrong - that check *must* be 4G. See:
>
> eb6db83d1059 ("x86/setup: Do not reserve crashkernel high memory if low
> reservation failed")
>
> It is even documented:
>
> crashkernel=size[KMG],low
> [KNL, X86-64] range under 4G. When crashkernel=X,high
[KNL, X86-64], This doc is for X86-64, not for X86-32
> is passed, kernel could allocate physical memory
> region
> above 4G, that cause second kernel crash on system
> that require some amount of low memory, e.g. swiotlb
> requires at least 64M+32K low memory, also enough
> extra
> low memory is needed to make sure DMA buffers for
> 32-bit
> devices won't run out.
vi arch/x86/kernel/setup.c +398
/*
* Keep the crash kernel below this limit.
*
* Earlier 32-bits kernels would limit the kernel to the low 512 MB range
* due to mapping restrictions.
If there is no such restriction, we can make CRASH_ADDR_LOW_MAX equal to (1ULL
<< 32) minus 1 on X86_32.
>
> so you need to do a low allocation for DMA *when* the reserved memory is
> above 4G. *NOT* above 512M. But that works due to the obscure situation,
> as Baoquan stated, that reserve_crashkernel_low() returns 0 on 32-bit.
>
> So all this is telling us is that that function needs serious cleanup.
>
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v17 05/10] x86: kdump: move reserve_crashkernel[_low]() into crash_core.c
On 2021/12/16 19:17, Borislav Petkov wrote: > On Fri, Dec 10, 2021 at 02:55:28PM +0800, Zhen Lei wrote: >> + * reserve_crashkernel() - reserves memory for crash kernel >> + * >> + * This function reserves memory area given in "crashkernel=" kernel command >> + * line parameter. The memory reserved is used by dump capture kernel when >> + * primary kernel is crashing. >> + */ >> +void __init reserve_crashkernel(void) > > As I've already alluded to in another mail, ontop of this there should > be a patch or multiple patches which clean this up more and perhaps even > split it into separate functions doing stuff in this order: > > 1. Parse all crashkernel= cmdline options > > 2. Do all crash_base, crash_size etc checks > > 3. Do the memory reservations > > And all that supplied with comments explaining why stuff is being done. I agree with you. This makes the code look clear. I will do it, try to post v18 next Monday. > > This set of functions is a mess and there's no better time for cleaning > it up and documenting it properly than when you move it to generic code. > > Thx. > ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v17 03/10] x86: kdump: use macro CRASH_ADDR_LOW_MAX in functions reserve_crashkernel()
On 2021/12/16 20:08, Leizhen (ThunderTown) wrote:
>
>
> On 2021/12/16 19:07, Borislav Petkov wrote:
>> On Thu, Dec 16, 2021 at 10:46:12AM +0800, Leizhen (ThunderTown) wrote:
>>> The original value (1ULL << 32) is inaccurate
>>
>> I keep asking *why*?
>>
>>> and it enlarged the CRASH_ADDR_LOW upper limit.
>>
>> $ git grep -E "CRASH_ADDR_LOW\W"
>> $
>>
>> I have no clue what you mean here.
>
> #ifdef CONFIG_X86_32
> # define CRASH_ADDR_LOW_MAX SZ_512M
> # define CRASH_ADDR_HIGH_MAXSZ_512M
> #endif
>
> if (!high)
> (1) crash_base = memblock_phys_alloc_range(crash_size,
> CRASH_ALIGN, CRASH_ALIGN,
> CRASH_ADDR_LOW_MAX);
> if (!crash_base)
> (2) crash_base = memblock_phys_alloc_range(crash_size,
> CRASH_ALIGN, CRASH_ALIGN,
> CRASH_ADDR_HIGH_MAX);
>
> - if (crash_base >= (1ULL << 32) && reserve_crashkernel_low())
> +(3) if (crash_base >= CRASH_ADDR_LOW_MAX && reserve_crashkernel_low())
>
> If the memory of 'crash_base' is successfully allocated at (1), because the
> last
> parameter CRASH_ADDR_LOW_MAX is the upper bound, so we can sure that
> "crash_base < CRASH_ADDR_LOW_MAX". So that, reserve_crashkernel_low() will
> not be
> invoked at (3). That's why I said (1ULL << 32) is inaccurate and enlarge the
> CRASH_ADDR_LOW
> upper limit.
>
> If the memory of 'crash_base' is successfully allocated at (2), you see,
> CRASH_ADDR_HIGH_MAX = CRASH_ADDR_LOW_MAX = SZ_512M, the same as (1). In fact,
> "crashkernel=high," may not be recommended on X86_32.
>
> Is it possible that (CRASH_ADDR_HIGH_MAX >= 4G) and (CRASH_ADDR_LOW_MAX < 4G)?
> In this case, the memory allocated at (2) maybe over 4G. But why shouldn't
> CRASH_ADDR_LOW_MAX be equal to 4G at this point?
We divide two memory areas: low memory area and high memory area. The doc told
us:
at least 256MB memory should be reserved at low memory area. So that if
"crash_base >= CRASH_ADDR_LOW_MAX" is true at (3), that means we have not
reserved
any memory at low memory area, so we should call reserve_crashkernel_low().
The low memory area is not equivalent to <=4G, I think. So replace (1ULL << 32)
with
CRASH_ADDR_LOW_MAX is logically correct.
>
>
>>
>>> This is because when the memory is allocated from the low end, the
>>> address cannot exceed CRASH_ADDR_LOW_MAX, see "if (!high)" branch.
>>
>>> If
>>> the memory is allocated from the high end, 'crash_base' is greater than or
>>> equal to (1ULL << 32), and naturally, it is greater than CRASH_ADDR_LOW_MAX.
>>>
>>> I think I should update the description, thanks.
>>
>> I think you should explain why is (1ULL << 32) wrong.
>>
>> It came from:
>>
>> eb6db83d1059 ("x86/setup: Do not reserve crashkernel high memory if low
>> reservation failed")
>>
>> which simply frees the high memory portion when the low reservation
>> fails. And the test for that is, is crash base > 4G. So that makes
>> perfect sense to me.
>>
>> So your change is a NOP on 64-bit and it is a NOP on 32-bit by virtue of
>> the _low() variant always returning 0 on 32-bit.
>>
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v17 03/10] x86: kdump: use macro CRASH_ADDR_LOW_MAX in functions reserve_crashkernel()
On 2021/12/16 19:07, Borislav Petkov wrote:
> On Thu, Dec 16, 2021 at 10:46:12AM +0800, Leizhen (ThunderTown) wrote:
>> The original value (1ULL << 32) is inaccurate
>
> I keep asking *why*?
>
>> and it enlarged the CRASH_ADDR_LOW upper limit.
>
> $ git grep -E "CRASH_ADDR_LOW\W"
> $
>
> I have no clue what you mean here.
#ifdef CONFIG_X86_32
# define CRASH_ADDR_LOW_MAX SZ_512M
# define CRASH_ADDR_HIGH_MAXSZ_512M
#endif
if (!high)
(1) crash_base = memblock_phys_alloc_range(crash_size,
CRASH_ALIGN, CRASH_ALIGN,
CRASH_ADDR_LOW_MAX);
if (!crash_base)
(2) crash_base = memblock_phys_alloc_range(crash_size,
CRASH_ALIGN, CRASH_ALIGN,
CRASH_ADDR_HIGH_MAX);
- if (crash_base >= (1ULL << 32) && reserve_crashkernel_low())
+(3)if (crash_base >= CRASH_ADDR_LOW_MAX && reserve_crashkernel_low())
If the memory of 'crash_base' is successfully allocated at (1), because the last
parameter CRASH_ADDR_LOW_MAX is the upper bound, so we can sure that
"crash_base < CRASH_ADDR_LOW_MAX". So that, reserve_crashkernel_low() will not
be
invoked at (3). That's why I said (1ULL << 32) is inaccurate and enlarge the
CRASH_ADDR_LOW
upper limit.
If the memory of 'crash_base' is successfully allocated at (2), you see,
CRASH_ADDR_HIGH_MAX = CRASH_ADDR_LOW_MAX = SZ_512M, the same as (1). In fact,
"crashkernel=high," may not be recommended on X86_32.
Is it possible that (CRASH_ADDR_HIGH_MAX >= 4G) and (CRASH_ADDR_LOW_MAX < 4G)?
In this case, the memory allocated at (2) maybe over 4G. But why shouldn't
CRASH_ADDR_LOW_MAX be equal to 4G at this point?
>
>> This is because when the memory is allocated from the low end, the
>> address cannot exceed CRASH_ADDR_LOW_MAX, see "if (!high)" branch.
>
>> If
>> the memory is allocated from the high end, 'crash_base' is greater than or
>> equal to (1ULL << 32), and naturally, it is greater than CRASH_ADDR_LOW_MAX.
>>
>> I think I should update the description, thanks.
>
> I think you should explain why is (1ULL << 32) wrong.
>
> It came from:
>
> eb6db83d1059 ("x86/setup: Do not reserve crashkernel high memory if low
> reservation failed")
>
> which simply frees the high memory portion when the low reservation
> fails. And the test for that is, is crash base > 4G. So that makes
> perfect sense to me.
>
> So your change is a NOP on 64-bit and it is a NOP on 32-bit by virtue of
> the _low() variant always returning 0 on 32-bit.
>
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v17 03/10] x86: kdump: use macro CRASH_ADDR_LOW_MAX in functions reserve_crashkernel()
On 2021/12/16 9:10, Baoquan He wrote:
> On 12/15/21 at 02:28pm, Borislav Petkov wrote:
>> On Fri, Dec 10, 2021 at 02:55:26PM +0800, Zhen Lei wrote:
>>> @@ -518,7 +519,7 @@ static void __init reserve_crashkernel(void)
>>> }
>>> }
>>>
>>> - if (crash_base >= (1ULL << 32) && reserve_crashkernel_low()) {
>>> + if (crash_base >= CRASH_ADDR_LOW_MAX && reserve_crashkernel_low()) {
>>> memblock_phys_free(crash_base, crash_size);
>>> return;
>>> }
>>
>> That's not a equivalent transformation on X86_32.
The original value (1ULL << 32) is inaccurate, and it enlarged the
CRASH_ADDR_LOW
upper limit. This is because when the memory is allocated from the low end,
the address cannot exceed CRASH_ADDR_LOW_MAX, see "if (!high)" branch. If
the memory is allocated from the high end, 'crash_base' is greater than or
equal to (1ULL << 32), and naturally, it is greater than CRASH_ADDR_LOW_MAX.
I think I should update the description, thanks.
if (!high)
crash_base = memblock_phys_alloc_range(crash_size,
CRASH_ALIGN, CRASH_ALIGN,
CRASH_ADDR_LOW_MAX);
if (!crash_base)
crash_base = memblock_phys_alloc_range(crash_size,
CRASH_ALIGN, CRASH_ALIGN,
CRASH_ADDR_HIGH_MAX);
>
> reserve_crashkernel_low() always return 0 on x86_32, so the not equivalent
> transformation for x86_32 doesn't matter, I think.
>
> .
>
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v17 02/10] x86: kdump: make the lower bound of crash kernel reservation consistent
On 2021/12/15 19:16, Baoquan He wrote: > On 12/15/21 at 11:01am, Catalin Marinas wrote: >> On Wed, Dec 15, 2021 at 11:42:19AM +0800, Baoquan He wrote: >>> On 12/14/21 at 07:24pm, Catalin Marinas wrote: On Tue, Dec 14, 2021 at 08:07:58PM +0100, Borislav Petkov wrote: > On Fri, Dec 10, 2021 at 02:55:25PM +0800, Zhen Lei wrote: >> From: Chen Zhou >> >> The lower bounds of crash kernel reservation and crash kernel low >> reservation are different, use the consistent value CRASH_ALIGN. > > A big WHY is missing here to explain why the lower bound of the > allocation range needs to be 16M and why was 0 wrong? I asked the same here: https://lore.kernel.org/r/20210224143547.gb28...@arm.com IIRC Baoquan said that there is a 1MB reserved for x86 anyway in the lower part, so that's equivalent in practice to starting from CRASH_ALIGN. >>> >>> Yeah, even for i386, there's area reserved by BIOS inside low 1M. >>> Considering the existing alignment CRASH_ALIGN which is 16M, we >>> definitely have no chance to get memory starting from 0. So starting >>> from 16M can skip the useless memblock searching, and make the >>> crashkernel low reservation consisten with crashkernel reservation on >>> allocation code. >> >> That's the x86 assumption. Is it valid for other architectures once the >> code has been made generic in patch 6? It should be ok for arm64, RAM >> tends to start from higher up but other architectures may start using >> this common code. > > Good point. I didn't think of this from generic code side, then let's > keep it as 0. > >> >> If you want to keep the same semantics as before, just leave it as 0. >> It's not that the additional lower bound makes the search slower. > > Agree. OK, I will drop this patch. > > . > ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v17 04/10] x86: kdump: move xen_pv_domain() check and insert_resource() to setup_arch()
On 2021/12/14 19:40, Leizhen (ThunderTown) wrote:
>
>
> On 2021/12/10 14:55, Zhen Lei wrote:
>> From: Chen Zhou
>>
>> We will make the functions reserve_crashkernel() as generic, the
>> xen_pv_domain() check in reserve_crashkernel() is relevant only to
>> x86, the same as insert_resource() in reserve_crashkernel[_low]().
>> So move xen_pv_domain() check and insert_resource() to setup_arch()
>> to keep them in x86.
>>
>> Suggested-by: Mike Rapoport
>> Signed-off-by: Chen Zhou
>> Signed-off-by: Zhen Lei
>> Tested-by: John Donnelly
>> Tested-by: Dave Kleikamp
>> Acked-by: Baoquan He
>> ---
>> arch/x86/kernel/setup.c | 19 +++
>> 1 file changed, 11 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
>> index bb2a0973b98059e..7ae00716a208f82 100644
>> --- a/arch/x86/kernel/setup.c
>> +++ b/arch/x86/kernel/setup.c
>> @@ -456,7 +456,6 @@ static int __init reserve_crashkernel_low(void)
>>
>> crashk_low_res.start = low_base;
>> crashk_low_res.end = low_base + low_size - 1;
>> -insert_resource(_resource, _low_res);
>> #endif
>> return 0;
>> }
>> @@ -480,11 +479,6 @@ static void __init reserve_crashkernel(void)
>> high = true;
>> }
>>
>> -if (xen_pv_domain()) {
>> -pr_info("Ignoring crashkernel for a Xen PV domain\n");
>> -return;
>> -}
>> -
>> /* 0 means: find the address automatically */
>> if (!crash_base) {
>> /*
>> @@ -531,7 +525,6 @@ static void __init reserve_crashkernel(void)
>>
>> crashk_res.start = crash_base;
>> crashk_res.end = crash_base + crash_size - 1;
>> -insert_resource(_resource, _res);
>> }
>> #else
>> static void __init reserve_crashkernel(void)
>> @@ -1143,7 +1136,17 @@ void __init setup_arch(char **cmdline_p)
>> * Reserve memory for crash kernel after SRAT is parsed so that it
>> * won't consume hotpluggable memory.
>> */
>> -reserve_crashkernel();
>
> Hi Baoquan:
> How about move "#ifdef CONFIG_KEXEC_CORE" here, so that we can remove the
> empty reserve_crashkernel(). In fact, xen_pv_domain() is invoked only
> when CONFIG_KEXEC_CORE is enabled before.
Hi Baoquan:
Did you miss this email? If no reply, I will keep it no change.
>
>> +if (xen_pv_domain())
>> +pr_info("Ignoring crashkernel for a Xen PV domain\n");
>> +else {
>> +reserve_crashkernel();
>> +#ifdef CONFIG_KEXEC_CORE
>> +if (crashk_res.end > crashk_res.start)
>> +insert_resource(_resource, _res);
>> +if (crashk_low_res.end > crashk_low_res.start)
>> +insert_resource(_resource, _low_res);
>> +#endif
>> +}
>>
>> memblock_find_dma_reserve();
>>
>>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> .
>
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v17 02/10] x86: kdump: make the lower bound of crash kernel reservation consistent
On 2021/12/15 3:24, Catalin Marinas wrote: > On Tue, Dec 14, 2021 at 08:07:58PM +0100, Borislav Petkov wrote: >> On Fri, Dec 10, 2021 at 02:55:25PM +0800, Zhen Lei wrote: >>> From: Chen Zhou >>> >>> The lower bounds of crash kernel reservation and crash kernel low >>> reservation are different, use the consistent value CRASH_ALIGN. >> >> A big WHY is missing here to explain why the lower bound of the >> allocation range needs to be 16M and why was 0 wrong? > > I asked the same here: > > https://lore.kernel.org/r/20210224143547.gb28...@arm.com > > IIRC Baoquan said that there is a 1MB reserved for x86 anyway in the > lower part, so that's equivalent in practice to starting from > CRASH_ALIGN. > > Anyway, I agree the commit log should describe this. OK, I will add the description. > ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v17 05/10] x86: kdump: move reserve_crashkernel[_low]() into crash_core.c
On 2021/12/14 18:45, Baoquan He wrote: >> +/* User specifies base address explicitly. */ > If you plan to repost, please take above sentence off either. Then we > can say this patch is only doing code moving. > >> +unsigned long long start; >> + > OK, I can see that this patch is only moving code, and introducing > CONFIG_ARCH_WANT_RESERVE_CRASH_KERNEL to wrap them appropriately, no > extra functionality change added or removed, except of this place. > An alignment checking is added for the user specified base address. > I love this checking. While I have to say it will be more perfect if > it's put in another small patch, that will be look much better from > patch splitting and reviewing point of view. Good eye. I will put it in a new patch. > > This whole patch looks great to me, thanks for the effort. > > ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v17 04/10] x86: kdump: move xen_pv_domain() check and insert_resource() to setup_arch()
On 2021/12/10 14:55, Zhen Lei wrote:
> From: Chen Zhou
>
> We will make the functions reserve_crashkernel() as generic, the
> xen_pv_domain() check in reserve_crashkernel() is relevant only to
> x86, the same as insert_resource() in reserve_crashkernel[_low]().
> So move xen_pv_domain() check and insert_resource() to setup_arch()
> to keep them in x86.
>
> Suggested-by: Mike Rapoport
> Signed-off-by: Chen Zhou
> Signed-off-by: Zhen Lei
> Tested-by: John Donnelly
> Tested-by: Dave Kleikamp
> Acked-by: Baoquan He
> ---
> arch/x86/kernel/setup.c | 19 +++
> 1 file changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index bb2a0973b98059e..7ae00716a208f82 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -456,7 +456,6 @@ static int __init reserve_crashkernel_low(void)
>
> crashk_low_res.start = low_base;
> crashk_low_res.end = low_base + low_size - 1;
> - insert_resource(_resource, _low_res);
> #endif
> return 0;
> }
> @@ -480,11 +479,6 @@ static void __init reserve_crashkernel(void)
> high = true;
> }
>
> - if (xen_pv_domain()) {
> - pr_info("Ignoring crashkernel for a Xen PV domain\n");
> - return;
> - }
> -
> /* 0 means: find the address automatically */
> if (!crash_base) {
> /*
> @@ -531,7 +525,6 @@ static void __init reserve_crashkernel(void)
>
> crashk_res.start = crash_base;
> crashk_res.end = crash_base + crash_size - 1;
> - insert_resource(_resource, _res);
> }
> #else
> static void __init reserve_crashkernel(void)
> @@ -1143,7 +1136,17 @@ void __init setup_arch(char **cmdline_p)
>* Reserve memory for crash kernel after SRAT is parsed so that it
>* won't consume hotpluggable memory.
>*/
> - reserve_crashkernel();
Hi Baoquan:
How about move "#ifdef CONFIG_KEXEC_CORE" here, so that we can remove the
empty reserve_crashkernel(). In fact, xen_pv_domain() is invoked only
when CONFIG_KEXEC_CORE is enabled before.
> + if (xen_pv_domain())
> + pr_info("Ignoring crashkernel for a Xen PV domain\n");
> + else {
> + reserve_crashkernel();
> +#ifdef CONFIG_KEXEC_CORE
> + if (crashk_res.end > crashk_res.start)
> + insert_resource(_resource, _res);
> + if (crashk_low_res.end > crashk_low_res.start)
> + insert_resource(_resource, _low_res);
> +#endif
> + }
>
> memblock_find_dma_reserve();
>
>
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v17 01/10] x86: kdump: replace the hard-coded alignment with macro CRASH_ALIGN
On 2021/12/14 3:54, Borislav Petkov wrote: >> Subject: Re: [PATCH v17 01/10] x86: kdump: replace the hard-coded alignment >> with macro CRASH_ALIGN > >>From Documentation/process/maintainer-tip.rst: > > "Patch subject > ^ > > The tip tree preferred format for patch subject prefixes is > 'subsys/component:', e.g. 'x86/apic:', 'x86/mm/fault:', 'sched/fair:', > 'genirq/core:'. Please do not use file names or complete file paths as > prefix. 'git log path/to/file' should give you a reasonable hint in most > cases. > > The condensed patch description in the subject line should start with a > uppercase letter and should be written in imperative tone." > > Please fix 1-5 for your next submission. OK. I will update them. > > Thx. > ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v17 02/10] x86: kdump: make the lower bound of crash kernel reservation consistent
On 2021/12/13 21:37, Baoquan He wrote:
> On 12/10/21 at 02:55pm, Zhen Lei wrote:
>> From: Chen Zhou
>>
>> The lower bounds of crash kernel reservation and crash kernel low
>> reservation are different, use the consistent value CRASH_ALIGN.
>>
>> Suggested-by: Dave Young
>> Signed-off-by: Chen Zhou
>> Signed-off-by: Zhen Lei
>
> You may need add Co-developed-by to clarify who is author, and who is
> co-author. Please check section "When to use Acked-by:, Cc:, and
> Co-developed-by:"
> of Documentation/process/submitting-patches.rst. Otherwise,
Okay, thanks for the heads-up. I will modify it.
>
> Acked-by: Baoquan He
>
>> Tested-by: John Donnelly
>> Tested-by: Dave Kleikamp
>> ---
>> arch/x86/kernel/setup.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
>> index 5cc60996eac56d6..6424ee4f23da2cf 100644
>> --- a/arch/x86/kernel/setup.c
>> +++ b/arch/x86/kernel/setup.c
>> @@ -441,7 +441,8 @@ static int __init reserve_crashkernel_low(void)
>> return 0;
>> }
>>
>> -low_base = memblock_phys_alloc_range(low_size, CRASH_ALIGN, 0,
>> CRASH_ADDR_LOW_MAX);
>> +low_base = memblock_phys_alloc_range(low_size, CRASH_ALIGN, CRASH_ALIGN,
>> +CRASH_ADDR_LOW_MAX);
>> if (!low_base) {
>> pr_err("Cannot reserve %ldMB crashkernel low memory, please try
>> smaller size.\n",
>> (unsigned long)(low_size >> 20));
>> --
>> 2.25.1
>>
>
> .
>
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v17 01/10] x86: kdump: replace the hard-coded alignment with macro CRASH_ALIGN
On 2021/12/13 21:17, Baoquan He wrote: > On 12/10/21 at 02:55pm, Zhen Lei wrote: >> From: Chen Zhou >> >> Move CRASH_ALIGN to header asm/kexec.h for later use. >> >> Suggested-by: Dave Young >> Suggested-by: Baoquan He > > I remember Dave and I discussed and suggested this when reviewing. > You can remove my Suggested-by. OK, I will do it. > > For this one, I would like to add ack: > > Acked-by: Baoquan He > >> Signed-off-by: Chen Zhou >> Signed-off-by: Zhen Lei >> Tested-by: John Donnelly >> Tested-by: Dave Kleikamp >> --- >> arch/x86/include/asm/kexec.h | 3 +++ >> arch/x86/kernel/setup.c | 3 --- >> 2 files changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/arch/x86/include/asm/kexec.h b/arch/x86/include/asm/kexec.h >> index 11b7c06e2828c30..3a22e65262aa70b 100644 >> --- a/arch/x86/include/asm/kexec.h >> +++ b/arch/x86/include/asm/kexec.h >> @@ -18,6 +18,9 @@ >> >> # define KEXEC_CONTROL_CODE_MAX_SIZE2048 >> >> +/* 16M alignment for crash kernel regions */ >> +#define CRASH_ALIGN SZ_16M >> + >> #ifndef __ASSEMBLY__ >> >> #include >> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c >> index 6a190c7f4d71b05..5cc60996eac56d6 100644 >> --- a/arch/x86/kernel/setup.c >> +++ b/arch/x86/kernel/setup.c >> @@ -392,9 +392,6 @@ static void __init >> memblock_x86_reserve_range_setup_data(void) >> >> #ifdef CONFIG_KEXEC_CORE >> >> -/* 16M alignment for crash kernel regions */ >> -#define CRASH_ALIGN SZ_16M >> - >> /* >> * Keep the crash kernel below this limit. >> * >> -- >> 2.25.1 >> > > . > ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v16 08/11] x86, arm64: Add ARCH_WANT_RESERVE_CRASH_KERNEL config
On 2021/12/9 1:09, Catalin Marinas wrote:
> On Tue, Nov 23, 2021 at 08:46:43PM +0800, Zhen Lei wrote:
>> diff --git a/arch/Kconfig b/arch/Kconfig
>> index 26b8ed11639da46..19256aa924c3b2c 100644
>> --- a/arch/Kconfig
>> +++ b/arch/Kconfig
>> @@ -24,6 +24,9 @@ config KEXEC_ELF
>> config HAVE_IMA_KEXEC
>> bool
>>
>> +config ARCH_WANT_RESERVE_CRASH_KERNEL
>> +bool
>> +
>> config SET_FS
>> bool
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index c4207cf9bb17ffb..4b99efa36da3793 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -95,6 +95,7 @@ config ARM64
>> select ARCH_WANT_FRAME_POINTERS
>> select ARCH_WANT_HUGE_PMD_SHARE if ARM64_4K_PAGES || (ARM64_16K_PAGES
>> && !ARM64_VA_BITS_36)
>> select ARCH_WANT_LD_ORPHAN_WARN
>> +select ARCH_WANT_RESERVE_CRASH_KERNEL if KEXEC_CORE
>> select ARCH_WANTS_NO_INSTR
>> select ARCH_HAS_UBSAN_SANITIZE_ALL
>> select ARM_AMBA
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index 7399327d1eff79d..528034b4276ecf8 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -12,6 +12,7 @@ config X86_32
>> depends on !64BIT
>> # Options that are inherently 32-bit kernel only:
>> select ARCH_WANT_IPC_PARSE_VERSION
>> +select ARCH_WANT_RESERVE_CRASH_KERNEL if KEXEC_CORE
>> select CLKSRC_I8253
>> select CLONE_BACKWARDS
>> select GENERIC_VDSO_32
>> @@ -28,6 +29,7 @@ config X86_64
>> select ARCH_HAS_GIGANTIC_PAGE
>> select ARCH_SUPPORTS_INT128 if CC_HAS_INT128
>> select ARCH_USE_CMPXCHG_LOCKREF
>> +select ARCH_WANT_RESERVE_CRASH_KERNEL if KEXEC_CORE
>> select HAVE_ARCH_SOFT_DIRTY
>> select MODULES_USE_ELF_RELA
>> select NEED_DMA_MAP_STATE
>> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
>> index 4dc2643fcbccf99..b23cfc0ca8905fd 100644
>> --- a/kernel/crash_core.c
>> +++ b/kernel/crash_core.c
>> @@ -321,9 +321,7 @@ int __init parse_crashkernel_low(char *cmdline,
>> * - Crashkernel reservation --
>> */
>>
>> -#ifdef CONFIG_KEXEC_CORE
>> -
>> -#if defined(CONFIG_X86) || defined(CONFIG_ARM64)
>> +#ifdef CONFIG_ARCH_WANT_RESERVE_CRASH_KERNEL
>> static int __init reserve_crashkernel_low(void)
>> {
>> #ifdef CONFIG_64BIT
>> @@ -451,8 +449,7 @@ void __init reserve_crashkernel(void)
>> crashk_res.start = crash_base;
>> crashk_res.end = crash_base + crash_size - 1;
>> }
>> -#endif
>> -#endif /* CONFIG_KEXEC_CORE */
>> +#endif /* CONFIG_ARCH_WANT_RESERVE_CRASH_KERNEL */
>
> Nitpick mostly but it may simplify the patches if the x86, arch/Kconfig
> and crash_core.c changes here could be moved to patch 5. The remaining
> select for arm64 should be moved to patch 7 and drop the #if change in
> that patch.
>
> This way we can keep the x86 patches on a separate branch.
That's a good suggestion. I will do it.
>
> Thanks.
>
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v16 10/11] of: fdt: Add memory for devices by DT property "linux,usable-memory-range"
On 2021/12/1 10:55, Leizhen (ThunderTown) wrote:
>>> + }
>>>
>>> - memblock_cap_memory_range(cap_mem_addr, cap_mem_size);
>>> + memblock_cap_memory_range(rgn[0].base, rgn[0].size);
>>> + for (i = 1; i < MAX_USABLE_RANGES && rgn[i].size; i++)
>> s/ &&/,/
Hi Rob:
I want to keep "&&" unchanged, do you mind? I'm going to post an
updated version tomorrow, hopefully the last.
> Hi Rob:
>
> The comma operator may not be suitable for logical judgment. The logical
> judgment
> before commas (,) is ignored.
>
> Here's my test：
>
> C code：
> int main()
> {
> int i, j;
>
> printf("&&:\n");
> for (i = 0, j = 0; i < 2 && j < 3; i++, j++)
> printf("i=%d, j=%d\n", i, j);
>
> printf("\ncomma:\n");
> for (i = 0, j = 0; i < 2, j < 3; i++, j++)//(i < 2） before comma
> is ignored
> printf("i=%d, j=%d\n", i, j);
>
> return 0;
> }
>
> Output：
> &&:
> i=0, j=0
> i=1, j=1
>
> comma:
> i=0, j=0
> i=1, j=1
> i=2, j=2
>
>
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v16 10/11] of: fdt: Add memory for devices by DT property "linux,usable-memory-range"
On 2021/12/1 6:16, Rob Herring wrote:
> On Tue, Nov 23, 2021 at 08:46:45PM +0800, Zhen Lei wrote:
>> From: Chen Zhou
>>
>> When reserving crashkernel in high memory, some low memory is reserved
>> for crash dump kernel devices and never mapped by the first kernel.
>> This memory range is advertised to crash dump kernel via DT property
>> under /chosen,
>> linux,usable-memory-range =
>>
>> We reused the DT property linux,usable-memory-range and made the low
>> memory region as the second range "BASE2 SIZE2", which keeps compatibility
>> with existing user-space and older kdump kernels.
>>
>> Crash dump kernel reads this property at boot time and call memblock_add()
>> to add the low memory region after memblock_cap_memory_range() has been
>> called.
>>
>> Signed-off-by: Chen Zhou
>> Signed-off-by: Zhen Lei
>> ---
>> drivers/of/fdt.c | 36 ++--
>> 1 file changed, 26 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
>> index 37b477a51175359..1ea2a0b1657e3a9 100644
>> --- a/drivers/of/fdt.c
>> +++ b/drivers/of/fdt.c
>> @@ -967,6 +967,15 @@ static void __init
>> early_init_dt_check_for_elfcorehdr(unsigned long node)
>>
>> static unsigned long chosen_node_offset = -FDT_ERR_NOTFOUND;
>>
>> +/*
>> + * The main usage of linux,usable-memory-range is for crash dump kernel.
>> + * Originally, the number of usable-memory regions is one. Now there may
>> + * be two regions, low region and high region.
>> + * To make compatibility with existing user-space and older kdump, the low
>> + * region is always the last range of linux,usable-memory-range if exist.
>> + */
>> +#define MAX_USABLE_RANGES 2
>> +
>> /**
>> * early_init_dt_check_for_usable_mem_range - Decode usable memory range
>> * location from flat tree
>> @@ -974,10 +983,9 @@ static unsigned long chosen_node_offset =
>> -FDT_ERR_NOTFOUND;
>> */
>> static void __init early_init_dt_check_for_usable_mem_range(unsigned long
>> node)
>> {
>> -const __be32 *prop;
>> -int len;
>> -phys_addr_t cap_mem_addr;
>> -phys_addr_t cap_mem_size;
>> +struct memblock_region rgn[MAX_USABLE_RANGES] = {0};
>> +const __be32 *prop, *endp;
>> +int len, i = 0;
>>
>> if ((long)node < 0)
>> return;
>> @@ -985,16 +993,24 @@ static void __init
>> early_init_dt_check_for_usable_mem_range(unsigned long node)
>> pr_debug("Looking for usable-memory-range property... ");
>>
>> prop = of_get_flat_dt_prop(node, "linux,usable-memory-range", );
>> -if (!prop || (len < (dt_root_addr_cells + dt_root_size_cells)))
>> +if (!prop)
>
> if (!prop || (len % (dt_root_addr_cells + dt_root_size_cells)))
OK.
>
>> return;
>>
>> -cap_mem_addr = dt_mem_next_cell(dt_root_addr_cells, );
>> -cap_mem_size = dt_mem_next_cell(dt_root_size_cells, );
>> +endp = prop + (len / sizeof(__be32));
>> +while ((endp - prop) >= (dt_root_addr_cells + dt_root_size_cells)) {
>
> for (i = 0; i < MAX_USABLE_RANGES, prop < endp; i++) {
>
>> +rgn[i].base = dt_mem_next_cell(dt_root_addr_cells, );
>> +rgn[i].size = dt_mem_next_cell(dt_root_size_cells, );
>> +
>> +pr_debug("cap_mem_regions[%d]: base=%pa, size=%pa\n",
>> + i, [i].base, [i].size);
>>
>> -pr_debug("cap_mem_start=%pa cap_mem_size=%pa\n", _mem_addr,
>> - _mem_size);
>> +if (++i >= MAX_USABLE_RANGES)
>> +break;
>
> And drop this if.
OK.
>
>> +}
>>
>> -memblock_cap_memory_range(cap_mem_addr, cap_mem_size);
>> +memblock_cap_memory_range(rgn[0].base, rgn[0].size);
>> +for (i = 1; i < MAX_USABLE_RANGES && rgn[i].size; i++)
>
> s/ &&/,/
Hi Rob:
The comma operator may not be suitable for logical judgment. The logical
judgment
before commas (,) is ignored.
Here's my test：
C code：
int main()
{
int i, j;
printf("&&:\n");
for (i = 0, j = 0; i < 2 && j < 3; i++, j++)
printf("i=%d, j=%d\n", i, j);
printf("\ncomma:\n");
for (i = 0, j = 0; i < 2, j < 3; i++, j++) //(i < 2） before comma
is ignored
printf("i=%d, j=%d\n", i, j);
return 0;
}
Output：
&&:
i=0, j=0
i=1, j=1
comma:
i=0, j=0
i=1, j=1
i=2, j=2
>
>> +memblock_add(rgn[i].base, rgn[i].size);
>> }
>>
>> #ifdef CONFIG_SERIAL_EARLYCON
>> --
>> 2.25.1
>>
>>
>
> .
>
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v15 09/10] of: fdt: Add memory for devices by DT property "linux,usable-memory-range"
On 2021/10/20 22:19, Rob Herring wrote:
> On Wed, Oct 20, 2021 at 10:03:16AM +0800, Zhen Lei wrote:
>> From: Chen Zhou
>>
>> When reserving crashkernel in high memory, some low memory is reserved
>> for crash dump kernel devices and never mapped by the first kernel.
>> This memory range is advertised to crash dump kernel via DT property
>> under /chosen,
>> linux,usable-memory-range =
>>
>> We reused the DT property linux,usable-memory-range and made the low
>> memory region as the second range "BASE2 SIZE2", which keeps compatibility
>> with existing user-space and older kdump kernels.
>>
>> Crash dump kernel reads this property at boot time and call memblock_add()
>> to add the low memory region after memblock_cap_memory_range() has been
>> called.
>>
>> Signed-off-by: Chen Zhou
>> Signed-off-by: Zhen Lei
>> ---
>> drivers/of/fdt.c | 47 ---
>> 1 file changed, 36 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
>> index 4546572af24bbf1..cf59c847b2c28a5 100644
>> --- a/drivers/of/fdt.c
>> +++ b/drivers/of/fdt.c
>> @@ -969,8 +969,16 @@ static void __init
>> early_init_dt_check_for_elfcorehdr(unsigned long node)
>> elfcorehdr_addr, elfcorehdr_size);
>> }
>>
>> -static phys_addr_t cap_mem_addr;
>> -static phys_addr_t cap_mem_size;
>> +/*
>> + * The main usage of linux,usable-memory-range is for crash dump kernel.
>> + * Originally, the number of usable-memory regions is one. Now there may
>> + * be two regions, low region and high region.
>> + * To make compatibility with existing user-space and older kdump, the low
>> + * region is always the last range of linux,usable-memory-range if exist.
>> + */
>> +#define MAX_USABLE_RANGES 2
>> +
>> +static struct memblock_region cap_mem_regions[MAX_USABLE_RANGES];
>>
>> /**
>> * early_init_dt_check_for_usable_mem_range - Decode usable memory range
>> @@ -979,20 +987,30 @@ static phys_addr_t cap_mem_size;
>> */
>> static void __init early_init_dt_check_for_usable_mem_range(unsigned long
>> node)
>> {
>> -const __be32 *prop;
>> -int len;
>> +const __be32 *prop, *endp;
>> +int len, nr = 0;
>> +struct memblock_region *rgn = _mem_regions[0];
>>
>> pr_debug("Looking for usable-memory-range property... ");
>>
>> prop = of_get_flat_dt_prop(node, "linux,usable-memory-range", );
>> -if (!prop || (len < (dt_root_addr_cells + dt_root_size_cells)))
>> +if (!prop)
>> return;
>>
>> -cap_mem_addr = dt_mem_next_cell(dt_root_addr_cells, );
>> -cap_mem_size = dt_mem_next_cell(dt_root_size_cells, );
>> +endp = prop + (len / sizeof(__be32));
>> +while ((endp - prop) >= (dt_root_addr_cells + dt_root_size_cells)) {
>> +rgn->base = dt_mem_next_cell(dt_root_addr_cells, );
>> +rgn->size = dt_mem_next_cell(dt_root_size_cells, );
>> +
>> +pr_debug("cap_mem_regions[%d]: base=%pa, size=%pa\n",
>> + nr, >base, >size);
>> +
>> +if (++nr >= MAX_USABLE_RANGES)
>> +break;
>> +
>> +rgn++;
>> +}
>>
>> -pr_debug("cap_mem_start=%pa cap_mem_size=%pa\n", _mem_addr,
>> - _mem_size);
>> }
>>
>> #ifdef CONFIG_SERIAL_EARLYCON
>> @@ -1265,7 +1283,8 @@ bool __init early_init_dt_verify(void *params)
>>
>> void __init early_init_dt_scan_nodes(void)
>> {
>> -int rc = 0;
>> +int i, rc = 0;
>> +struct memblock_region *rgn = _mem_regions[0];
>>
>> /* Initialize {size,address}-cells info */
>> of_scan_flat_dt(early_init_dt_scan_root, NULL);
>> @@ -1279,7 +1298,13 @@ void __init early_init_dt_scan_nodes(void)
>> of_scan_flat_dt(early_init_dt_scan_memory, NULL);
>>
>> /* Handle linux,usable-memory-range property */
>> -memblock_cap_memory_range(cap_mem_addr, cap_mem_size);
>> +memblock_cap_memory_range(rgn->base, rgn->size);
>> +for (i = 1; i < MAX_USABLE_RANGES; i++) {
>> +rgn++;
>
> Just use rgn[i].
OK.
>
>> +
>> +if (rgn->size)
>
> This check can be in the 'for' conditions check.
Yes, this node is added by kexec tool, it is impossible that
the first range is zero and the second range is not zero.
>
>> +memblock_add(rgn->base, rgn->size);
>> +}
>
>
> There's not really any point in doing all this in 2 steps. I'm
> assuming this needs to be handled after scanning the memory nodes, so
> can you refactor this moving early_init_dt_check_for_usable_mem_range
> out of early_init_dt_scan_chosen() and call it here. You'll have to get
> the offset for /chosen twice or save the offset.
This's a good suggestion. I'll refactor it. Thanks.
Zhen Lei
>
> Rob
> .
>
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 1/1] kernel: fix numerous spelling mistakes
On 2021/5/29 7:18, Eric W. Biederman wrote: > Zhen Lei writes: > >> Fix some spelling mistakes in comments: >> suspeneded ==> suspended >> occuring ==> occurring >> wont ==> won't >> detatch ==> detach >> represntation ==> representation >> hexidecimal ==> hexadecimal >> delimeter ==> delimiter >> architecure ==> architecture >> accumalator ==> accumulator >> evertything ==> everything >> contingous ==> contiguous >> useable ==> usable >> musn't ==> mustn't >> alloed ==> allowed >> immmediately ==> immediately >> Allocted ==> Allocated >> noone ==> no one >> unparseable ==> unparsable >> dependend ==> dependent >> callled ==> called >> alreay ==> already >> childs ==> children >> implemention ==> implementation >> situration ==> situation >> overriden ==> overridden >> asynchonous ==> asynchronous >> accumalate ==> accumulate >> syncrhonized ==> synchronized >> therefor ==> therefore >> ther ==> their >> capabilites ==> capabilities >> lentgh ==> length >> watchog ==> watchdog >> assing ==> assign >> Retun ==> Return > > I took a quick read through and everything looks like a good spelling > correction, and on top of that this looks safe as it just comments being > changed? Yes, all changes are in the comments. > > How were you thinking of getting this merged? > > Do we have a misc maintainer? If the individual maintainers need to > merge this than this patch should probably get split as these files > cover lot areas that different people take care of. Okay, I'm thinking of splitting it up. However, this leads to more patches. > > Acked-by: "Eric W. Biederman" > >> >> Signed-off-by: Zhen Lei >> --- >> kernel/acct.c | 2 +- >> kernel/context_tracking.c | 2 +- >> kernel/cpu.c | 2 +- >> kernel/debug/debug_core.c | 2 +- >> kernel/debug/kdb/kdb_main.c| 8 >> kernel/debug/kdb/kdb_private.h | 2 +- >> kernel/delayacct.c | 2 +- >> kernel/dma/map_benchmark.c | 2 +- >> kernel/dma/swiotlb.c | 2 +- >> kernel/exit.c | 2 +- >> kernel/hung_task.c | 2 +- >> kernel/kexec_core.c| 2 +- >> kernel/kprobes.c | 2 +- >> kernel/latencytop.c| 2 +- >> kernel/module.c| 4 ++-- >> kernel/notifier.c | 2 +- >> kernel/padata.c| 2 +- >> kernel/panic.c | 2 +- >> kernel/pid.c | 2 +- >> kernel/ptrace.c| 2 +- >> kernel/relay.c | 2 +- >> kernel/signal.c| 4 ++-- >> kernel/smp.c | 2 +- >> kernel/taskstats.c | 2 +- >> kernel/time/alarmtimer.c | 2 +- >> kernel/time/timer.c| 4 ++-- >> kernel/umh.c | 2 +- >> kernel/user_namespace.c| 2 +- >> kernel/usermode_driver.c | 2 +- >> kernel/watchdog.c | 2 +- >> kernel/workqueue.c | 4 ++-- >> 31 files changed, 38 insertions(+), 38 deletions(-) >> >> diff --git a/kernel/acct.c b/kernel/acct.c >> index a64102be2bb0..5ace865b6176 100644 >> --- a/kernel/acct.c >> +++ b/kernel/acct.c >> @@ -26,7 +26,7 @@ >> * XTerms and EMACS are manifestations of pure evil. 21/10/98, AV. >> * >> * Fixed a nasty interaction with sys_umount(). If the accounting >> - * was suspeneded we failed to stop it on umount(). Messy. >> + * was suspended we failed to stop it on umount(). Messy. >> * Another one: remount to readonly didn't stop accounting. >> * Question: what should we do if we have CAP_SYS_ADMIN but not >> * CAP_SYS_PACCT? Current code does the following: umount returns -EBUSY >> diff --git a/kernel/context_tracking.c b/kernel/context_tracking.c >> index 36a98c48aedc..53f525604ce8 100644 >> --- a/kernel/context_tracking.c >> +++ b/kernel/context_tracking.c >> @@ -108,7 +108,7 @@ void context_tracking_enter(enum ctx_state state) >> unsigned long flags; >> >> /* >> - * Some contexts may involve an exception occuring in an irq, >> + * Some contexts may involve an exception occurring in an irq, >> * leading to that nesting: >> * rcu_irq_enter() rcu_user_exit() rcu_user_exit() rcu_irq_exit() >> * This would mess up the dyntick_nesting count though. And rcu_irq_*() >> diff --git a/kernel/cpu.c b/kernel/cpu.c >> index e538518556f4..f6f6613a4c04 100644 >> --- a/kernel/cpu.c >> +++ b/kernel/cpu.c >> @@ -832,7 +832,7 @@ cpuhp_invoke_ap_callback(int cpu, enum cpuhp_state >> state, bool bringup, >> } >> >> /* >> - * Clean up the leftovers so the next hotplug operation wont use stale >> + * Clean up the leftovers so the next hotplug operation won't use stale >> * data. >> */ >> st->node = st->last = NULL; >> diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c >> index 4708aec492df..a1f26766eb90 100644 >> --- a/kernel/debug/debug_core.c >> +++ b/kernel/debug/debug_core.c >> @@ -1032,7 +1032,7 @@
