| Message ID | 20221113005618.29679-1-richard.weiyang@gmail.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | maple_tree: not necessary to filter MAPLE_PARENT_ROOT since it is not a root | expand |
* Wei Yang <richard.weiyang@gmail.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@gmail.com> > CC: Liam R. Howlett <Liam.Howlett@Oracle.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 >
* Liam R. Howlett <Liam.Howlett@Oracle.com> [221115 09:29]: > * Wei Yang <richard.weiyang@gmail.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@gmail.com> > > CC: Liam R. Howlett <Liam.Howlett@Oracle.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. On second thought, I will hold off for the 6.2 merge window for this to go upstream. Thanks, Liam
On Tue, Nov 15, 2022 at 02:31:15PM +0000, Liam Howlett wrote: >* Wei Yang <richard.weiyang@gmail.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@gmail.com> >> CC: Liam R. Howlett <Liam.Howlett@Oracle.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. > Yep, look forward your cleanup. While I have a question here. We get 4 types in maple_type, here we just return two of them. This means the other two is not possible to be parent node, right? >> >> switch (p_type) { >> case MAPLE_PARENT_RANGE64: /* or MAPLE_PARENT_ARANGE64 */ >> -- >> 2.33.1 >>
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); switch (p_type) { case MAPLE_PARENT_RANGE64: /* or MAPLE_PARENT_ARANGE64 */
Root node is return at the beginning, so we are sure bit 0 is not set. Signed-off-by: Wei Yang <richard.weiyang@gmail.com> CC: Liam R. Howlett <Liam.Howlett@Oracle.com> --- lib/maple_tree.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)