Re: [PATCH 01/12] kho: generalize radix tree APIs

Re: [PATCH 01/12] kho: generalize radix tree APIs

[Pasha Tatashin]

On 04-29 15:39, Pratyush Yadav wrote:
> From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
> 
> The KHO radix tree is a data structure that can track the presence or
> absence of an arbitrary key, with nothing inherently tied to KHO memory
> preservation tracking. This was one of the design goals of the radix
> tree. This was done to enable it to be re-used by other users of KHO.
> 
> Despite that, the radix tree APIs are very closely tied to KHO memory
> preservation tracking. Adding a key is done by kho_radix_add_page(),
> which encodes it as a page tracking operation and takes in PFN and
> order. kho_radix_del_page() does the same. These functions encode the
> key internally that goes into the radix tree. kho_radix_walk_tree() does
> the same by baking the PFN and order into the callback arguments.
> 
> Generalize the APIs by taking the key directly and doing the encoding at
> the callers. Rename the functions to kho_radix_add_key() and
> kho_radix_del_key(). In practice, this removes a line each from the
> functions and moves the encoding function call to the callers.
> Similarly, update kho_radix_tree_walk_callback_t to take the key
> directly.
> 
> To keep the naming convention clearer, rename
> kho_radix_{encode,decode}_key() to kho_{encode,decode}_radix_key().
> 
> Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>

Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com> 

