[PATCH 0/4] cleanup maple_alloc related functions

[PATCH 0/4] cleanup maple_alloc related functions

[Wei Yang]

Patch 1/2: some fields of the maple_alloc is not necessary to change, so we
           can skip some operations
Patch 3: a valid alloc check could be hide in current code, so we don't need
         to do a separate check
Patch 4: found on rare case where allocation would fail even has enough
         memory

Wei Yang (4):
  maple_tree: clear request_count for new allocated one
  maple_tree: total is not changed for nomem_one case
  maple_tree: simplify mas_push_node()
  maple_tree: fix potential allocation failure even has memory

 lib/maple_tree.c | 26 ++++++++++++--------------
 1 file changed, 12 insertions(+), 14 deletions(-)

-- 
2.34.1

[PATCH 1/4] maple_tree: clear request_count for new allocated one

[Wei Yang]

If this is not a new allocated one, the request_count has already been
cleared in mas_set_alloc_req().

Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
CC: Liam R. Howlett <Liam.Howlett@Oracle.com>
CC: Sidhartha Kumar <sidhartha.kumar@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 fab1610dc800..75be2c81f0e2 100644
--- a/lib/maple_tree.c
+++ b/lib/maple_tree.c
@@ -1250,11 +1250,11 @@ static inline void mas_alloc_nodes(struct ma_state *mas, gfp_t gfp)
 
 		mas->alloc = node;
 		node->total = ++allocated;
+		node->request_count = 0;
 		requested--;
 	}
 
 	node = mas->alloc;
-	node->request_count = 0;
 	while (requested) {
 		max_req = MAPLE_ALLOC_SLOTS - node->node_count;
 		slots = (void **)&node->slot[node->node_count];
-- 
2.34.1

Re: [PATCH 1/4] maple_tree: clear request_count for new allocated one

[Liam R. Howlett]

* Wei Yang <richard.weiyang@gmail.com> [240924 08:41]:
> If this is not a new allocated one, the request_count has already been
> cleared in mas_set_alloc_req().
> 
> Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
> CC: Liam R. Howlett <Liam.Howlett@Oracle.com>
> CC: Sidhartha Kumar <sidhartha.kumar@oracle.com>

Reviewed-by: 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 fab1610dc800..75be2c81f0e2 100644
> --- a/lib/maple_tree.c
> +++ b/lib/maple_tree.c
> @@ -1250,11 +1250,11 @@ static inline void mas_alloc_nodes(struct ma_state *mas, gfp_t gfp)
>  
>  		mas->alloc = node;
>  		node->total = ++allocated;
> +		node->request_count = 0;
>  		requested--;
>  	}
>  
>  	node = mas->alloc;
> -	node->request_count = 0;
>  	while (requested) {
>  		max_req = MAPLE_ALLOC_SLOTS - node->node_count;
>  		slots = (void **)&node->slot[node->node_count];
> -- 
> 2.34.1
> 

[PATCH 2/4] maple_tree: total is not changed for nomem_one case

[Wei Yang]

If it jumps to nomem_one, the total allocated number is not changed. So
we don't need to adjust it.

For the nomem_bulk case, we know there is a valid mas->alloc. So we
don't need to do the check.

Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
CC: Liam R. Howlett <Liam.Howlett@Oracle.com>
CC: Sidhartha Kumar <sidhartha.kumar@oracle.com>
---
 lib/maple_tree.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/lib/maple_tree.c b/lib/maple_tree.c
index 75be2c81f0e2..c1fb67540cc9 100644
--- a/lib/maple_tree.c
+++ b/lib/maple_tree.c
@@ -1279,10 +1279,9 @@ static inline void mas_alloc_nodes(struct ma_state *mas, gfp_t gfp)
 nomem_bulk:
 	/* Clean up potential freed allocations on bulk failure */
 	memset(slots, 0, max_req * sizeof(unsigned long));
+	mas->alloc->total = allocated;
 nomem_one:
 	mas_set_alloc_req(mas, requested);
-	if (mas->alloc && !(((unsigned long)mas->alloc & 0x1)))
-		mas->alloc->total = allocated;
 	mas_set_err(mas, -ENOMEM);
 }
 
