On Thu, Aug 14, 2025 at 10:09:15PM -0400, Liam R. Howlett wrote: > * Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> [250814 21:02]: > > On Thu, 14 Aug 2025 13:40:03 +0100 Pedro Falcato <pfalcato@xxxxxxx> wrote: > > > > > On Thu, Aug 14, 2025 at 07:49:27AM +0100, Lorenzo Stoakes wrote: > > > > From: Pedro Falcato <pfalcato@xxxxxxx> > > > > > > > > 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@xxxxxxxxxx> > > > > Tested-by: Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx> > > > > Signed-off-by: Pedro Falcato <pfalcato@xxxxxxx> > > > > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx> > > > > --- > > > > > > > > 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? > I agree. This sounds sensible. I don't think it makes much sense to let the patchset rot in mm-new. -- Pedro