> ---
>  include/linux/kho_radix_tree.h     | 18 +++----
>  kernel/liveupdate/kexec_handover.c | 76 ++++++++++++++----------------
>  2 files changed, 42 insertions(+), 52 deletions(-)
> 
> diff --git a/include/linux/kho_radix_tree.h b/include/linux/kho_radix_tree.h
> index 84e918b96e53..f368f3b9f923 100644
> --- a/include/linux/kho_radix_tree.h
> +++ b/include/linux/kho_radix_tree.h
> @@ -34,30 +34,24 @@ struct kho_radix_tree {
>  	struct mutex lock; /* protects the tree's structure and root pointer */
>  };
>  
> -typedef int (*kho_radix_tree_walk_callback_t)(phys_addr_t phys,
> -					      unsigned int order);
> +typedef int (*kho_radix_tree_walk_callback_t)(unsigned long key);
>  
>  #ifdef CONFIG_KEXEC_HANDOVER
>  
> -int kho_radix_add_page(struct kho_radix_tree *tree, unsigned long pfn,
> -		       unsigned int order);
> -
> -void kho_radix_del_page(struct kho_radix_tree *tree, unsigned long pfn,
> -			unsigned int order);
> -
> +int kho_radix_add_key(struct kho_radix_tree *tree, unsigned long key);
> +void kho_radix_del_key(struct kho_radix_tree *tree, unsigned long key);
>  int kho_radix_walk_tree(struct kho_radix_tree *tree,
>  			kho_radix_tree_walk_callback_t cb);
>  
>  #else  /* #ifdef CONFIG_KEXEC_HANDOVER */
>  
> -static inline int kho_radix_add_page(struct kho_radix_tree *tree, long pfn,
> -				     unsigned int order)
> +static inline int kho_radix_add_key(struct kho_radix_tree *tree, unsigned long key)
>  {
>  	return -EOPNOTSUPP;
>  }
>  
> -static inline void kho_radix_del_page(struct kho_radix_tree *tree,
> -				      unsigned long pfn, unsigned int order) { }
> +static inline void kho_radix_del_key(struct kho_radix_tree *tree,
> +				     unsigned long key) { }
>  
>  static inline int kho_radix_walk_tree(struct kho_radix_tree *tree,
>  				      kho_radix_tree_walk_callback_t cb)
> diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
> index 33fcf848ef95..ba568d34c5b4 100644
> --- a/kernel/liveupdate/kexec_handover.c
> +++ b/kernel/liveupdate/kexec_handover.c
> @@ -85,7 +85,7 @@ static struct kho_out kho_out = {
>  };
>  
>  /**
> - * kho_radix_encode_key - Encodes a physical address and order into a radix key.
> + * kho_encode_radix_key - Encodes a physical address and order into a radix key.
>   * @phys: The physical address of the page.
>   * @order: The order of the page.
>   *
> @@ -95,7 +95,7 @@ static struct kho_out kho_out = {
>   *
>   * Return: The encoded unsigned long radix key.
>   */
> -static unsigned long kho_radix_encode_key(phys_addr_t phys, unsigned int order)
> +static unsigned long kho_encode_radix_key(phys_addr_t phys, unsigned int order)
>  {
>  	/* Order bits part */
>  	unsigned long h = 1UL << (KHO_ORDER_0_LOG2 - order);
> @@ -106,17 +106,17 @@ static unsigned long kho_radix_encode_key(phys_addr_t phys, unsigned int order)
>  }
>  
>  /**
> - * kho_radix_decode_key - Decodes a radix key back into a physical address and order.
> + * kho_decode_radix_key - Decodes a radix key back into a physical address and order.
>   * @key: The unsigned long key to decode.
>   * @order: An output parameter, a pointer to an unsigned int where the decoded
>   *         page order will be stored.
>   *
> - * This function reverses the encoding performed by kho_radix_encode_key(),
> + * This function reverses the encoding performed by kho_encode_radix_key(),
>   * extracting the original physical address and page order from a given key.
>   *
>   * Return: The decoded physical address.
>   */
> -static phys_addr_t kho_radix_decode_key(unsigned long key, unsigned int *order)
> +static phys_addr_t kho_decode_radix_key(unsigned long key, unsigned int *order)
>  {
>  	unsigned int order_bit = fls64(key);
>  	phys_addr_t phys;
> @@ -144,24 +144,21 @@ static unsigned long kho_radix_get_table_index(unsigned long key,
>  }
>  
>  /**
> - * kho_radix_add_page - Marks a page as preserved in the radix tree.
> + * kho_radix_add_key - Add a key to the radix tree.
>   * @tree: The KHO radix tree.
> - * @pfn: The page frame number of the page to preserve.
> - * @order: The order of the page.
> + * @key: The key to add.
>   *
> - * This function traverses the radix tree based on the key derived from @pfn
> - * and @order. It sets the corresponding bit in the leaf bitmap to mark the
> - * page for preservation. If intermediate nodes do not exist along the path,
> - * they are allocated and added to the tree.
> + * This function traverses the radix tree based on the key provided. It sets the
> + * corresponding bit in the leaf bitmap to mark the key as present. If
> + * intermediate nodes do not exist along the path, they are allocated and added
> + * to the tree.
>   *
>   * Return: 0 on success, or a negative error code on failure.
>   */
> -int kho_radix_add_page(struct kho_radix_tree *tree,
> -		       unsigned long pfn, unsigned int order)
> +int kho_radix_add_key(struct kho_radix_tree *tree, unsigned long key)
>  {
>  	/* Newly allocated nodes for error cleanup */
>  	struct kho_radix_node *intermediate_nodes[KHO_TREE_MAX_DEPTH] = { 0 };
> -	unsigned long key = kho_radix_encode_key(PFN_PHYS(pfn), order);
>  	struct kho_radix_node *anchor_node = NULL;
>  	struct kho_radix_node *node = tree->root;
>  	struct kho_radix_node *new_node;
> @@ -224,22 +221,19 @@ int kho_radix_add_page(struct kho_radix_tree *tree,
>  
>  	return err;
>  }
> -EXPORT_SYMBOL_GPL(kho_radix_add_page);
> +EXPORT_SYMBOL_GPL(kho_radix_add_key);
>  
>  /**
> - * kho_radix_del_page - Removes a page's preservation status from the radix tree.
> + * kho_radix_del_key - Removes the key from the radix tree.
>   * @tree: The KHO radix tree.
> - * @pfn: The page frame number of the page to unpreserve.
> - * @order: The order of the page.
> + * @key: The key to remove.
>   *
>   * This function traverses the radix tree and clears the bit corresponding to
> - * the page, effectively removing its "preserved" status. It does not free
> - * the tree's intermediate nodes, even if they become empty.
> + * the key, effectively removing it from the tree. It does not free the tree's
> + * intermediate nodes, even if they become empty.
>   */
> -void kho_radix_del_page(struct kho_radix_tree *tree, unsigned long pfn,
> -			unsigned int order)
> +void kho_radix_del_key(struct kho_radix_tree *tree, unsigned long key)
>  {
> -	unsigned long key = kho_radix_encode_key(PFN_PHYS(pfn), order);
>  	struct kho_radix_node *node = tree->root;
>  	struct kho_radix_leaf *leaf;
>  	unsigned int i, idx;
> @@ -270,21 +264,18 @@ void kho_radix_del_page(struct kho_radix_tree *tree, unsigned long pfn,
>  	idx = kho_radix_get_bitmap_index(key);
>  	__clear_bit(idx, leaf->bitmap);
>  }
> -EXPORT_SYMBOL_GPL(kho_radix_del_page);
> +EXPORT_SYMBOL_GPL(kho_radix_del_key);
>  
>  static int kho_radix_walk_leaf(struct kho_radix_leaf *leaf,
>  			       unsigned long key,
>  			       kho_radix_tree_walk_callback_t cb)
>  {
>  	unsigned long *bitmap = (unsigned long *)leaf;
> -	unsigned int order;
> -	phys_addr_t phys;
>  	unsigned int i;
>  	int err;
>  
>  	for_each_set_bit(i, bitmap, PAGE_SIZE * BITS_PER_BYTE) {
> -		phys = kho_radix_decode_key(key | i, &order);
> -		err = cb(phys, order);
> +		err = cb(key | i);
>  		if (err)
>  			return err;
>  	}
> @@ -332,15 +323,14 @@ static int __kho_radix_walk_tree(struct kho_radix_node *root,
>  }
>  
>  /**
> - * kho_radix_walk_tree - Traverses the radix tree and calls a callback for each preserved page.
> + * kho_radix_walk_tree - Traverses the radix tree and calls a callback for each key.
>   * @tree: A pointer to the KHO radix tree to walk.
>   * @cb: A callback function of type kho_radix_tree_walk_callback_t that will be
> - *      invoked for each preserved page found in the tree. The callback receives
> - *      the physical address and order of the preserved page.
> + *      invoked for each key in the tree.
>   *
>   * This function walks the radix tree, searching from the specified top level
> - * down to the lowest level (level 0). For each preserved page found, it invokes
> - * the provided callback, passing the page's physical address and order.
> + * down to the lowest level (level 0). For each key found, it invokes the
> + * provided callback.
>   *
>   * Return: 0 if the walk completed the specified tree, or the non-zero return
>   *         value from the callback that stopped the walk.
> @@ -365,7 +355,8 @@ static void __kho_unpreserve(struct kho_radix_tree *tree,
>  	while (pfn < end_pfn) {
>  		order = min(count_trailing_zeros(pfn), ilog2(end_pfn - pfn));
>  
> -		kho_radix_del_page(tree, pfn, order);
> +		kho_radix_del_key(tree, kho_encode_radix_key(PFN_PHYS(pfn),
> +							     order));
>  
>  		pfn += 1 << order;
>  	}
> @@ -498,13 +489,16 @@ static struct page *__init kho_get_preserved_page(phys_addr_t phys,
>  	return pfn_to_page(pfn);
>  }
>  
> -static int __init kho_preserved_memory_reserve(phys_addr_t phys,
> -					       unsigned int order)
> +static int __init kho_preserved_memory_reserve(unsigned long key)
>  {
>  	union kho_page_info info;
>  	struct page *page;
> +	unsigned int order;
> +	phys_addr_t phys;
>  	u64 sz;
>  
> +	phys = kho_decode_radix_key(key, &order);
> +
>  	sz = 1 << (order + PAGE_SHIFT);
>  	page = kho_get_preserved_page(phys, order);
>  
> @@ -858,7 +852,8 @@ int kho_preserve_folio(struct folio *folio)
>  	if (WARN_ON(kho_scratch_overlap(pfn << PAGE_SHIFT, PAGE_SIZE << order)))
>  		return -EINVAL;
>  
> -	return kho_radix_add_page(tree, pfn, order);
> +	return kho_radix_add_key(tree, kho_encode_radix_key(PFN_PHYS(pfn),
> +							    order));
>  }
>  EXPORT_SYMBOL_GPL(kho_preserve_folio);
>  
> @@ -876,7 +871,7 @@ void kho_unpreserve_folio(struct folio *folio)
>  	const unsigned long pfn = folio_pfn(folio);
>  	const unsigned int order = folio_order(folio);
>  
> -	kho_radix_del_page(tree, pfn, order);
> +	kho_radix_del_key(tree, kho_encode_radix_key(PFN_PHYS(pfn), order));
>  }
>  EXPORT_SYMBOL_GPL(kho_unpreserve_folio);
>  
> @@ -916,7 +911,8 @@ int kho_preserve_pages(struct page *page, unsigned long nr_pages)
>  		while (pfn_to_nid(pfn) != pfn_to_nid(pfn + (1UL << order) - 1))
>  			order--;
>  
> -		err = kho_radix_add_page(tree, pfn, order);
> +		err = kho_radix_add_key(tree, kho_encode_radix_key(PFN_PHYS(pfn),
> +								   order));
>  		if (err) {
>  			failed_pfn = pfn;
>  			break;
> -- 
> 2.54.0.545.g6539524ca2-goog
> 

Re: [PATCH 01/12] kho: generalize radix tree APIs

[Jork Loeser]

On Wed, 29 Apr 2026, Pratyush Yadav wrote:

> From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
>
> The KHO radix tree is a data structure that can track the presence or
> absence of an arbitrary key, with nothing inherently tied to KHO memory
> preservation tracking. This was one of the design goals of the radix
> tree. This was done to enable it to be re-used by other users of KHO.

"Arbitrary key": Not quite the complete 64-bits, rather 64 - PAGE_SIZE, 
correct?

> + * kho_radix_add_key - Add a key to the radix tree.
>  * @tree: The KHO radix tree.
> + * @key: The key to add.
>  *
> + * This function traverses the radix tree based on the key provided. It sets the
> + * corresponding bit in the leaf bitmap to mark the key as present. If
> + * intermediate nodes do not exist along the path, they are allocated and added
> + * to the tree.

Consider adding a note on the key-width limitation.

Best,
Jork

Re: [PATCH 01/12] kho: generalize radix tree APIs

[Pratyush Yadav]

On Tue, May 05 2026, Jork Loeser wrote:

> On Wed, 29 Apr 2026, Pratyush Yadav wrote:
>
>> From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
>>
>> The KHO radix tree is a data structure that can track the presence or
>> absence of an arbitrary key, with nothing inherently tied to KHO memory
>> preservation tracking. This was one of the design goals of the radix
>> tree. This was done to enable it to be re-used by other users of KHO.
>
> "Arbitrary key": Not quite the complete 64-bits, rather 64 - PAGE_SIZE, correct?

Right, 64 - PAGE_SHIFT.

>
>> + * kho_radix_add_key - Add a key to the radix tree.
>>  * @tree: The KHO radix tree.
>> + * @key: The key to add.
>>  *
>> + * This function traverses the radix tree based on the key provided. It sets the
>> + * corresponding bit in the leaf bitmap to mark the key as present. If
>> + * intermediate nodes do not exist along the path, they are allocated and added
>> + * to the tree.
>
> Consider adding a note on the key-width limitation.

I think adding a runtime check would also be a good idea here.

-- 
Regards,
Pratyush Yadav

Re: [PATCH 01/12] kho: generalize radix tree APIs

[Mike Rapoport]

On Wed, Apr 29, 2026 at 03:39:03PM +0200, Pratyush Yadav wrote:
> From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
> 
> The KHO radix tree is a data structure that can track the presence or
> absence of an arbitrary key, with nothing inherently tied to KHO memory
> preservation tracking. This was one of the design goals of the radix
> tree. This was done to enable it to be re-used by other users of KHO.
> 
> Despite that, the radix tree APIs are very closely tied to KHO memory
> preservation tracking. Adding a key is done by kho_radix_add_page(),
> which encodes it as a page tracking operation and takes in PFN and
> order. kho_radix_del_page() does the same. These functions encode the
> key internally that goes into the radix tree. kho_radix_walk_tree() does
> the same by baking the PFN and order into the callback arguments.
> 
> Generalize the APIs by taking the key directly and doing the encoding at
> the callers. Rename the functions to kho_radix_add_key() and
> kho_radix_del_key(). In practice, this removes a line each from the
> functions and moves the encoding function call to the callers.
> Similarly, update kho_radix_tree_walk_callback_t to take the key
> directly.
> 
> To keep the naming convention clearer, rename
> kho_radix_{encode,decode}_key() to kho_{encode,decode}_radix_key().
> 
> Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
> ---
>  include/linux/kho_radix_tree.h     | 18 +++----
>  kernel/liveupdate/kexec_handover.c | 76 ++++++++++++++----------------
>  2 files changed, 42 insertions(+), 52 deletions(-)
> 
> diff --git a/include/linux/kho_radix_tree.h b/include/linux/kho_radix_tree.h
> index 84e918b96e53..f368f3b9f923 100644
> --- a/include/linux/kho_radix_tree.h
> +++ b/include/linux/kho_radix_tree.h
> @@ -85,7 +85,7 @@ static struct kho_out kho_out = {
>  };
>  
>  /**
> - * kho_radix_encode_key - Encodes a physical address and order into a radix key.
> + * kho_encode_radix_key - Encodes a physical address and order into a radix key.

Let's keep kho_radix_ prefix for namespasing please.
This is the common practice these days.

>   * @phys: The physical address of the page.
>   * @order: The order of the page.
>   *

...

> @@ -144,24 +144,21 @@ static unsigned long kho_radix_get_table_index(unsigned long key,
>  }
>  
>  /**
> - * kho_radix_add_page - Marks a page as preserved in the radix tree.
> + * kho_radix_add_key - Add a key to the radix tree.
>   * @tree: The KHO radix tree.
> - * @pfn: The page frame number of the page to preserve.
> - * @order: The order of the page.
> + * @key: The key to add.
>   *
> - * This function traverses the radix tree based on the key derived from @pfn
> - * and @order. It sets the corresponding bit in the leaf bitmap to mark the
> - * page for preservation. If intermediate nodes do not exist along the path,
> - * they are allocated and added to the tree.
> + * This function traverses the radix tree based on the key provided. It sets the

Nit:                                                     @key here and in
the comments below.

> + * corresponding bit in the leaf bitmap to mark the key as present. If
> + * intermediate nodes do not exist along the path, they are allocated and added
> + * to the tree.
>   *
>   * Return: 0 on success, or a negative error code on failure.
>   */

-- 
Sincerely yours,
Mike.

Re: [PATCH 01/12] kho: generalize radix tree APIs

[Pratyush Yadav]

On Mon, May 11 2026, Mike Rapoport wrote:

> On Wed, Apr 29, 2026 at 03:39:03PM +0200, Pratyush Yadav wrote:
>> From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
>> 
>> The KHO radix tree is a data structure that can track the presence or
>> absence of an arbitrary key, with nothing inherently tied to KHO memory
>> preservation tracking. This was one of the design goals of the radix
>> tree. This was done to enable it to be re-used by other users of KHO.
>> 
>> Despite that, the radix tree APIs are very closely tied to KHO memory
>> preservation tracking. Adding a key is done by kho_radix_add_page(),
>> which encodes it as a page tracking operation and takes in PFN and
>> order. kho_radix_del_page() does the same. These functions encode the
>> key internally that goes into the radix tree. kho_radix_walk_tree() does
>> the same by baking the PFN and order into the callback arguments.
>> 
>> Generalize the APIs by taking the key directly and doing the encoding at
>> the callers. Rename the functions to kho_radix_add_key() and
>> kho_radix_del_key(). In practice, this removes a line each from the
>> functions and moves the encoding function call to the callers.
>> Similarly, update kho_radix_tree_walk_callback_t to take the key
>> directly.
>> 
>> To keep the naming convention clearer, rename
>> kho_radix_{encode,decode}_key() to kho_{encode,decode}_radix_key().
>> 
>> Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
>> ---
>>  include/linux/kho_radix_tree.h     | 18 +++----
>>  kernel/liveupdate/kexec_handover.c | 76 ++++++++++++++----------------
>>  2 files changed, 42 insertions(+), 52 deletions(-)
>> 
>> diff --git a/include/linux/kho_radix_tree.h b/include/linux/kho_radix_tree.h
>> index 84e918b96e53..f368f3b9f923 100644
>> --- a/include/linux/kho_radix_tree.h
>> +++ b/include/linux/kho_radix_tree.h
>> @@ -85,7 +85,7 @@ static struct kho_out kho_out = {
>>  };
>>  
>>  /**
>> - * kho_radix_encode_key - Encodes a physical address and order into a radix key.
>> + * kho_encode_radix_key - Encodes a physical address and order into a radix key.
>
> Let's keep kho_radix_ prefix for namespasing please.
> This is the common practice these days.

I am keeping the namespacing, just moving it out of the "kho_radix"
namespace to "kho" namespace. The mental model is that this function has
nothing to do with the radix tree. It is just something KHO uses for one
of its radix tree, so it should live in the "kho" namespace not
"kho_radix".

Does that make sense? I can add this explanation to the commit message
as well.

>
>>   * @phys: The physical address of the page.
>>   * @order: The order of the page.
>>   *
>
> ...
>
>> @@ -144,24 +144,21 @@ static unsigned long kho_radix_get_table_index(unsigned long key,
>>  }
>>  
>>  /**
>> - * kho_radix_add_page - Marks a page as preserved in the radix tree.
>> + * kho_radix_add_key - Add a key to the radix tree.
>>   * @tree: The KHO radix tree.
>> - * @pfn: The page frame number of the page to preserve.
>> - * @order: The order of the page.
>> + * @key: The key to add.
>>   *
>> - * This function traverses the radix tree based on the key derived from @pfn
>> - * and @order. It sets the corresponding bit in the leaf bitmap to mark the
>> - * page for preservation. If intermediate nodes do not exist along the path,
>> - * they are allocated and added to the tree.
>> + * This function traverses the radix tree based on the key provided. It sets the
>
> Nit:                                                     @key here and in
> the comments below.

ACK.

>
>> + * corresponding bit in the leaf bitmap to mark the key as present. If
>> + * intermediate nodes do not exist along the path, they are allocated and added
>> + * to the tree.
>>   *
>>   * Return: 0 on success, or a negative error code on failure.
>>   */

-- 
Regards,
Pratyush Yadav

Re: [PATCH 08/12] kho: add kho_radix_init_tree()

[Jork Loeser]

On Wed, 29 Apr 2026, Pratyush Yadav wrote:

> From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
>
> Move the initialization logic of the radix tree into
> kho_radix_init_tree() instead of having users open-code it. Makes the
> boundaries cleaner and reduces code duplication when a new user of the
> radix tree will be added in a future commit.

Consider using kho_radix_init_tree() in kho_init() as well. This will also 
remove the kzalloc() one-off use. Similar for kho_radix_destroy_tree().

Best,
Jork

Re: [PATCH 08/12] kho: add kho_radix_init_tree()

[Pratyush Yadav]

On Wed, May 06 2026, Jork Loeser wrote:

> On Wed, 29 Apr 2026, Pratyush Yadav wrote:
>
>> From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
>>
>> Move the initialization logic of the radix tree into
>> kho_radix_init_tree() instead of having users open-code it. Makes the
>> boundaries cleaner and reduces code duplication when a new user of the
>> radix tree will be added in a future commit.
>
> Consider using kho_radix_init_tree() in kho_init() as well. This will also
> remove the kzalloc() one-off use. Similar for kho_radix_destroy_tree().

Good point. Will do.

-- 
Regards,
Pratyush Yadav

Re: [PATCH 02/12] kho: store incoming radix tree in kho_in

[Mike Rapoport]

On Wed, Apr 29, 2026 at 03:39:04PM +0200, Pratyush Yadav wrote:
> From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
> 
> This allows other functions to also use the radix tree. While at it,
> also use kho_get_mem_map_phys() instead of duplicating the code to get
> the radix tree root from the FDT.
> 
> Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
> ---
>  kernel/liveupdate/kexec_handover.c | 27 ++++++++-------------------
>  1 file changed, 8 insertions(+), 19 deletions(-)
> 
> diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
> index ba568d34c5b4..5758dc6fab5d 100644
> --- a/kernel/liveupdate/kexec_handover.c
> +++ b/kernel/liveupdate/kexec_handover.c
> @@ -1294,6 +1294,7 @@ struct kho_in {
>  	char previous_release[__NEW_UTS_LEN + 1];
>  	u32 kexec_count;
>  	struct kho_debugfs dbg;
> +	struct kho_radix_tree radix_tree;
>  };
>  
>  static struct kho_in kho_in = {
> @@ -1373,24 +1374,10 @@ EXPORT_SYMBOL_GPL(kho_retrieve_subtree);
>  
>  static int __init kho_mem_retrieve(const void *fdt)
>  {
> -	struct kho_radix_tree tree;
> -	const phys_addr_t *mem;
> -	int len;
> -
> -	/* Retrieve the KHO radix tree from passed-in FDT. */
> -	mem = fdt_getprop(fdt, 0, KHO_FDT_MEMORY_MAP_PROP_NAME, &len);
> -
> -	if (!mem || len != sizeof(*mem)) {
> -		pr_err("failed to get preserved KHO memory tree\n");
> -		return -ENOENT;
> -	}
> -
> -	if (!*mem)
> -		return -EINVAL;
> -
> -	tree.root = phys_to_virt(*mem);
> -	mutex_init(&tree.lock);
> -	return kho_radix_walk_tree(&tree, kho_preserved_memory_reserve);
> +	kho_in.radix_tree.root = phys_to_virt(kho_get_mem_map_phys(fdt));

Do we really want to remove an explicit check for 0 and get a WARN() in
kho_radix_walk_tree()?

> +	mutex_init(&kho_in.radix_tree.lock);
> +	return kho_radix_walk_tree(&kho_in.radix_tree,
> +				   kho_preserved_memory_reserve);
>  }
>  
>  static __init int kho_out_fdt_setup(void)
> @@ -1597,8 +1584,10 @@ void __init kho_memory_init(void)
>  	if (kho_in.scratch_phys) {
>  		kho_scratch = phys_to_virt(kho_in.scratch_phys);
>  
> -		if (kho_mem_retrieve(kho_get_fdt()))
> +		if (kho_mem_retrieve(kho_get_fdt())) {
>  			kho_in.fdt_phys = 0;
> +			kho_in.radix_tree.root = NULL;

I'd make kho_mem_retrieve() void and put these there.

> +		}
>  	} else {
>  		kho_reserve_scratch();
>  	}
> -- 
> 2.54.0.545.g6539524ca2-goog
> 

-- 
Sincerely yours,
Mike.

Re: [PATCH 02/12] kho: store incoming radix tree in kho_in

[Pratyush Yadav]

On Mon, May 11 2026, Mike Rapoport wrote:

> On Wed, Apr 29, 2026 at 03:39:04PM +0200, Pratyush Yadav wrote:
>> From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
>> 
>> This allows other functions to also use the radix tree. While at it,
>> also use kho_get_mem_map_phys() instead of duplicating the code to get
>> the radix tree root from the FDT.
>> 
>> Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
>> ---
>>  kernel/liveupdate/kexec_handover.c | 27 ++++++++-------------------
>>  1 file changed, 8 insertions(+), 19 deletions(-)
>> 
>> diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
>> index ba568d34c5b4..5758dc6fab5d 100644
>> --- a/kernel/liveupdate/kexec_handover.c
>> +++ b/kernel/liveupdate/kexec_handover.c
>> @@ -1294,6 +1294,7 @@ struct kho_in {
>>  	char previous_release[__NEW_UTS_LEN + 1];
>>  	u32 kexec_count;
>>  	struct kho_debugfs dbg;
>> +	struct kho_radix_tree radix_tree;
>>  };
>>  
>>  static struct kho_in kho_in = {
>> @@ -1373,24 +1374,10 @@ EXPORT_SYMBOL_GPL(kho_retrieve_subtree);
>>  
>>  static int __init kho_mem_retrieve(const void *fdt)
>>  {
>> -	struct kho_radix_tree tree;
>> -	const phys_addr_t *mem;
>> -	int len;
>> -
>> -	/* Retrieve the KHO radix tree from passed-in FDT. */
>> -	mem = fdt_getprop(fdt, 0, KHO_FDT_MEMORY_MAP_PROP_NAME, &len);
>> -
>> -	if (!mem || len != sizeof(*mem)) {
>> -		pr_err("failed to get preserved KHO memory tree\n");
>> -		return -ENOENT;
>> -	}
>> -
>> -	if (!*mem)
>> -		return -EINVAL;
>> -
>> -	tree.root = phys_to_virt(*mem);
>> -	mutex_init(&tree.lock);
>> -	return kho_radix_walk_tree(&tree, kho_preserved_memory_reserve);
>> +	kho_in.radix_tree.root = phys_to_virt(kho_get_mem_map_phys(fdt));
>
> Do we really want to remove an explicit check for 0 and get a WARN() in
> kho_radix_walk_tree()?

If mem_map_phys is 0 then kho_populate() never sets kho_in.scratch_phys
and thus kho_mem_retrieve() never gets called. So here it will never be
0, and if it is, a WARN() is certainly warranted.

Perhaps I should add a comment since this isn't so obvious?

>
>> +	mutex_init(&kho_in.radix_tree.lock);
>> +	return kho_radix_walk_tree(&kho_in.radix_tree,
>> +				   kho_preserved_memory_reserve);
>>  }
>>  
>>  static __init int kho_out_fdt_setup(void)
>> @@ -1597,8 +1584,10 @@ void __init kho_memory_init(void)
>>  	if (kho_in.scratch_phys) {
>>  		kho_scratch = phys_to_virt(kho_in.scratch_phys);
>>  
>> -		if (kho_mem_retrieve(kho_get_fdt()))
>> +		if (kho_mem_retrieve(kho_get_fdt())) {
>>  			kho_in.fdt_phys = 0;
>> +			kho_in.radix_tree.root = NULL;
>
> I'd make kho_mem_retrieve() void and put these there.

Sure, will do.

>
>> +		}
>>  	} else {
>>  		kho_reserve_scratch();
>>  	}
>> -- 
>> 2.54.0.545.g6539524ca2-goog
>> 

-- 
Regards,
Pratyush Yadav

Re: [PATCH 02/12] kho: store incoming radix tree in kho_in

[Mike Rapoport]

On Mon, May 11, 2026 at 06:28:21PM +0200, Pratyush Yadav wrote:
> On Mon, May 11 2026, Mike Rapoport wrote:
> 
> > On Wed, Apr 29, 2026 at 03:39:04PM +0200, Pratyush Yadav wrote:
> >> From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
> >> 
> >> This allows other functions to also use the radix tree. While at it,
> >> also use kho_get_mem_map_phys() instead of duplicating the code to get
> >> the radix tree root from the FDT.
> >> 
> >> Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
> >> ---
> >>  kernel/liveupdate/kexec_handover.c | 27 ++++++++-------------------
> >>  1 file changed, 8 insertions(+), 19 deletions(-)
> >> 
> >> diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
> >> index ba568d34c5b4..5758dc6fab5d 100644
> >> --- a/kernel/liveupdate/kexec_handover.c
> >> +++ b/kernel/liveupdate/kexec_handover.c
> >> @@ -1294,6 +1294,7 @@ struct kho_in {
> >>  	char previous_release[__NEW_UTS_LEN + 1];
> >>  	u32 kexec_count;
> >>  	struct kho_debugfs dbg;
> >> +	struct kho_radix_tree radix_tree;
> >>  };
> >>  
> >>  static struct kho_in kho_in = {
> >> @@ -1373,24 +1374,10 @@ EXPORT_SYMBOL_GPL(kho_retrieve_subtree);
> >>  
> >>  static int __init kho_mem_retrieve(const void *fdt)
> >>  {
> >> -	struct kho_radix_tree tree;
> >> -	const phys_addr_t *mem;
> >> -	int len;
> >> -
> >> -	/* Retrieve the KHO radix tree from passed-in FDT. */
> >> -	mem = fdt_getprop(fdt, 0, KHO_FDT_MEMORY_MAP_PROP_NAME, &len);
> >> -
> >> -	if (!mem || len != sizeof(*mem)) {
> >> -		pr_err("failed to get preserved KHO memory tree\n");
> >> -		return -ENOENT;
> >> -	}
> >> -
> >> -	if (!*mem)
> >> -		return -EINVAL;
> >> -
> >> -	tree.root = phys_to_virt(*mem);
> >> -	mutex_init(&tree.lock);
> >> -	return kho_radix_walk_tree(&tree, kho_preserved_memory_reserve);
> >> +	kho_in.radix_tree.root = phys_to_virt(kho_get_mem_map_phys(fdt));
> >
> > Do we really want to remove an explicit check for 0 and get a WARN() in
> > kho_radix_walk_tree()?
> 
> If mem_map_phys is 0 then kho_populate() never sets kho_in.scratch_phys
> and thus kho_mem_retrieve() never gets called. So here it will never be
> 0, and if it is, a WARN() is certainly warranted.
> 
> Perhaps I should add a comment since this isn't so obvious?

Yes, please.
After a few weeks it will be completely obscure.
 
> >
> >> +	mutex_init(&kho_in.radix_tree.lock);
> >> +	return kho_radix_walk_tree(&kho_in.radix_tree,
> >> +				   kho_preserved_memory_reserve);
> >>  }
> >>  
> >>  static __init int kho_out_fdt_setup(void)
> >> @@ -1597,8 +1584,10 @@ void __init kho_memory_init(void)
> >>  	if (kho_in.scratch_phys) {
> >>  		kho_scratch = phys_to_virt(kho_in.scratch_phys);
> >>  
> >> -		if (kho_mem_retrieve(kho_get_fdt()))
> >> +		if (kho_mem_retrieve(kho_get_fdt())) {
> >>  			kho_in.fdt_phys = 0;
> >> +			kho_in.radix_tree.root = NULL;
> >
> > I'd make kho_mem_retrieve() void and put these there.
> 
> Sure, will do.
> 
> >
> >> +		}
> >>  	} else {
> >>  		kho_reserve_scratch();
> >>  	}
> >> -- 
> >> 2.54.0.545.g6539524ca2-goog
> >> 
> 
> -- 
> Regards,
> Pratyush Yadav

-- 
Sincerely yours,
Mike.

Re: [PATCH 03/12] kho: add a struct for radix callbacks

[Mike Rapoport]

On Wed, Apr 29, 2026 at 03:39:05PM +0200, Pratyush Yadav wrote:
> From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
> 
> A future commit will add more callbacks for the KHO radix tree. Add a
> struct for collecting the callbacks.
> 
> Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
> ---
>  include/linux/kho_radix_tree.h     | 15 ++++++++++++---
>  kernel/liveupdate/kexec_handover.c | 29 ++++++++++++++++-------------
>  2 files changed, 28 insertions(+), 16 deletions(-)
> 
> diff --git a/include/linux/kho_radix_tree.h b/include/linux/kho_radix_tree.h
> index f368f3b9f923..030da6399d28 100644
> --- a/include/linux/kho_radix_tree.h
> +++ b/include/linux/kho_radix_tree.h
> @@ -34,14 +34,23 @@ struct kho_radix_tree {
>  	struct mutex lock; /* protects the tree's structure and root pointer */
>  };
>  
> -typedef int (*kho_radix_tree_walk_callback_t)(unsigned long key);
> +/**
> + * struct kho_radix_walk_cb - Callbacks for KHO radix tree walk.
> + * @key:      Called on each present key in the radix tree.
> + *
> + * For each callback, a return value of 0 continues the walk and a non-zero
> + * return value is directly returned to the caller.
> + */
> +struct kho_radix_walk_cb {
> +	int (*key)(unsigned long key);
> +};
>  
>  #ifdef CONFIG_KEXEC_HANDOVER
>  
>  int kho_radix_add_key(struct kho_radix_tree *tree, unsigned long key);
>  void kho_radix_del_key(struct kho_radix_tree *tree, unsigned long key);
>  int kho_radix_walk_tree(struct kho_radix_tree *tree,
> -			kho_radix_tree_walk_callback_t cb);
> +			const struct kho_radix_walk_cb *cb);
>  
>  #else  /* #ifdef CONFIG_KEXEC_HANDOVER */
>  
> @@ -54,7 +63,7 @@ static inline void kho_radix_del_key(struct kho_radix_tree *tree,
>  				     unsigned long key) { }
>  
>  static inline int kho_radix_walk_tree(struct kho_radix_tree *tree,
> -				      kho_radix_tree_walk_callback_t cb)
> +				      const struct kho_radix_walk_cb *cb)
>  {
>  	return -EOPNOTSUPP;
>  }
> diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
> index 5758dc6fab5d..4a5d1b47799c 100644
> --- a/kernel/liveupdate/kexec_handover.c
> +++ b/kernel/liveupdate/kexec_handover.c
> @@ -266,16 +266,18 @@ void kho_radix_del_key(struct kho_radix_tree *tree, unsigned long key)
>  }
>  EXPORT_SYMBOL_GPL(kho_radix_del_key);
>  
> -static int kho_radix_walk_leaf(struct kho_radix_leaf *leaf,
> -			       unsigned long key,
> -			       kho_radix_tree_walk_callback_t cb)
> +static int kho_radix_walk_leaf(struct kho_radix_leaf *leaf, unsigned long key,
> +			       const struct kho_radix_walk_cb *cb)
>  {
>  	unsigned long *bitmap = (unsigned long *)leaf;
>  	unsigned int i;
>  	int err;
>  
> +	if (!cb->key)
> +		return 0;
> +
>  	for_each_set_bit(i, bitmap, PAGE_SIZE * BITS_PER_BYTE) {
> -		err = cb(key | i);
> +		err = cb->key(key | i);

key(key) reads weird :)
Can't say I have a good name, maybe key_action()?

>  		if (err)
>  			return err;
>  	}

-- 
Sincerely yours,
Mike.

Re: [PATCH 03/12] kho: add a struct for radix callbacks

[Pratyush Yadav]

On Mon, May 11 2026, Mike Rapoport wrote:

> On Wed, Apr 29, 2026 at 03:39:05PM +0200, Pratyush Yadav wrote:
>> From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
>> 
>> A future commit will add more callbacks for the KHO radix tree. Add a
>> struct for collecting the callbacks.
>> 
>> Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
>> ---
[...]
>> --- a/kernel/liveupdate/kexec_handover.c
>> +++ b/kernel/liveupdate/kexec_handover.c
>> @@ -266,16 +266,18 @@ void kho_radix_del_key(struct kho_radix_tree *tree, unsigned long key)
>>  }
>>  EXPORT_SYMBOL_GPL(kho_radix_del_key);
>>  
>> -static int kho_radix_walk_leaf(struct kho_radix_leaf *leaf,
>> -			       unsigned long key,
>> -			       kho_radix_tree_walk_callback_t cb)
>> +static int kho_radix_walk_leaf(struct kho_radix_leaf *leaf, unsigned long key,
>> +			       const struct kho_radix_walk_cb *cb)
>>  {
>>  	unsigned long *bitmap = (unsigned long *)leaf;
>>  	unsigned int i;
>>  	int err;
>>  
>> +	if (!cb->key)
>> +		return 0;
>> +
>>  	for_each_set_bit(i, bitmap, PAGE_SIZE * BITS_PER_BYTE) {
>> -		err = cb(key | i);
>> +		err = cb->key(key | i);
>
> key(key) reads weird :)
> Can't say I have a good name, maybe key_action()?

I thought the context of it being under a callback struct would make it
more obvious. I don't like key_action() much better TBH, but I don't
have a strong opinion. Perhaps Pasha can suggest a 3rd option and we
pick on randomly ;-)

>
>>  		if (err)
>>  			return err;
>>  	}

-- 
Regards,
Pratyush Yadav

Re: [PATCH 03/12] kho: add a struct for radix callbacks

[Mike Rapoport]

On Mon, May 11, 2026 at 06:35:54PM +0200, Pratyush Yadav wrote:
> On Mon, May 11 2026, Mike Rapoport wrote:
> 
> > On Wed, Apr 29, 2026 at 03:39:05PM +0200, Pratyush Yadav wrote:
> >> From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
> >> 
> >> A future commit will add more callbacks for the KHO radix tree. Add a
> >> struct for collecting the callbacks.
> >> 
> >> Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
> >> ---
> [...]
> >> --- a/kernel/liveupdate/kexec_handover.c
> >> +++ b/kernel/liveupdate/kexec_handover.c
> >> @@ -266,16 +266,18 @@ void kho_radix_del_key(struct kho_radix_tree *tree, unsigned long key)
> >>  }
> >>  EXPORT_SYMBOL_GPL(kho_radix_del_key);
> >>  
> >> -static int kho_radix_walk_leaf(struct kho_radix_leaf *leaf,
> >> -			       unsigned long key,
> >> -			       kho_radix_tree_walk_callback_t cb)
> >> +static int kho_radix_walk_leaf(struct kho_radix_leaf *leaf, unsigned long key,
> >> +			       const struct kho_radix_walk_cb *cb)
> >>  {
> >>  	unsigned long *bitmap = (unsigned long *)leaf;
> >>  	unsigned int i;
> >>  	int err;
> >>  
> >> +	if (!cb->key)
> >> +		return 0;
> >> +
> >>  	for_each_set_bit(i, bitmap, PAGE_SIZE * BITS_PER_BYTE) {
> >> -		err = cb(key | i);
> >> +		err = cb->key(key | i);
> >
> > key(key) reads weird :)
> > Can't say I have a good name, maybe key_action()?
> 
> I thought the context of it being under a callback struct would make it
> more obvious. I don't like key_action() much better TBH, but I don't
> have a strong opinion. Perhaps Pasha can suggest a 3rd option and we
> pick on randomly ;-)

Another option I thought is to call them ->leaf() and ->node().
 
> >
> >>  		if (err)
> >>  			return err;
> >>  	}
> 
> -- 
> Regards,
> Pratyush Yadav

