Re: [PATCH] testing/radix-tree/maple: hack around kfree_rcu not existing

["Liam R. Howlett" <Liam.Howlett@oracle.com>]

* Andrew Morton <akpm@linux-foundation.org> [250814 21:02]:
> On Thu, 14 Aug 2025 13:40:03 +0100 Pedro Falcato <pfalcato@suse.de> wrote:
> 
> > On Thu, Aug 14, 2025 at 07:49:27AM +0100, Lorenzo Stoakes wrote:
> > > From: Pedro Falcato <pfalcato@suse.de>
> > > 
> > > liburcu doesn't have kfree_rcu (or anything similar). Despite that, we can
> > > hack around it in a trivial fashion, by adding a wrapper.
> > > 
> > > This wrapper only works for maple_nodes, and not anything else (due to us
> > > not being able to know rcu_head offsets in any way), and thus we take
> > > advantage of the type checking to avoid future silent breakage.
> > > 
> > > This fixes the build for the VMA userland tests.
> > > 
> > > Additionally remove the existing implementation in maple.c, and have
> > > maple.c include the maple-shared.c header.
> > > 
> > > Reviewed-by: Sidhartha Kumar <sidhartha.kumar@oracle.com>
> > > Tested-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> > > Signed-off-by: Pedro Falcato <pfalcato@suse.de>
> > > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> > > ---
> > > 
> > > Andrew - please attribute this as Pedro's patch (Pedro - please mail to
> > > confirm), as this is simply an updated version of [0], pulled out to fix the
> > > VMA tests which remain broken.
> > >
> > 
> > ACK, this is fine. The future of the series is still unclear, so if this fixes
> > the build then all good from my end :)
> 
> Well, can we have this as a standalone thing, rather than as a
> modification to a patch whose future is uncertain?
> 
> Then we can just drop "testing/radix-tree/maple: hack around kfree_rcu
> not existing", yes?
> 
> Some expansion of "fixes the build for the VMA userland tests" would be
> helpful.

Ah, this is somewhat messy.

Pedro removed unnecessary rcu calls with the newer slab reality as you
can directly call kfree instead of specifying the kmem_cache.

But the patch is partially already in Vlastimil's sheaves work and we'd
like his work to go through his branch, so the future of this particular
patch is a bit messy.

Maybe we should just drop the related patches that caused the issue from
the mm-new branch?  That way we don't need a fix at all.

And when Vlastimil is around, we can get him to pick up the set
including the fix.

Doing things this way will allow Vlastimil the avoid conflicts on
rebase, and restore the userspace testing in mm-new.

Does that make sense to everyone?

Thanks,
Liam