Re: [PATCH v2] test_maple_tree: test maple_range_64 node below the root in RCU mode

[Liam R. Howlett]

On 26/11/02 10:14AM, Florian Schmaus wrote:
> Commit baed735a956f ("maple_tree: fix maple_range_64 crashes in RCU
> mode") fixed mt_free_walk() taking the metadata in the last slot of a
> maple_range_64 node with 15 children for a child node.  The bug only
> affects nodes at least two levels above the leaves.  The test added
> along with the fix, check_range64_in_rcu(), uses a height 3 tree, in
> which the root is the only such node.
> 
> The height 3 tree only exposes the bug because the same commit also
> removed mt_clear_meta(), which used to clear the metadata of the root.
> On the code before that commit, the bug is only reachable below the
> root, and the height 3 tree is destroyed without a crash.  If the
> metadata of the root were cleared again, the existing test would no
> longer detect the bug.
> 
> Add a height 4 tree in which a child of the root has 15 children and
> keeps its metadata in the last slot.  5191 insertions produce such a
> tree on a 64-bit build.  Destroying it crashes without the
> mt_free_walk() fix, with or without mt_clear_meta().  For example, on
> the code before the fix, the userspace test harness reports:
> 
>   lib/maple_tree.c:4755:27: runtime error: member access within
>   misaligned address 0x00000000000e for type 'struct maple_node'
> 
> Signed-off-by: Florian Schmaus <florian.schmaus@xxxxxxxxxxx>

Reviewed-by: Liam R. Howlett (Google) <liam@xxxxxxxxxxxxx>

> ---
> v1 of this series fixed two bugs when freeing RCU-mode maple trees. Both
> are now fixed in mainline by Dimitris' commit baed735a956f ("maple_tree:
> fix maple_range_64 crashes in RCU mode"), so only the height 4 test case
> remains, which I offered to send as a follow-up in [1]. It now extends
> check_range64_in_rcu().
> 
> Testing: the userspace test harness (tools/testing/radix-tree) passes
> on x86_64 with ASan and UBSan, and on s390x (big-endian) under
> qemu-user with UBSan. On both, the new case fails without the
> mt_free_walk() fix, with or without mt_clear_meta(), while the
> existing height 3 case only fails once mt_clear_meta() is gone.
> 
> 1: https://lore.kernel.org/all/46073a08-20fd-465e-86e8-9c358787f9b3@xxxxxxxxxxx/
> ---
> Changes in v2:
> - Drop the two fixes, superseded by commit baed735a956f ("maple_tree:
>   fix maple_range_64 crashes in RCU mode").
> - Rebase onto current mainline.
> - Add the height 4 case to check_range64_in_rcu() instead of a separate
>   check_rcu_destroy(), using its insertion pattern (5191 entries).
> - Drop the full root case, which check_range64_in_rcu() already covers.
> - Link to v1: https://patch.msgid.link/20261015-maple-tree-fix-slab-corruption-v1-0-160d97f7304c@xxxxxxxxxxx
> ---
>  lib/test_maple_tree.c | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/lib/test_maple_tree.c b/lib/test_maple_tree.c
> index fb40e193a3cb..121f521e263f 100644
> --- a/lib/test_maple_tree.c
> +++ b/lib/test_maple_tree.c
> @@ -3738,6 +3738,19 @@ static noinline void __init check_range64_in_rcu(struct maple_tree *mt)
>  
>  	mtree_destroy(mt);
>  	rcu_barrier();
> +
> +	nr_entries = 5191; /* Height 4. Root child 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();
>  }
>  
>  static DEFINE_MTREE(tree);
> 
> ---
> base-commit: d89e1d186ec9271bf78e62771779e9fc03bf0fc3
> change-id: 20261015-maple-tree-fix-slab-corruption-d1f098521d15
> 
> Best regards,
> --  
> Florian Schmaus <florian.schmaus@xxxxxxxxxxx>
> 
> 
> -- 
> maple-tree mailing list
> maple-tree@xxxxxxxxxxxxxxxxxxx
> https://lists.infradead.org/mailman/listinfo/maple-tree