-- 
Sincerely yours,
Mike.

Re: [PATCH 03/12] kho: add a struct for radix callbacks

[Pratyush Yadav]

On Tue, May 12 2026, Mike Rapoport wrote:

> On Mon, May 11, 2026 at 06:35:54PM +0200, Pratyush Yadav wrote:
>> On Mon, May 11 2026, Mike Rapoport wrote:
>> 
>> > On Wed, Apr 29, 2026 at 03:39:05PM +0200, Pratyush Yadav wrote:
>> >> From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
>> >> 
>> >> A future commit will add more callbacks for the KHO radix tree. Add a
>> >> struct for collecting the callbacks.
>> >> 
>> >> Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
>> >> ---
>> [...]
>> >> --- a/kernel/liveupdate/kexec_handover.c
>> >> +++ b/kernel/liveupdate/kexec_handover.c
>> >> @@ -266,16 +266,18 @@ void kho_radix_del_key(struct kho_radix_tree *tree, unsigned long key)
>> >>  }
>> >>  EXPORT_SYMBOL_GPL(kho_radix_del_key);
>> >>  
>> >> -static int kho_radix_walk_leaf(struct kho_radix_leaf *leaf,
>> >> -			       unsigned long key,
>> >> -			       kho_radix_tree_walk_callback_t cb)
>> >> +static int kho_radix_walk_leaf(struct kho_radix_leaf *leaf, unsigned long key,
>> >> +			       const struct kho_radix_walk_cb *cb)
>> >>  {
>> >>  	unsigned long *bitmap = (unsigned long *)leaf;
>> >>  	unsigned int i;
>> >>  	int err;
>> >>  
>> >> +	if (!cb->key)
>> >> +		return 0;
>> >> +
>> >>  	for_each_set_bit(i, bitmap, PAGE_SIZE * BITS_PER_BYTE) {
>> >> -		err = cb(key | i);
>> >> +		err = cb->key(key | i);
>> >
>> > key(key) reads weird :)
>> > Can't say I have a good name, maybe key_action()?
>> 
>> I thought the context of it being under a callback struct would make it
>> more obvious. I don't like key_action() much better TBH, but I don't
>> have a strong opinion. Perhaps Pasha can suggest a 3rd option and we
>> pick on randomly ;-)
>
> Another option I thought is to call them ->leaf() and ->node().

