Re: [PATCH v2 4/4] kho: rename kho_scratch= commandline parameter to kho_bootmem=

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] The patch series renames the device tree property from 'linux,kho-scratch' to 'linux,kho-bootmem' in the kexec sender, but fails to update the receiver, breaking Kexec Handover completely on OF/DeviceTree platforms.
- [Medium] The kernel parameter `kho_scratch=` is renamed to `kho_bootmem=` without retaining a fallback, breaking backward compatibility.
- [Low] Typo in the dummy implementation of `memblock_set_kho_noprsrv_only` for !CONFIG_KEXEC_HANDOVER.
- [Low] The patch fails to update 'scratch' terminology in several KHO-related comments, leaving the subsystem documentation in an inconsistent state.
--

commit 59d6b2029e0b48c319862bcfeb71dd0dd1ccc43d
Author: Pratyush Yadav (Google) <pratyush@kernel.org>

kho: rename kho_scratch= commandline parameter to kho_bootmem=

KHO now no longer uses "scratch" to describe the memory areas passed by
previous kernel. Instead, it calls them boot memory, or bootmem in
short. Rename the kho_scratch= commandline parameter to reflect this
terminology change.

> diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
> index fe4b76ff5a2cc..7018e25e4eda1 100644
> --- a/kernel/liveupdate/kexec_handover.c
> +++ b/kernel/liveupdate/kexec_handover.c
[ ... ]
> @@ -751,7 +751,7 @@ static int __init kho_parse_bootmem_size(char *p)
>  
>  	return 0;
>  }
> -early_param("kho_scratch", kho_parse_bootmem_size);
> +early_param("kho_bootmem", kho_parse_bootmem_size);

[Severity: Medium]
Does the removal of the old parameter alias completely drop support for
existing configurations?

User configuration scripts or bootloaders using the kho_scratch= parameter
will silently fail to configure the KHO bootmem size, potentially causing
Kexec Handover to fail or behave incorrectly due to default memory
allocations.

Could a fallback early_param for kho_scratch be retained to prevent this
regression?

[Severity: High]
Does this patch series introduce a property name mismatch between the kexec
sender and receiver?

The sender kernel writes the new property in drivers/of/kexec.c:

    ret = fdt_appendprop_addrrange(fdt, 0, chosen_node, "linux,kho-bootmem",
                                   bootmem_arr, bootmem_len);

However, the receiver kernel still attempts to read the device tree property
using the obsolete name in drivers/of/fdt.c:early_init_dt_check_kho():

    if (!of_flat_dt_get_addr_size(node, "linux,kho-scratch",
                                  &scratch_start, &scratch_size))
        return;

Will this mismatch cause a silent failure of the handover process on Device
Tree-based architectures, since of_flat_dt_get_addr_size will fail to find
the required property?

[Severity: Low]
This isn't a bug, but is there a typo in the fallback macro definition for
!CONFIG_KEXEC_HANDOVER?

In include/linux/memblock.h:

#ifdef CONFIG_KEXEC_HANDOVER
void memblock_set_kho_noprsrv_only(void);
void memblock_clear_kho_noprsrv_only(void);
#else
static inline void memblock_set_kho_noprsev_only(void) { }
static inline void memblock_clear_kho_noprsrv_only(void) { }
#endif

The dummy function is defined as memblock_set_kho_noprsev_only instead of
memblock_set_kho_noprsrv_only. Any future code attempting to call this
function outside of conditionally compiled KHO code will encounter a
compilation error.

[Severity: Low]
This isn't a bug, but several comments still use the obsolete scratch
terminology.

In kernel/kexec_file.c:kexec_locate_mem_hole():

    /*
     * If KHO is active, only use KHO scratch memory. All other memory
     * could potentially be handed over.
     */

In mm/memfd_luo.c:luo_memfd_pin_folios():

     * ensures none of the folios are in CMA -- which ensures they don't
     * fall in KHO scratch memory. It also moves swapped out folios back to

Could these comments be updated to reflect the new bootmem terminology for
consistency?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260908155639.2496551-1-pratyush@kernel.org?part=4