[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221115142914.x6d2q3qz4xurikrq@revolver>
Date: Tue, 15 Nov 2022 14:31:15 +0000
From: Liam Howlett <liam.howlett@...cle.com>
To: Wei Yang <richard.weiyang@...il.com>
CC: "linux-mm@...ck.org" <linux-mm@...ck.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] maple_tree: not necessary to filter MAPLE_PARENT_ROOT
since it is not a root
* Wei Yang <richard.weiyang@...il.com> [221112 19:56]:
> Root node is return at the beginning, so we are sure bit 0 is not set.
>
> Signed-off-by: Wei Yang <richard.weiyang@...il.com>
> CC: Liam R. Howlett <Liam.Howlett@...cle.com>
> ---
> lib/maple_tree.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/maple_tree.c b/lib/maple_tree.c
> index 9aad98c24f3e..f8c4755e7c75 100644
> --- a/lib/maple_tree.c
> +++ b/lib/maple_tree.c
> @@ -436,7 +436,7 @@ enum maple_type mte_parent_enum(struct maple_enode *p_enode,
> return 0; /* Validated in the caller. */
>
> p_type &= MAPLE_NODE_MASK;
> - p_type = p_type & ~(MAPLE_PARENT_ROOT | mte_parent_slot_mask(p_type));
> + p_type = p_type & ~mte_parent_slot_mask(p_type);
I think there is a larger cleanup that can be done here. It looks like
mte_parent_enum() is called from one location and that location is a
wrapper.
The check for the root bit should also probably trigger a WARN_ON() and
still return 0. I don't think the callers are doing enough to validate
it - although they should never reach this function with a root node.
And, in fact, I am not doing enough in the test code since I didn't
guard this correctly in the verification of the parent slot before
calling this function.
Thanks for pointing this out. I will send out a patch to clean this up
shortly.
>
> switch (p_type) {
> case MAPLE_PARENT_RANGE64: /* or MAPLE_PARENT_ARANGE64 */
> --
> 2.33.1
>
Powered by blists - more mailing lists