This one sounds nice. Will use it in v2.

-- 
Regards,
Pratyush Yadav

Re: [PATCH 04/12] kho: add callback for table pages

[Mike Rapoport]

On Wed, Apr 29, 2026 at 03:39:06PM +0200, Pratyush Yadav wrote:
> From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
> 
> The KHO memory preservation radix tree does not mark the table pages
> themselves as scratch. This is done to avoid a circular dependency where
> preserving a page can lead of allocating other preserved pages. This
> means any walker looking for free ranges of memory outside of scratch
> areas will ignore the table
> 
> Add a table callback that is invoked for each table page. The callback

A sentence why a table callback helps would be nice here :)

> is given the physical address of the table page.
> 
> Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
> ---
>  include/linux/kho_radix_tree.h     |  3 +++
>  kernel/liveupdate/kexec_handover.c | 12 ++++++++++++
>  2 files changed, 15 insertions(+)
> 
> diff --git a/include/linux/kho_radix_tree.h b/include/linux/kho_radix_tree.h
> index 030da6399d28..fe7151d89361 100644
> --- a/include/linux/kho_radix_tree.h
> +++ b/include/linux/kho_radix_tree.h
> @@ -37,12 +37,15 @@ struct kho_radix_tree {
>  /**
>   * struct kho_radix_walk_cb - Callbacks for KHO radix tree walk.
>   * @key:      Called on each present key in the radix tree.
> + * @table:    Called on each table of the radix tree itself. Receives the
> + *            physical address of the page containing the table.
>   *
>   * For each callback, a return value of 0 continues the walk and a non-zero
>   * return value is directly returned to the caller.
>   */
>  struct kho_radix_walk_cb {
>  	int (*key)(unsigned long key);
> +	int (*table)(phys_addr_t phys);

Naming is hard ;-)

>  };
>  

