Re: [PATCH v3 2/2] test_maple_tree: test maple_range_64 node in RCU mode
From: Dimitris Charisis
Date: Sat Oct 24 2026 - 07:27:10 EST
On 10/23/26 17:14, Florian Schmaus wrote:
Hi Florian!This commit adds a test that builds two maple_range_64 trees in RCUThis case passes on an unfixed kernel.
mode. The first tree has a root that is a full maple_range_64 node and
ensures that the destruction under RCU does not misinterpret the last
slot as metadata. 226 insertions produce such a root on a 64-bit build.
The second tree is a height 3 tree whose root holds 15 child pointers
and metadata in its last slot, so every slot is non-zero and ensures
that the destruction under RCU does not descend into the metadata slot.
3166 insertions produce such a tree on a 64-bit build.
Signed-off-by: Dimitris Charisis <dchar@xxxxxxxxxxxxxxxxx>
diff --git a/lib/test_maple_tree.c b/lib/test_maple_tree.c
index b9367c61e8b5..fb40e193a3cb 100644
--- a/lib/test_maple_tree.c
+++ b/lib/test_maple_tree.c
@@ -3710,6 +3710,36 @@ static noinline void __init alloc_cyclic_testing(struct maple_tree *mt)
MT_BUG_ON(mt, ret != 1);
}
+static noinline void __init check_range64_in_rcu(struct maple_tree *mt)
+{
+ unsigned long i;
+ unsigned long nr_entries = 226; /* Build a full maple_range_64 root node */
+
+ MT_BUG_ON(mt, !mtree_empty(mt));
+ mt_init_flags(mt, MT_FLAGS_USE_RCU);
+
+ for (i = 0; i < nr_entries; i++) {
+ MT_BUG_ON(mt, mtree_test_insert_range(mt, i*10, i*10 + 9,
+ xa_mk_value(i)));
+ }
+
+ mtree_destroy(mt);
+ rcu_barrier();
+
+ nr_entries = 3166; /* Height 3. Root has 15 children + metadata */
+
+ MT_BUG_ON(mt, !mtree_empty(mt));
+ mt_init_flags(mt, MT_FLAGS_USE_RCU);
+
+ for (i = 0; i < nr_entries; i++) {
+ MT_BUG_ON(mt, mtree_test_insert_range(mt, i*10, i*10 + 9,
+ xa_mk_value(i)));
+ }
+
+ mtree_destroy(mt);
+ rcu_barrier();
The bug that exists today requires a non-root node with 15 children and a
tree of height 4. The size-2768 test case in my series covers that. You can
find my test at
https://lore.kernel.org/all/20261015-maple-tree-fix-slab-corruption-v1-3-160d97f7304c@xxxxxxxxxxx/
and may fold it into your check_range64_in_rcu(). It fails without your (or
my) fix and succeed with.
KASAN catches the invalid pointer access in the first tested tree on
an unmodified kernel. The second test guards against the cause of the
second bug: a node (at least) two levels above the leaves with exactly
15 valid child pointers.
That being said, I do think that covering the case where this is an
intermediate node has its own value. After all, more testing is never
bad :-). Feel free to send / extend the test. Since it exercises the
same underlying issue, extending check_range64_in_rcu() seems like
the right place to me.
Dimitris