[PATCH v2 15/18] kho: extend scratch

[Mike Rapoport]

On Mon, Jun 15, 2026 at 03:28:03PM +0200, Pratyush Yadav wrote:
> On Sun, Jun 14 2026, Mike Rapoport wrote:
> > On Fri, 05 Jun 2026 20:34:48 +0200, Pratyush Yadav <pratyush at kernel.org> wrote:
> >
> >> +{
> >> +	struct kho_radix_tree *tree = data;
> >
> > Would be nice to say which tree in the variable name ;)
> 
> How about preserved_mem_map?

But this is the new tree, isn't it?
Maybe keep the variable name and add a comment? 

> >> +/**
> >
> > I don't think we expose statics as kernel-doc somewhere, so this
> > probably shouldn't be a kernel-doc comment
> 
> This is a leftover from the previous version, where this was external.
> 
> I think the documentation is still worthwhile though, so I suppose I'll
> turn it into a normal comment by removing the /**.

Yeah, I meant it should not be a kernel-doc, just a plain comment. 

> >> +static void __init kho_extend_scratch(void)
> >> +{
> >> +	const struct kho_radix_walk_cb kho_cb = {
> >> +		.leaf = kho_ext_walk_key,
> >> +		.node = kho_ext_walk_node,
> >> +	};
> >> +	const struct kho_radix_walk_cb ext_cb = {
> >> +		.leaf = kho_ext_mark_scratch,
> >> +	};
> >> +	struct kho_radix_tree radix;
> >
> > sashiko says:
> >
> >   Is it possible for the radix variable to contain uninitialized stack memory
> >   here?
> >   If radix is uninitialized, tree->root might contain garbage data when passed
> >   to kho_radix_init_tree()
> >
> > and I agree :)
> >
> > This should be
> >
> > 	struct kho_radix_tree radix = { 0 };
> 
> Ugh, right. But at the same time, it is odd for an initialization
> function to expect an initialized object. Perhaps I should move the
> kho_radix_init_tree() from kho_mem_retrieve() to
> kho_memory_init_early(). Then kho_extend_scratch() won't have to do the
> init at all and I can remove the if (tree->root) check from
> kho_radix_init_tree().

Sounds about right :)
 
> -- 
> Regards,
> Pratyush Yadav

-- 
Sincerely yours,
Mike.