-- 
Sincerely yours,
Mike.

Re: [PATCH 04/12] kho: add callback for table pages

[Pratyush Yadav]

On Mon, May 11 2026, Mike Rapoport wrote:

> On Wed, Apr 29, 2026 at 03:39:06PM +0200, Pratyush Yadav wrote:
>> From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
>> 
>> The KHO memory preservation radix tree does not mark the table pages
>> themselves as scratch. This is done to avoid a circular dependency where
>> preserving a page can lead of allocating other preserved pages. This
>> means any walker looking for free ranges of memory outside of scratch
>> areas will ignore the table
>> 
>> Add a table callback that is invoked for each table page. The callback
>
> A sentence why a table callback helps would be nice here :)

The main reason is that a later patch will create a radix tree for short
use and will need to destroy it afterwards.

Will add that here.

>
>> is given the physical address of the table page.
>> 
>> Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
>> ---
>>  include/linux/kho_radix_tree.h     |  3 +++
>>  kernel/liveupdate/kexec_handover.c | 12 ++++++++++++
>>  2 files changed, 15 insertions(+)
>> 
>> diff --git a/include/linux/kho_radix_tree.h b/include/linux/kho_radix_tree.h
>> index 030da6399d28..fe7151d89361 100644
>> --- a/include/linux/kho_radix_tree.h
>> +++ b/include/linux/kho_radix_tree.h
>> @@ -37,12 +37,15 @@ struct kho_radix_tree {
>>  /**
>>   * struct kho_radix_walk_cb - Callbacks for KHO radix tree walk.
>>   * @key:      Called on each present key in the radix tree.
>> + * @table:    Called on each table of the radix tree itself. Receives the
>> + *            physical address of the page containing the table.
>>   *
>>   * For each callback, a return value of 0 continues the walk and a non-zero
>>   * return value is directly returned to the caller.
>>   */
>>  struct kho_radix_walk_cb {
>>  	int (*key)(unsigned long key);
>> +	int (*table)(phys_addr_t phys);
>
> Naming is hard ;-)

Yes :-/

>
>>  };
>>  

