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.

Sid - I kept your R-b as this is fundamentally the same thing, just pulling out
shared code from maple.c.

Delta from [0]:
* Removed duplicated code from maple.c.
* Slightly reworded patch description.

Note I didn't put a Fixes, as the relevant commit [1] is not yet upstream.

Thanks, Lorenzo

[0]:https://lore.kernel.org/all/20250812162124.59417-1-pfalcato@suse.de/
[1]:https://lore.kernel.org/all/20250718172138.103116-1-pfalcato@suse.de/

 tools/testing/radix-tree/maple.c    | 18 +-----------------
 tools/testing/shared/maple-shared.h | 15 +++++++++++++++
 2 files changed, 16 insertions(+), 17 deletions(-)

diff --git a/tools/testing/radix-tree/maple.c b/tools/testing/radix-tree/maple.c
index bfdc93c36cf9..fbfd4fcc634c 100644
--- a/tools/testing/radix-tree/maple.c
+++ b/tools/testing/radix-tree/maple.c
@@ -23,23 +23,7 @@
 #define MODULE_LICENSE(x)
 #define dump_stack()	assert(0)

-
-#include <linux/maple_tree.h>
-
-static void free_node(struct rcu_head *head)
-{
-	struct maple_node *node = container_of(head, struct maple_node, rcu);
-
-	free(node);
-}
-
-static void kfree_rcu_node(struct maple_node *node)
-{
-	call_rcu(&node->rcu, free_node);
-}
-
-#define kfree_rcu(ptr, memb) kfree_rcu_node(ptr)
-
+#include "../shared/maple-shared.h"
 #include "../../../lib/maple_tree.c"
 #include "../../../lib/test_maple_tree.c"

diff --git a/tools/testing/shared/maple-shared.h b/tools/testing/shared/maple-shared.h
index dc4d30f3860b..572cd2580123 100644
--- a/tools/testing/shared/maple-shared.h
+++ b/tools/testing/shared/maple-shared.h
@@ -9,5 +9,20 @@
 #include <stdlib.h>
 #include <time.h>
 #include "linux/init.h"
+#include <linux/maple_tree.h>
+
+static inline void free_node(struct rcu_head *head)
+{
+	struct maple_node *node = container_of(head, struct maple_node, rcu);
+
+	free(node);
+}
+
+static inline void kfree_rcu_node(struct maple_node *node)
+{
+	call_rcu(&node->rcu, free_node);
+}
+
+#define kfree_rcu(ptr, memb) kfree_rcu_node(ptr)

 #endif /* __MAPLE_SHARED_H__ */
--
2.50.1

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 :)

-- 
Pedro

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.

* 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

On Thu, Aug 14, 2025 at 10:09:15PM -0400, Liam R. Howlett wrote:
> * 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?
>

I agree. This sounds sensible. I don't think it makes much sense to let the
patchset rot in mm-new.

-- 
Pedro

On Thu, Aug 14, 2025 at 10:09:15PM -0400, Liam R. Howlett wrote:
> * Andrew Morton <akpm@linux-foundation.org> [250814 21:02]:
> > 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?

Sounds good to me, I didn't realise that both the original series at [0])
(which introduced the test fail) and the follow up at [1] were intended to
be dropped, I thought only [1] but dropping [0] obviously also fixes it!

And it looks like Andrew's done so and tests now fully working in mm-new
again so I'm happy :)

Cheers, Lorenzo

[0]:https://lore.kernel.org/all/20250718172138.103116-1-pfalcato@suse.de/
[1]:https://lore.kernel.org/all/20250812162124.59417-1-pfalcato@suse.de/

On Fri, Aug 15, 2025 at 05:28:02AM +0100, Lorenzo Stoakes wrote:
> On Thu, Aug 14, 2025 at 10:09:15PM -0400, Liam R. Howlett wrote:
> > * Andrew Morton <akpm@linux-foundation.org> [250814 21:02]:
> > > 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?
>
> Sounds good to me, I didn't realise that both the original series at [0])
> (which introduced the test fail) and the follow up at [1] were intended to
> be dropped, I thought only [1] but dropping [0] obviously also fixes it!
>
> And it looks like Andrew's done so and tests now fully working in mm-new
> again so I'm happy :)

OK this isn't the case.

Can you clarify that you want to drop [0] and explicitly reply there asking
Andrew to drop it just so all is certain?

Because right now VMA tests are still broken in mm-new :(

>
> Cheers, Lorenzo
>
> [0]:https://lore.kernel.org/all/20250718172138.103116-1-pfalcato@suse.de/
> [1]:https://lore.kernel.org/all/20250812162124.59417-1-pfalcato@suse.de/

Thanks, Lorenzo