-- 
2.34.1

Re: [PATCH 2/4] maple_tree: total is not changed for nomem_one case

[Liam R. Howlett]

* Wei Yang <richard.weiyang@gmail.com> [240924 08:41]:
> If it jumps to nomem_one, the total allocated number is not changed. So
> we don't need to adjust it.
> 
> For the nomem_bulk case, we know there is a valid mas->alloc. So we
> don't need to do the check.
> 
> Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
> CC: Liam R. Howlett <Liam.Howlett@Oracle.com>
> CC: Sidhartha Kumar <sidhartha.kumar@oracle.com>

Reviewed-by: Liam R. Howlett <Liam.Howlett@Oracle.com>

> ---
>  lib/maple_tree.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/lib/maple_tree.c b/lib/maple_tree.c
> index 75be2c81f0e2..c1fb67540cc9 100644
> --- a/lib/maple_tree.c
> +++ b/lib/maple_tree.c
> @@ -1279,10 +1279,9 @@ static inline void mas_alloc_nodes(struct ma_state *mas, gfp_t gfp)
>  nomem_bulk:
>  	/* Clean up potential freed allocations on bulk failure */
>  	memset(slots, 0, max_req * sizeof(unsigned long));
> +	mas->alloc->total = allocated;
>  nomem_one:
>  	mas_set_alloc_req(mas, requested);
> -	if (mas->alloc && !(((unsigned long)mas->alloc & 0x1)))
> -		mas->alloc->total = allocated;
>  	mas_set_err(mas, -ENOMEM);
>  }
>  
> -- 
> 2.34.1
> 

[PATCH 3/4] maple_tree: simplify mas_push_node()

[Wei Yang]

When count is not 0, we know head is valid. So we can put the assignment
in if(count) instead of check head again.

Also count represents current total, we can assign the new total by
increasing count at last.

Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
CC: Liam R. Howlett <Liam.Howlett@Oracle.com>
CC: Sidhartha Kumar <sidhartha.kumar@oracle.com>
---
 lib/maple_tree.c | 16 +++++++---------
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/lib/maple_tree.c b/lib/maple_tree.c
index c1fb67540cc9..1cbc5f7ca40d 100644
--- a/lib/maple_tree.c
+++ b/lib/maple_tree.c
@@ -1192,19 +1192,17 @@ static inline void mas_push_node(struct ma_state *mas, struct maple_node *used)
 
 	reuse->request_count = 0;
 	reuse->node_count = 0;