-- 
Regards,
Pratyush Yadav

Re: [PATCH 04/12] kho: add callback for table pages

[Pratyush Yadav]

On Mon, May 11 2026, Pratyush Yadav wrote:

> On Mon, May 11 2026, Mike Rapoport wrote:
>
>> On Wed, Apr 29, 2026 at 03:39:06PM +0200, Pratyush Yadav wrote:
>>> From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
>>> 
>>> The KHO memory preservation radix tree does not mark the table pages
>>> themselves as scratch. This is done to avoid a circular dependency where
>>> preserving a page can lead of allocating other preserved pages. This
>>> means any walker looking for free ranges of memory outside of scratch
>>> areas will ignore the table
>>> 
>>> Add a table callback that is invoked for each table page. The callback
>>
>> A sentence why a table callback helps would be nice here :)
>
> The main reason is that a later patch will create a radix tree for short
> use and will need to destroy it afterwards.

This was meant for patch 7.

The reason for this one is that kho_extend_scratch() needs to exclude
table pages from its free ranges. Will add it.

>
> Will add that here.
>
>>
>>> is given the physical address of the table page.
>>> 
>>> Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>

-- 
Regards,
Pratyush Yadav

Re: [PATCH 05/12] kho: add data argument to radix walk callback

[Mike Rapoport]

On Wed, Apr 29, 2026 at 03:39:07PM +0200, Pratyush Yadav wrote:
> From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
> 
> Add an opaque data pointer argument to kho_radix_walk_cb_t. This can be
> used for callers to pass extra information to the callback.

Nit:  ^by IMHO
 
> Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
> ---
>  include/linux/kho_radix_tree.h     |  8 ++++----
>  kernel/liveupdate/kexec_handover.c | 24 +++++++++++++-----------
>  2 files changed, 17 insertions(+), 15 deletions(-)
> 

-- 
Sincerely yours,
Mike.

Re: [PATCH 05/12] kho: add data argument to radix walk callback

[Pratyush Yadav]

On Mon, May 11 2026, Mike Rapoport wrote:

> On Wed, Apr 29, 2026 at 03:39:07PM +0200, Pratyush Yadav wrote:
>> From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
>> 
>> Add an opaque data pointer argument to kho_radix_walk_cb_t. This can be
>> used for callers to pass extra information to the callback.
>
> Nit:  ^by IMHO

ACK, makes sense.

-- 
Regards,
Pratyush Yadav

Re: [PATCH 06/12] kho: allow early-boot usage of the KHO radix tree

[Mike Rapoport]

On Wed, Apr 29, 2026 at 03:39:08PM +0200, Pratyush Yadav wrote:
> From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
> 
> The KHO radix tree allocates memory for table pages from the buddy
> allocator using get_zeroed_page(). This is not available in early boot
> when memblock is still active.
> 
> Using the radix tree in early boot is useful for KHO to track metadata
> about its memory. One such example is for tracking free blocks for
> memory allocation when scratch runs out of space. This feature will be
> added in the following commits.
> 
> Add kho_radix_{alloc,free}_node() which allocate and free the table
> pages. They use slab_is_available() to decide which allocator to use.
> While slab_is_available() indicates availability of the slab allocator,
> it gets initialized right before buddy so it serves the same practical

                           ^ after?

> purpose.
> 
> Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
> ---
>  kernel/liveupdate/kexec_handover.c | 24 ++++++++++++++++++++++--
>  1 file changed, 22 insertions(+), 2 deletions(-)

-- 
Sincerely yours,
Mike.

Re: [PATCH 06/12] kho: allow early-boot usage of the KHO radix tree

[Pratyush Yadav]

On Mon, May 11 2026, Mike Rapoport wrote:

> On Wed, Apr 29, 2026 at 03:39:08PM +0200, Pratyush Yadav wrote:
>> From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
>> 
>> The KHO radix tree allocates memory for table pages from the buddy
>> allocator using get_zeroed_page(). This is not available in early boot
>> when memblock is still active.
>> 
>> Using the radix tree in early boot is useful for KHO to track metadata
>> about its memory. One such example is for tracking free blocks for
>> memory allocation when scratch runs out of space. This feature will be
>> added in the following commits.
>> 
>> Add kho_radix_{alloc,free}_node() which allocate and free the table
>> pages. They use slab_is_available() to decide which allocator to use.
>> While slab_is_available() indicates availability of the slab allocator,
>> it gets initialized right before buddy so it serves the same practical
>
>                            ^ after?

ACK, will fix.

>
>> purpose.
>> 
>> Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
>> ---
>>  kernel/liveupdate/kexec_handover.c | 24 ++++++++++++++++++++++--
>>  1 file changed, 22 insertions(+), 2 deletions(-)

-- 
Regards,
Pratyush Yadav

Re: [PATCH 07/12] kho: allow destroying KHO radix tree

[Mike Rapoport]

On Wed, Apr 29, 2026 at 03:39:09PM +0200, Pratyush Yadav wrote:
> From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
> 
> Add kho_radix_destroy_tree() which allows destroying the radix tree and
> freeing all its pages.