-	if (count && (head->node_count < MAPLE_ALLOC_SLOTS)) {
-		head->slot[head->node_count++] = reuse;
-		head->total++;
-		goto done;
-	}
-
-	reuse->total = 1;
-	if ((head) && !((unsigned long)head & 0x1)) {
+	if (count) {
+		if (head->node_count < MAPLE_ALLOC_SLOTS) {
+			head->slot[head->node_count++] = reuse;
+			head->total++;
+			goto done;
+		}
 		reuse->slot[0] = head;
 		reuse->node_count = 1;
-		reuse->total += head->total;
 	}
 
+	reuse->total = count + 1;
 	mas->alloc = reuse;
 done:
 	if (requested > 1)
-- 
2.34.1

Re: [PATCH 3/4] maple_tree: simplify mas_push_node()

[Liam R. Howlett]

* Wei Yang <richard.weiyang@gmail.com> [240924 08:41]:
> When count is not 0, we know head is valid. So we can put the assignment
> in if(count) in stead of check head again.

" in if (count) instead of checking the head pointer again."

> 
> Also count represents current total, we can assign the new total by
> increasing count at last.

" increasing the count by one."

This message isn't clear, but the rest is good.  Thanks!


> 
> Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
> CC: Liam R. Howlett <Liam.Howlett@Oracle.com>
> CC: Sidhartha Kumar <sidhartha.kumar@oracle.com>

Reviewed-by: Liam R. Howlett <Liam.Howlett@Oracle.com>

> ---
>  lib/maple_tree.c | 16 +++++++---------
>  1 file changed, 7 insertions(+), 9 deletions(-)
> 
> diff --git a/lib/maple_tree.c b/lib/maple_tree.c
> index c1fb67540cc9..1cbc5f7ca40d 100644
> --- a/lib/maple_tree.c
> +++ b/lib/maple_tree.c
> @@ -1192,19 +1192,17 @@ static inline void mas_push_node(struct ma_state *mas, struct maple_node *used)
>  
>  	reuse->request_count = 0;
>  	reuse->node_count = 0;
> -	if (count && (head->node_count < MAPLE_ALLOC_SLOTS)) {
> -		head->slot[head->node_count++] = reuse;
> -		head->total++;
> -		goto done;
> -	}
> -
> -	reuse->total = 1;
> -	if ((head) && !((unsigned long)head & 0x1)) {
> +	if (count) {
> +		if (head->node_count < MAPLE_ALLOC_SLOTS) {
> +			head->slot[head->node_count++] = reuse;
> +			head->total++;
> +			goto done;
> +		}
>  		reuse->slot[0] = head;
>  		reuse->node_count = 1;
> -		reuse->total += head->total;
>  	}
>  
> +	reuse->total = count + 1;
>  	mas->alloc = reuse;
>  done:
>  	if (requested > 1)
> -- 
> 2.34.1
> 

[PATCH 4/4] maple_tree: fix potential allocation failure even has memory

[Wei Yang]

We got an rare case when mas_node_count() would fail even there is
enough memory.

The reason is the maple_alloc grows downward. And when hit a full
maple_alloc, the max_req would be 0. This leads to mt_alloc_bulk()
return 0, which means failure here.

For example, here is the test code:

	expect = MAPLE_ALLOC_SLOTS + 1;
	mas_node_count(&ms, expect);
	pr_info("expect %d allocated %lu\n", expect, mas_allocated(&ms));
	expect = MAPLE_ALLOC_SLOTS * 2 + 2;
	mas_node_count(&ms, expect);
	pr_info("expect %d allocated %lu\n", expect, mas_allocated(&ms));

We will get the following output, which shows we fail to allocate the
required number of nodes.

	expect 31 allocated 31
        expect 62 allocated 61

The straight forward way to fix it is go down one level more.

Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
CC: Liam R. Howlett <Liam.Howlett@Oracle.com>
CC: Sidhartha Kumar <sidhartha.kumar@oracle.com>
---
 lib/maple_tree.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lib/maple_tree.c b/lib/maple_tree.c
index 1cbc5f7ca40d..dd33d0793dd1 100644
--- a/lib/maple_tree.c
+++ b/lib/maple_tree.c
@@ -1253,8 +1253,10 @@ static inline void mas_alloc_nodes(struct ma_state *mas, gfp_t gfp)
 	}
 
 	node = mas->alloc;
-	while (requested) {
+	for (; requested; node = node->slot[0]) {
 		max_req = MAPLE_ALLOC_SLOTS - node->node_count;
+		if (unlikely(!max_req))
+			continue;
 		slots = (void **)&node->slot[node->node_count];
 		max_req = min(requested, max_req);
 		count = mt_alloc_bulk(gfp, max_req, slots);
@@ -1268,7 +1270,6 @@ static inline void mas_alloc_nodes(struct ma_state *mas, gfp_t gfp)
 
 		node->node_count += count;
 		allocated += count;
-		node = node->slot[0];
 		requested -= count;
 	}
 	mas->alloc->total = allocated;
-- 
2.34.1

Re: [PATCH 4/4] maple_tree: fix potential allocation failure even has memory

[Wei Yang]

Related fix has been posted, but not merged yet.

lkml.kernel.org/r/20240626160631.3636515-1-Liam.Howlett@oracle.com

May drop this one.

On Tue, Sep 24, 2024 at 12:39:54PM +0000, Wei Yang wrote:
>We got an rare case when mas_node_count() would fail even there is
>enough memory.
>
>The reason is the maple_alloc grows downward. And when hit a full
>maple_alloc, the max_req would be 0. This leads to mt_alloc_bulk()
>return 0, which means failure here.
>
>For example, here is the test code:
>
>	expect = MAPLE_ALLOC_SLOTS + 1;
>	mas_node_count(&ms, expect);
>	pr_info("expect %d allocated %lu\n", expect, mas_allocated(&ms));
>	expect = MAPLE_ALLOC_SLOTS * 2 + 2;
>	mas_node_count(&ms, expect);
>	pr_info("expect %d allocated %lu\n", expect, mas_allocated(&ms));
>
>We will get the following output, which shows we fail to allocate the
>required number of nodes.
>
>	expect 31 allocated 31
>        expect 62 allocated 61
>
>The straight forward way to fix it is go down one level more.
>
>Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
>CC: Liam R. Howlett <Liam.Howlett@Oracle.com>
>CC: Sidhartha Kumar <sidhartha.kumar@oracle.com>
>---
> lib/maple_tree.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
>diff --git a/lib/maple_tree.c b/lib/maple_tree.c
>index 1cbc5f7ca40d..dd33d0793dd1 100644
>--- a/lib/maple_tree.c
>+++ b/lib/maple_tree.c
>@@ -1253,8 +1253,10 @@ static inline void mas_alloc_nodes(struct ma_state *mas, gfp_t gfp)
> 	}
> 
> 	node = mas->alloc;
>-	while (requested) {
>+	for (; requested; node = node->slot[0]) {
> 		max_req = MAPLE_ALLOC_SLOTS - node->node_count;
>+		if (unlikely(!max_req))
>+			continue;
> 		slots = (void **)&node->slot[node->node_count];
> 		max_req = min(requested, max_req);
> 		count = mt_alloc_bulk(gfp, max_req, slots);
>@@ -1268,7 +1270,6 @@ static inline void mas_alloc_nodes(struct ma_state *mas, gfp_t gfp)
> 
> 		node->node_count += count;
> 		allocated += count;
>-		node = node->slot[0];
> 		requested -= count;
> 	}
> 	mas->alloc->total = allocated;
>-- 
>2.34.1

-- 
Wei Yang
Help you, Help me

Re: [PATCH 4/4] maple_tree: fix potential allocation failure even has memory

[Liam R. Howlett]

* Wei Yang <richard.weiyang@gmail.com> [241010 21:27]:
> 
> Related fix has been posted, but not merged yet.
> 
> lkml.kernel.org/r/20240626160631.3636515-1-Liam.Howlett@oracle.com
> 
> May drop this one.

Yes, I thought we had fixed this already.

> 
> On Tue, Sep 24, 2024 at 12:39:54PM +0000, Wei Yang wrote:
> >We got an rare case when mas_node_count() would fail even there is
> >enough memory.
> >
> >The reason is the maple_alloc grows downward. And when hit a full
> >maple_alloc, the max_req would be 0. This leads to mt_alloc_bulk()
> >return 0, which means failure here.
> >
> >For example, here is the test code:
> >
> >	expect = MAPLE_ALLOC_SLOTS + 1;
> >	mas_node_count(&ms, expect);
> >	pr_info("expect %d allocated %lu\n", expect, mas_allocated(&ms));
> >	expect = MAPLE_ALLOC_SLOTS * 2 + 2;
> >	mas_node_count(&ms, expect);
> >	pr_info("expect %d allocated %lu\n", expect, mas_allocated(&ms));
> >
> >We will get the following output, which shows we fail to allocate the
> >required number of nodes.
> >
> >	expect 31 allocated 31
> >        expect 62 allocated 61
> >
> >The straight forward way to fix it is go down one level more.
> >
> >Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
> >CC: Liam R. Howlett <Liam.Howlett@Oracle.com>
> >CC: Sidhartha Kumar <sidhartha.kumar@oracle.com>
> >---
> > lib/maple_tree.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> >diff --git a/lib/maple_tree.c b/lib/maple_tree.c
> >index 1cbc5f7ca40d..dd33d0793dd1 100644
> >--- a/lib/maple_tree.c
> >+++ b/lib/maple_tree.c
> >@@ -1253,8 +1253,10 @@ static inline void mas_alloc_nodes(struct ma_state *mas, gfp_t gfp)
> > 	}
> > 
> > 	node = mas->alloc;
> >-	while (requested) {
> >+	for (; requested; node = node->slot[0]) {
> > 		max_req = MAPLE_ALLOC_SLOTS - node->node_count;
> >+		if (unlikely(!max_req))
> >+			continue;
> > 		slots = (void **)&node->slot[node->node_count];
> > 		max_req = min(requested, max_req);
> > 		count = mt_alloc_bulk(gfp, max_req, slots);
> >@@ -1268,7 +1270,6 @@ static inline void mas_alloc_nodes(struct ma_state *mas, gfp_t gfp)
> > 
> > 		node->node_count += count;
> > 		allocated += count;
> >-		node = node->slot[0];
> > 		requested -= count;
> > 	}
> > 	mas->alloc->total = allocated;
> >-- 
> >2.34.1
> 
> -- 
> Wei Yang
> Help you, Help me
> 

Re: [PATCH 4/4] maple_tree: fix potential allocation failure even has memory

[Liam R. Howlett]

* Wei Yang <richard.weiyang@gmail.com> [241010 21:27]:
> 
> Related fix has been posted, but not merged yet.
> 
> lkml.kernel.org/r/20240626160631.3636515-1-Liam.Howlett@oracle.com
> 
> May drop this one.

Yes, thanks.  This can be dropped in favour of the other commit.

> 
> On Tue, Sep 24, 2024 at 12:39:54PM +0000, Wei Yang wrote:
> >We got an rare case when mas_node_count() would fail even there is
> >enough memory.
> >
> >The reason is the maple_alloc grows downward. And when hit a full
> >maple_alloc, the max_req would be 0. This leads to mt_alloc_bulk()
> >return 0, which means failure here.
> >
> >For example, here is the test code:
> >
> >	expect = MAPLE_ALLOC_SLOTS + 1;
> >	mas_node_count(&ms, expect);
> >	pr_info("expect %d allocated %lu\n", expect, mas_allocated(&ms));
> >	expect = MAPLE_ALLOC_SLOTS * 2 + 2;
> >	mas_node_count(&ms, expect);
> >	pr_info("expect %d allocated %lu\n", expect, mas_allocated(&ms));
> >
> >We will get the following output, which shows we fail to allocate the
> >required number of nodes.
> >
> >	expect 31 allocated 31
> >        expect 62 allocated 61
> >
> >The straight forward way to fix it is go down one level more.
> >
> >Signed-off-by: Wei Yang <richard.weiyang@gmail.com>
> >CC: Liam R. Howlett <Liam.Howlett@Oracle.com>
> >CC: Sidhartha Kumar <sidhartha.kumar@oracle.com>
> >---
> > lib/maple_tree.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> >diff --git a/lib/maple_tree.c b/lib/maple_tree.c
> >index 1cbc5f7ca40d..dd33d0793dd1 100644
> >--- a/lib/maple_tree.c
> >+++ b/lib/maple_tree.c
> >@@ -1253,8 +1253,10 @@ static inline void mas_alloc_nodes(struct ma_state *mas, gfp_t gfp)
> > 	}
> > 
> > 	node = mas->alloc;
> >-	while (requested) {
> >+	for (; requested; node = node->slot[0]) {
> > 		max_req = MAPLE_ALLOC_SLOTS - node->node_count;
> >+		if (unlikely(!max_req))
> >+			continue;
> > 		slots = (void **)&node->slot[node->node_count];
> > 		max_req = min(requested, max_req);
> > 		count = mt_alloc_bulk(gfp, max_req, slots);
> >@@ -1268,7 +1270,6 @@ static inline void mas_alloc_nodes(struct ma_state *mas, gfp_t gfp)
> > 
> > 		node->node_count += count;
> > 		allocated += count;
> >-		node = node->slot[0];
> > 		requested -= count;
> > 	}
> > 	mas->alloc->total = allocated;
> >-- 
> >2.34.1
> 
> -- 
> Wei Yang
> Help you, Help me
> 

Re: [PATCH 0/4] cleanup maple_alloc related functions

[Lorenzo Stoakes]

On Tue, Sep 24, 2024 at 12:39:50PM GMT, Wei Yang wrote:
> Patch 1/2: some fields of the maple_alloc is not necessary to change, so we
>            can skip some operations
> Patch 3: a valid alloc check could be hide in current code, so we don't need
>          to do a separate check
> Patch 4: found on rare case where allocation would fail even has enough
>          memory
>
> Wei Yang (4):
>   maple_tree: clear request_count for new allocated one
>   maple_tree: total is not changed for nomem_one case
>   maple_tree: simplify mas_push_node()
>   maple_tree: fix potential allocation failure even has memory
>
>  lib/maple_tree.c | 26 ++++++++++++--------------
>  1 file changed, 12 insertions(+), 14 deletions(-)
>
> --
> 2.34.1
>
>

Andrew - Liam is away at the moment - could we hold off on taking this
series to unstable until he's back and had a chance to review please?

It may be best to avoid taking maple tree changes other than urgent bug
fixes or the like until his return also.

Wei - please hold off on series like this until Liam's had a chance to
reply to this thread. Thanks!

Re: [PATCH 0/4] cleanup maple_alloc related functions

[Wei Yang]

On Tue, Sep 24, 2024 at 04:03:35PM +0100, Lorenzo Stoakes wrote:
>On Tue, Sep 24, 2024 at 12:39:50PM GMT, Wei Yang wrote:
>> Patch 1/2: some fields of the maple_alloc is not necessary to change, so we
>>            can skip some operations
>> Patch 3: a valid alloc check could be hide in current code, so we don't need
>>          to do a separate check
>> Patch 4: found on rare case where allocation would fail even has enough
>>          memory
>>
>> Wei Yang (4):
>>   maple_tree: clear request_count for new allocated one
>>   maple_tree: total is not changed for nomem_one case
>>   maple_tree: simplify mas_push_node()
>>   maple_tree: fix potential allocation failure even has memory
>>
>>  lib/maple_tree.c | 26 ++++++++++++--------------
>>  1 file changed, 12 insertions(+), 14 deletions(-)
>>
>> --
>> 2.34.1
>>
>>
>
>Andrew - Liam is away at the moment - could we hold off on taking this
>series to unstable until he's back and had a chance to review please?
>
>It may be best to avoid taking maple tree changes other than urgent bug
>fixes or the like until his return also.
>
>Wei - please hold off on series like this until Liam's had a chance to
>reply to this thread. Thanks!

Sure, let me know when it is ok.

BTW, I don't see Andrew has taken it in unstable. Do I miss the mail?

-- 
Wei Yang
Help you, Help me

Re: [PATCH 0/4] cleanup maple_alloc related functions

[Lorenzo Stoakes]

On Wed, Sep 25, 2024 at 01:03:05AM GMT, Wei Yang wrote:
> On Tue, Sep 24, 2024 at 04:03:35PM +0100, Lorenzo Stoakes wrote:
> >On Tue, Sep 24, 2024 at 12:39:50PM GMT, Wei Yang wrote:
> >> Patch 1/2: some fields of the maple_alloc is not necessary to change, so we
> >>            can skip some operations
> >> Patch 3: a valid alloc check could be hide in current code, so we don't need
> >>          to do a separate check
> >> Patch 4: found on rare case where allocation would fail even has enough
> >>          memory
> >>
> >> Wei Yang (4):
> >>   maple_tree: clear request_count for new allocated one
> >>   maple_tree: total is not changed for nomem_one case
> >>   maple_tree: simplify mas_push_node()
> >>   maple_tree: fix potential allocation failure even has memory
> >>
> >>  lib/maple_tree.c | 26 ++++++++++++--------------
> >>  1 file changed, 12 insertions(+), 14 deletions(-)
> >>
> >> --
> >> 2.34.1
> >>
> >>
> >
> >Andrew - Liam is away at the moment - could we hold off on taking this
> >series to unstable until he's back and had a chance to review please?
> >
> >It may be best to avoid taking maple tree changes other than urgent bug
> >fixes or the like until his return also.
> >
> >Wei - please hold off on series like this until Liam's had a chance to
> >reply to this thread. Thanks!
>
> Sure, let me know when it is ok.

Thanks, Liam should reply to the thread once he's back then we're good to
go :)

>
> BTW, I don't see Andrew has taken it in unstable. Do I miss the mail?

Yeah he's not taken yet, kind of getting ahead of things here - not a
comment on your series - more an act of time/resource management :)

Cheers!

>
> --
> Wei Yang
> Help you, Help me
>