A sentence why it Will be useful would be nice.
 
> Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
> ---
>  include/linux/kho_radix_tree.h     |  3 +++
>  kernel/liveupdate/kexec_handover.c | 34 ++++++++++++++++++++++++++++++
>  2 files changed, 37 insertions(+)

-- 
Sincerely yours,
Mike.

Re: [PATCH 09/12] memblock: introduce MEMBLOCK_KHO_SCRATCH_EXT

[Mike Rapoport]

On Wed, Apr 29, 2026 at 03:39:11PM +0200, Pratyush Yadav wrote:
> From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
> 
> In the upcoming commits, the KHO will learn how to discover free blocks
> of memory by walking the KHO radix tree. It will then mark those regions
> as scratch to allow memory allocation in case scratch runs low.
> 
> To differentiate the extended scratch areas from the main scratch areas,
> introduce MEMBLOCK_KHO_SCRATCH_EXT. Use it when choosing memblock flags
> for allocations during scratch-only. Teach should_skip_region() to check
> for both flags before deciding if the region should be skipped.

Why there's a need to differentiate SCRATCH and SCRATCH_EXT?
SCRATCH (I still hate the name) means "memory memblock can safely use for
the allocations". Initially this memory comes from the reservations in the
first kernel, but if the second kernel can find more memory to extend it,
why that additional memory should be treated differently? 

> Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
> ---
> 
> Notes:
>     Checkpatch complains about no space after MEMBLOCK_KHO_SCRATCH_EXT in
>     the declaration, but doing so makes it nicely align with all the other
>     numbers. Mike, if you'd like I can add some whitespace.
> 
>  include/linux/memblock.h | 10 ++++++++++
>  mm/memblock.c            | 41 ++++++++++++++++++++++++++++++++++------
>  2 files changed, 45 insertions(+), 6 deletions(-)
 
-- 
Sincerely yours,
Mike.

Re: [PATCH 09/12] memblock: introduce MEMBLOCK_KHO_SCRATCH_EXT

[Pratyush Yadav]

On Mon, May 11 2026, Mike Rapoport wrote:

> On Wed, Apr 29, 2026 at 03:39:11PM +0200, Pratyush Yadav wrote:
>> From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
>> 
>> In the upcoming commits, the KHO will learn how to discover free blocks
>> of memory by walking the KHO radix tree. It will then mark those regions
>> as scratch to allow memory allocation in case scratch runs low.
>> 
>> To differentiate the extended scratch areas from the main scratch areas,
>> introduce MEMBLOCK_KHO_SCRATCH_EXT. Use it when choosing memblock flags
>> for allocations during scratch-only. Teach should_skip_region() to check
>> for both flags before deciding if the region should be skipped.
>
> Why there's a need to differentiate SCRATCH and SCRATCH_EXT?
> SCRATCH (I still hate the name) means "memory memblock can safely use for
> the allocations". Initially this memory comes from the reservations in the
> first kernel, but if the second kernel can find more memory to extend it,
> why that additional memory should be treated differently? 

Two reasons:

1. We mark SCRATCH as MIGRATE_CMA. We don't want to do that for
   SCRATCH_EXT since this memory can be used for non-movable
   allocations.

2. Gigantic (1G) huge pages can not be allocated from scratch. They can
   be preserved memory and thus should not be allocated from SCRATCH.
   See patch 12 that does allocations for gigantic huge pages only from
   SCRATCH_EXT.

I will add this in the commit message for the next version.

Naming is hard, so if you have any better names I'm all ears :-)

>
>> Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
>> ---
>> 
>> Notes:
>>     Checkpatch complains about no space after MEMBLOCK_KHO_SCRATCH_EXT in
>>     the declaration, but doing so makes it nicely align with all the other
>>     numbers. Mike, if you'd like I can add some whitespace.
>> 
>>  include/linux/memblock.h | 10 ++++++++++
>>  mm/memblock.c            | 41 ++++++++++++++++++++++++++++++++++------
>>  2 files changed, 45 insertions(+), 6 deletions(-)

-- 
Regards,
Pratyush Yadav

Re: [PATCH 11/12] kho: return virtual address of mem_map

[Mike Rapoport]

On Wed, Apr 29, 2026 at 03:39:13PM +0200, Pratyush Yadav wrote:
> From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
> 
> There are currently 3 callers of kho_get_mem_map_phys(). Two of them,
> kho_mem_retrieve() and kho_extend_scratch() need the virtual address.
> The third, kho_populate() doesn't care. Make things simpler by
> directly returning the virtual address. Rename kho_get_mem_map_phys() to
> kho_get_mem_map() to accurately reflect what it returns.

This should be moved earlier, before replacing open-coded get_mem_map()
with a call to kho_get_mem_map_phys().
 
> Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
> ---
>  kernel/liveupdate/kexec_handover.c | 28 +++++++++++++++-------------
>  1 file changed, 15 insertions(+), 13 deletions(-)

-- 
Sincerely yours,
Mike.

Re: [PATCH 11/12] kho: return virtual address of mem_map

[Pratyush Yadav]

On Mon, May 11 2026, Mike Rapoport wrote:

> On Wed, Apr 29, 2026 at 03:39:13PM +0200, Pratyush Yadav wrote:
>> From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
>> 
>> There are currently 3 callers of kho_get_mem_map_phys(). Two of them,
>> kho_mem_retrieve() and kho_extend_scratch() need the virtual address.
>> The third, kho_populate() doesn't care. Make things simpler by
>> directly returning the virtual address. Rename kho_get_mem_map_phys() to
>> kho_get_mem_map() to accurately reflect what it returns.
>
> This should be moved earlier, before replacing open-coded get_mem_map()
> with a call to kho_get_mem_map_phys().

Do you mean move it before patch 2 "kho: store incoming radix tree in
kho_in"?

I can do that. I did it this way to show a clear need for this function,
but I don't mind doing it as a preparatory step.

>  
>> Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
>> ---
>>  kernel/liveupdate/kexec_handover.c | 28 +++++++++++++++-------------
>>  1 file changed, 15 insertions(+), 13 deletions(-)

-- 
Regards,
Pratyush Yadav

Re: [PATCH 11/12] kho: return virtual address of mem_map

[Mike Rapoport]

On Mon, May 11, 2026 at 06:48:37PM +0200, Pratyush Yadav wrote:
> On Mon, May 11 2026, Mike Rapoport wrote:
> 
> > On Wed, Apr 29, 2026 at 03:39:13PM +0200, Pratyush Yadav wrote:
> >> From: "Pratyush Yadav (Google)" <pratyush@kernel.org>
> >> 
> >> There are currently 3 callers of kho_get_mem_map_phys(). Two of them,
> >> kho_mem_retrieve() and kho_extend_scratch() need the virtual address.
> >> The third, kho_populate() doesn't care. Make things simpler by
> >> directly returning the virtual address. Rename kho_get_mem_map_phys() to
> >> kho_get_mem_map() to accurately reflect what it returns.
> >
> > This should be moved earlier, before replacing open-coded get_mem_map()
> > with a call to kho_get_mem_map_phys().
> 
> Do you mean move it before patch 2 "kho: store incoming radix tree in
> kho_in"?

Yes.
 
> I can do that. I did it this way to show a clear need for this function,
> but I don't mind doing it as a preparatory step.

With the usual "it will be used in the upcoming changes" text in the log
it's fine :)
 
> >  
> >> Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org>
> >> ---
> >>  kernel/liveupdate/kexec_handover.c | 28 +++++++++++++++-------------
> >>  1 file changed, 15 insertions(+), 13 deletions(-)
> 
> -- 
> Regards,
> Pratyush Yadav

-- 
Sincerely yours,
Mike.