From visitorckw at gmail.com  Fri May  3 02:50:27 2024
From: visitorckw at gmail.com (Kuan-Wei Chiu)
Date: Fri,  3 May 2024 17:50:27 +0800
Subject: [PATCH] maple_tree: Fix build failure with W=1 and LLVM=1
Message-ID: <20240503095027.747838-1-visitorckw@gmail.com>

When compiling library code using "make W=1 LLVM=1 lib/", clang
generated the following compilation errors:

lib/maple_tree.c:351:21: error: unused function 'mte_set_full' [-Werror,-Wunused-function]
static inline void *mte_set_full(const struct maple_enode *node)
                    ^
lib/maple_tree.c:356:21: error: unused function 'mte_clear_full' [-Werror,-Wunused-function]
static inline void *mte_clear_full(const struct maple_enode *node)
                    ^
lib/maple_tree.c:361:20: error: unused function 'mte_has_null' [-Werror,-Wunused-function]
static inline bool mte_has_null(const struct maple_enode *node)
                   ^
3 errors generated.

Remove unused static inline functions to resolve compilation errors
with clang.

Signed-off-by: Kuan-Wei Chiu <visitorckw at gmail.com>
---
 lib/maple_tree.c | 15 ---------------
 1 file changed, 15 deletions(-)

diff --git a/lib/maple_tree.c b/lib/maple_tree.c
index 55e1b35bf877..cd3f5399f9f3 100644
--- a/lib/maple_tree.c
+++ b/lib/maple_tree.c
@@ -348,21 +348,6 @@ static inline void *mte_safe_root(const struct maple_enode *node)
 	return (void *)((unsigned long)node & ~MAPLE_ROOT_NODE);
 }
 
-static inline void *mte_set_full(const struct maple_enode *node)
-{
-	return (void *)((unsigned long)node & ~MAPLE_ENODE_NULL);
-}
-
-static inline void *mte_clear_full(const struct maple_enode *node)
-{
-	return (void *)((unsigned long)node | MAPLE_ENODE_NULL);
-}
-
-static inline bool mte_has_null(const struct maple_enode *node)
-{
-	return (unsigned long)node & MAPLE_ENODE_NULL;
-}
-
 static __always_inline bool ma_is_root(struct maple_node *node)
 {
 	return ((unsigned long)node->parent & MA_ROOT_PARENT);
-- 
2.34.1



From willy at infradead.org  Fri May  3 05:20:32 2024
From: willy at infradead.org (Matthew Wilcox)
Date: Fri, 3 May 2024 13:20:32 +0100
Subject: [PATCH] maple_tree: Fix build failure with W=1 and LLVM=1
In-Reply-To: <20240503095027.747838-1-visitorckw@gmail.com>
References: <20240503095027.747838-1-visitorckw@gmail.com>
Message-ID: <ZjTWkM9hTnoIhzqV@casper.infradead.org>

On Fri, May 03, 2024 at 05:50:27PM +0800, Kuan-Wei Chiu wrote:
> When compiling library code using "make W=1 LLVM=1 lib/", clang
> generated the following compilation errors:
> 
> lib/maple_tree.c:351:21: error: unused function 'mte_set_full' [-Werror,-Wunused-function]
> static inline void *mte_set_full(const struct maple_enode *node)

Uh, clang is wrong to flag these as an error.  They're just not used
yet.


From visitorckw at gmail.com  Fri May  3 06:01:06 2024
From: visitorckw at gmail.com (Kuan-Wei Chiu)
Date: Fri, 3 May 2024 21:01:06 +0800
Subject: [PATCH] maple_tree: Fix build failure with W=1 and LLVM=1
In-Reply-To: <ZjTWkM9hTnoIhzqV@casper.infradead.org>
References: <20240503095027.747838-1-visitorckw@gmail.com>
 <ZjTWkM9hTnoIhzqV@casper.infradead.org>
Message-ID: <ZjTgEsuxYF29AVFJ@visitorckw-System-Product-Name>

On Fri, May 03, 2024 at 01:20:32PM +0100, Matthew Wilcox wrote:
> On Fri, May 03, 2024 at 05:50:27PM +0800, Kuan-Wei Chiu wrote:
> > When compiling library code using "make W=1 LLVM=1 lib/", clang
> > generated the following compilation errors:
> > 
> > lib/maple_tree.c:351:21: error: unused function 'mte_set_full' [-Werror,-Wunused-function]
> > static inline void *mte_set_full(const struct maple_enode *node)
> 
> Uh, clang is wrong to flag these as an error.  They're just not used
> yet.

I think it's because the kernel defaults to treating all compilation
warnings as errors. If you turn off the option to treat compilation
warnings as errors, they will be treated as warnings instead. Should I
update my commit message to change compilation errors to compilation
warnings?

Regards,
Kuan-Wei


From willy at infradead.org  Fri May  3 06:29:12 2024
From: willy at infradead.org (Matthew Wilcox)
Date: Fri, 3 May 2024 14:29:12 +0100
Subject: [PATCH] maple_tree: Fix build failure with W=1 and LLVM=1
In-Reply-To: <ZjTgEsuxYF29AVFJ@visitorckw-System-Product-Name>
References: <20240503095027.747838-1-visitorckw@gmail.com>
 <ZjTWkM9hTnoIhzqV@casper.infradead.org>
 <ZjTgEsuxYF29AVFJ@visitorckw-System-Product-Name>
Message-ID: <ZjTmqM4ePSZgSt9_@casper.infradead.org>

On Fri, May 03, 2024 at 09:01:06PM +0800, Kuan-Wei Chiu wrote:
> On Fri, May 03, 2024 at 01:20:32PM +0100, Matthew Wilcox wrote:
> > On Fri, May 03, 2024 at 05:50:27PM +0800, Kuan-Wei Chiu wrote:
> > > When compiling library code using "make W=1 LLVM=1 lib/", clang
> > > generated the following compilation errors:
> > > 
> > > lib/maple_tree.c:351:21: error: unused function 'mte_set_full' [-Werror,-Wunused-function]
> > > static inline void *mte_set_full(const struct maple_enode *node)
> > 
> > Uh, clang is wrong to flag these as an error.  They're just not used
> > yet.
> 
> I think it's because the kernel defaults to treating all compilation
> warnings as errors. If you turn off the option to treat compilation
> warnings as errors, they will be treated as warnings instead. Should I
> update my commit message to change compilation errors to compilation
> warnings?

just don't use W=1 and clang.


From nathan at kernel.org  Fri May  3 09:08:21 2024
From: nathan at kernel.org (Nathan Chancellor)
Date: Fri, 3 May 2024 09:08:21 -0700
Subject: [PATCH] maple_tree: Fix build failure with W=1 and LLVM=1
In-Reply-To: <ZjTmqM4ePSZgSt9_@casper.infradead.org>
References: <20240503095027.747838-1-visitorckw@gmail.com>
 <ZjTWkM9hTnoIhzqV@casper.infradead.org>
 <ZjTgEsuxYF29AVFJ@visitorckw-System-Product-Name>
 <ZjTmqM4ePSZgSt9_@casper.infradead.org>
Message-ID: <20240503160821.GB3960118@thelio-3990X>

On Fri, May 03, 2024 at 02:29:12PM +0100, Matthew Wilcox wrote:
> On Fri, May 03, 2024 at 09:01:06PM +0800, Kuan-Wei Chiu wrote:
> > On Fri, May 03, 2024 at 01:20:32PM +0100, Matthew Wilcox wrote:
> > > On Fri, May 03, 2024 at 05:50:27PM +0800, Kuan-Wei Chiu wrote:
> > > > When compiling library code using "make W=1 LLVM=1 lib/", clang
> > > > generated the following compilation errors:
> > > > 
> > > > lib/maple_tree.c:351:21: error: unused function 'mte_set_full' [-Werror,-Wunused-function]
> > > > static inline void *mte_set_full(const struct maple_enode *node)
> > > 
> > > Uh, clang is wrong to flag these as an error.  They're just not used
> > > yet.
> > 
> > I think it's because the kernel defaults to treating all compilation
> > warnings as errors. If you turn off the option to treat compilation
> > warnings as errors, they will be treated as warnings instead. Should I
> > update my commit message to change compilation errors to compilation
> > warnings?
> 
> just don't use W=1 and clang.

This patch has effectively been sent four times now:

https://lore.kernel.org/all/20220914101829.82000-1-jiapeng.chong at linux.alibaba.com/
https://lore.kernel.org/all/20230217084647.50471-1-jiapeng.chong at linux.alibaba.com/
https://lore.kernel.org/all/20230319132903.1702426-1-trix at redhat.com/
https://lore.kernel.org/all/20240503095027.747838-1-visitorckw at gmail.com/ (this change obviously)

Your first comment from the 2022 patch:

  They're not used now, but they will be in a release or two.

I think a few releases have passed since then :) I don't personally care
if there is a solution here or not, as I don't test with W=1 (there's
enough to do at W=0 :P), but maybe it is time for either __maybe_unused
(as that strikes at the heart of the issue) or at the very least a
comment saying "hey, these functions are currently unused but there are
plans for them to be used, so don't remove them", rather than just
saying the status quo?

Cheers,
Nathan


From akpm at linux-foundation.org  Sat May  4 16:02:57 2024
From: akpm at linux-foundation.org (Andrew Morton)
Date: Sat, 4 May 2024 16:02:57 -0700
Subject: [PATCH] maple_tree: Fix build failure with W=1 and LLVM=1
In-Reply-To: <20240503160821.GB3960118@thelio-3990X>
References: <20240503095027.747838-1-visitorckw@gmail.com>
	<ZjTWkM9hTnoIhzqV@casper.infradead.org>
	<ZjTgEsuxYF29AVFJ@visitorckw-System-Product-Name>
	<ZjTmqM4ePSZgSt9_@casper.infradead.org>
	<20240503160821.GB3960118@thelio-3990X>
Message-ID: <20240504160257.02e20addebc407cb4a18da48@linux-foundation.org>

On Fri, 3 May 2024 09:08:21 -0700 Nathan Chancellor <nathan at kernel.org> wrote:

> This patch has effectively been sent four times now:
> 
> https://lore.kernel.org/all/20220914101829.82000-1-jiapeng.chong at linux.alibaba.com/
> https://lore.kernel.org/all/20230217084647.50471-1-jiapeng.chong at linux.alibaba.com/
> https://lore.kernel.org/all/20230319132903.1702426-1-trix at redhat.com/
> https://lore.kernel.org/all/20240503095027.747838-1-visitorckw at gmail.com/ (this change obviously)
> 
> Your first comment from the 2022 patch:
> 
>   They're not used now, but they will be in a release or two.
> 
> I think a few releases have passed since then :) I don't personally care
> if there is a solution here or not, as I don't test with W=1 (there's
> enough to do at W=0 :P), but maybe it is time for either __maybe_unused
> (as that strikes at the heart of the issue) or at the very least a
> comment saying "hey, these functions are currently unused but there are
> plans for them to be used, so don't remove them", rather than just
> saying the status quo?

We could just slap a #if 0 around them.  But I don't think it'll kill us to
have to type them in again one day ;)


From Liam.Howlett at oracle.com  Mon May  6 07:29:09 2024
From: Liam.Howlett at oracle.com (Liam R. Howlett)
Date: Mon, 6 May 2024 10:29:09 -0400
Subject: [PATCH] maple_tree: Fix build failure with W=1 and LLVM=1
In-Reply-To: <20240504160257.02e20addebc407cb4a18da48@linux-foundation.org>
References: <20240503095027.747838-1-visitorckw@gmail.com>
 <ZjTWkM9hTnoIhzqV@casper.infradead.org>
 <ZjTgEsuxYF29AVFJ@visitorckw-System-Product-Name>
 <ZjTmqM4ePSZgSt9_@casper.infradead.org>
 <20240503160821.GB3960118@thelio-3990X>
 <20240504160257.02e20addebc407cb4a18da48@linux-foundation.org>
Message-ID: <u27qo2hnypvnziv36gdzs3eta76t4ia2sjxj7j7fhll3icljng@doeeizsosli2>

* Andrew Morton <akpm at linux-foundation.org> [240504 19:03]:
> On Fri, 3 May 2024 09:08:21 -0700 Nathan Chancellor <nathan at kernel.org> wrote:
> 
> > This patch has effectively been sent four times now:
> > 
> > https://lore.kernel.org/all/20220914101829.82000-1-jiapeng.chong at linux.alibaba.com/
> > https://lore.kernel.org/all/20230217084647.50471-1-jiapeng.chong at linux.alibaba.com/
> > https://lore.kernel.org/all/20230319132903.1702426-1-trix at redhat.com/
> > https://lore.kernel.org/all/20240503095027.747838-1-visitorckw at gmail.com/ (this change obviously)
> > 
> > Your first comment from the 2022 patch:
> > 
> >   They're not used now, but they will be in a release or two.
> > 
> > I think a few releases have passed since then :) I don't personally care
> > if there is a solution here or not, as I don't test with W=1 (there's
> > enough to do at W=0 :P), but maybe it is time for either __maybe_unused
> > (as that strikes at the heart of the issue) or at the very least a
> > comment saying "hey, these functions are currently unused but there are
> > plans for them to be used, so don't remove them", rather than just
> > saying the status quo?
> 
> We could just slap a #if 0 around them.  But I don't think it'll kill us to
> have to type them in again one day ;)

I've had people try to use this bit for other reasons, even with these
functions.

If we're dropping this code, then we should put something in to avoid it
disappearing on us.

I am working on the use of these functions in a branch, but I don't have
a timeline of when that feature will land.

Thanks,
Liam


From rgbi3307 at gmail.com  Thu May 23 19:49:45 2024
From: rgbi3307 at gmail.com (Jung-JaeJoon)
Date: Fri, 24 May 2024 11:49:45 +0900
Subject: [PATCH] Modified XArray entry bit flags as macro constants
Message-ID: <20240524024945.9309-1-rgbi3307@naver.com>

From: Jung-JaeJoon <rgbi3307 at gmail.com>

It would be better to modify the operation on the last two bits of the entry 
with a macro constant name rather than using a numeric constant.

#define XA_VALUE_ENTRY		1UL
#define XA_INTERNAL_ENTRY	2UL
#define XA_POINTER_ENTRY	3UL

In particular, in the xa_to_node() function, it is more consistent and efficient 
to perform a logical AND operation as shown below than a subtraction operation.

- return (struct xa_node *)((unsigned long)entry - 2);
+ return (struct xa_node *)((unsigned long)entry & ~XA_INTERNAL_ENTRY);

Additionally, it is better to modify the if condition below 
in the mas_store_root() function of lib/maple_tree.c to the xa_is_internal() inline function.

- else if (((unsigned long) (entry) & 3) == 2)
+ else if (xa_is_internal(entry))

And there is no reason to declare XA_CHECK_SCHED as an enum data type.
-enum {
-	XA_CHECK_SCHED = 4096,
-};
+#define XA_CHECK_SCHED          4096

Signed-off-by: JaeJoon Jung <rgbi3307 at gmail.com>

---
 include/linux/xarray.h | 55 ++++++++++++++++++++++--------------------
 lib/maple_tree.c       |  2 +-
 2 files changed, 30 insertions(+), 27 deletions(-)

diff --git a/include/linux/xarray.h b/include/linux/xarray.h
index cb571dfcf4b1..d73dfe35a005 100644
--- a/include/linux/xarray.h
+++ b/include/linux/xarray.h
@@ -42,6 +42,16 @@
  * returned by the normal API.
  */
 
+#define XA_VALUE_ENTRY          1UL
+#define XA_INTERNAL_ENTRY       2UL
+#define XA_POINTER_ENTRY        3UL
+
+/*
+ * If iterating while holding a lock, drop the lock and reschedule
+ * every %XA_CHECK_SCHED loops.
+ */
+#define XA_CHECK_SCHED          4096
+
 #define BITS_PER_XA_VALUE	(BITS_PER_LONG - 1)
 
 /**
@@ -54,7 +64,7 @@
 static inline void *xa_mk_value(unsigned long v)
 {
 	WARN_ON((long)v < 0);
-	return (void *)((v << 1) | 1);
+	return (void *)((v << XA_VALUE_ENTRY) | XA_VALUE_ENTRY);
 }
 
 /**
@@ -66,7 +76,7 @@ static inline void *xa_mk_value(unsigned long v)
  */
 static inline unsigned long xa_to_value(const void *entry)
 {
-	return (unsigned long)entry >> 1;
+	return (unsigned long)entry >> XA_VALUE_ENTRY;
 }
 
 /**
@@ -78,7 +88,7 @@ static inline unsigned long xa_to_value(const void *entry)
  */
 static inline bool xa_is_value(const void *entry)
 {
-	return (unsigned long)entry & 1;
+	return (unsigned long)entry & XA_VALUE_ENTRY;
 }
 
 /**
@@ -111,7 +121,7 @@ static inline void *xa_tag_pointer(void *p, unsigned long tag)
  */
 static inline void *xa_untag_pointer(void *entry)
 {
-	return (void *)((unsigned long)entry & ~3UL);
+	return (void *)((unsigned long)entry & ~XA_POINTER_ENTRY);
 }
 
 /**
@@ -126,7 +136,7 @@ static inline void *xa_untag_pointer(void *entry)
  */
 static inline unsigned int xa_pointer_tag(void *entry)
 {
-	return (unsigned long)entry & 3UL;
+	return (unsigned long)entry & XA_POINTER_ENTRY;
 }
 
 /*
@@ -144,7 +154,7 @@ static inline unsigned int xa_pointer_tag(void *entry)
  */
 static inline void *xa_mk_internal(unsigned long v)
 {
-	return (void *)((v << 2) | 2);
+	return (void *)((v << XA_INTERNAL_ENTRY) | XA_INTERNAL_ENTRY);
 }
 
 /*
@@ -156,7 +166,7 @@ static inline void *xa_mk_internal(unsigned long v)
  */
 static inline unsigned long xa_to_internal(const void *entry)
 {
-	return (unsigned long)entry >> 2;
+	return (unsigned long)entry >> XA_INTERNAL_ENTRY;
 }
 
 /*
@@ -168,7 +178,7 @@ static inline unsigned long xa_to_internal(const void *entry)
  */
 static inline bool xa_is_internal(const void *entry)
 {
-	return ((unsigned long)entry & 3) == 2;
+	return ((unsigned long)entry & XA_POINTER_ENTRY) == XA_INTERNAL_ENTRY;
 }
 
 #define XA_ZERO_ENTRY		xa_mk_internal(257)
@@ -220,7 +230,7 @@ static inline int xa_err(void *entry)
 {
 	/* xa_to_internal() would not do sign extension. */
 	if (xa_is_err(entry))
-		return (long)entry >> 2;
+		return (long)entry >> XA_INTERNAL_ENTRY;
 	return 0;
 }
 
@@ -1245,19 +1255,19 @@ static inline struct xa_node *xa_parent_locked(const struct xarray *xa,
 /* Private */
 static inline void *xa_mk_node(const struct xa_node *node)
 {
-	return (void *)((unsigned long)node | 2);
+	return (void *)((unsigned long)node | XA_INTERNAL_ENTRY);
 }
 
 /* Private */
 static inline struct xa_node *xa_to_node(const void *entry)
 {
-	return (struct xa_node *)((unsigned long)entry - 2);
+	return (struct xa_node *)((unsigned long)entry & ~XA_INTERNAL_ENTRY);
 }
 
 /* Private */
 static inline bool xa_is_node(const void *entry)
 {
-	return xa_is_internal(entry) && (unsigned long)entry > 4096;
+	return xa_is_internal(entry) && (unsigned long)entry > XA_CHECK_SCHED;
 }
 
 /* Private */
@@ -1358,9 +1368,10 @@ struct xa_state {
  * We encode errnos in the xas->xa_node.  If an error has happened, we need to
  * drop the lock to fix it, and once we've done so the xa_state is invalid.
  */
-#define XA_ERROR(errno) ((struct xa_node *)(((unsigned long)errno << 2) | 2UL))
-#define XAS_BOUNDS	((struct xa_node *)1UL)
-#define XAS_RESTART	((struct xa_node *)3UL)
+#define XA_ERROR(errno) ((struct xa_node *)             \
+        (((unsigned long)errno << XA_INTERNAL_ENTRY) | XA_INTERNAL_ENTRY))
+#define XAS_BOUNDS	((struct xa_node *)XA_VALUE_ENTRY)
+#define XAS_RESTART	((struct xa_node *)XA_POINTER_ENTRY)
 
 #define __XA_STATE(array, index, shift, sibs)  {	\
 	.xa = array,					\
@@ -1449,7 +1460,7 @@ static inline void xas_set_err(struct xa_state *xas, long err)
  */
 static inline bool xas_invalid(const struct xa_state *xas)
 {
-	return (unsigned long)xas->xa_node & 3;
+	return (unsigned long)xas->xa_node & XA_POINTER_ENTRY;
 }
 
 /**
@@ -1477,13 +1488,13 @@ static inline bool xas_is_node(const struct xa_state *xas)
 /* True if the pointer is something other than a node */
 static inline bool xas_not_node(struct xa_node *node)
 {
-	return ((unsigned long)node & 3) || !node;
+	return ((unsigned long)node & XA_POINTER_ENTRY) || !node;
 }
 
 /* True if the node represents RESTART or an error */
 static inline bool xas_frozen(struct xa_node *node)
 {
-	return (unsigned long)node & 2;
+	return (unsigned long)node & XA_INTERNAL_ENTRY;
 }
 
 /* True if the node represents head-of-tree, RESTART or BOUNDS */
@@ -1764,14 +1775,6 @@ static inline void *xas_next_marked(struct xa_state *xas, unsigned long max,
 	return entry;
 }
 
-/*
- * If iterating while holding a lock, drop the lock and reschedule
- * every %XA_CHECK_SCHED loops.
- */
-enum {
-	XA_CHECK_SCHED = 4096,
-};
-
 /**
  * xas_for_each() - Iterate over a range of an XArray.
  * @xas: XArray operation state.
diff --git a/lib/maple_tree.c b/lib/maple_tree.c
index 2d7d27e6ae3c..c08545f8b09b 100644
--- a/lib/maple_tree.c
+++ b/lib/maple_tree.c
@@ -3515,7 +3515,7 @@ static inline void mas_store_root(struct ma_state *mas, void *entry)
 {
 	if (likely((mas->last != 0) || (mas->index != 0)))
 		mas_root_expand(mas, entry);
-	else if (((unsigned long) (entry) & 3) == 2)
+        else if (xa_is_internal(entry))
 		mas_root_expand(mas, entry);
 	else {
 		rcu_assign_pointer(mas->tree->ma_root, entry);
-- 
2.17.1



From willy at infradead.org  Thu May 23 20:05:49 2024
From: willy at infradead.org (Matthew Wilcox)
Date: Fri, 24 May 2024 04:05:49 +0100
Subject: [PATCH] Modified XArray entry bit flags as macro constants
In-Reply-To: <20240524024945.9309-1-rgbi3307@naver.com>
References: <20240524024945.9309-1-rgbi3307@naver.com>
Message-ID: <ZlAEDbOR6Ch-Y__C@casper.infradead.org>

On Fri, May 24, 2024 at 11:49:45AM +0900, Jung-JaeJoon wrote:
> From: Jung-JaeJoon <rgbi3307 at gmail.com>
> 
> It would be better to modify the operation on the last two bits of the entry 
> with a macro constant name rather than using a numeric constant.
> 
> #define XA_VALUE_ENTRY		1UL
> #define XA_INTERNAL_ENTRY	2UL
> #define XA_POINTER_ENTRY	3UL
> 
> In particular, in the xa_to_node() function, it is more consistent and efficient 
> to perform a logical AND operation as shown below than a subtraction operation.
> 
> - return (struct xa_node *)((unsigned long)entry - 2);
> + return (struct xa_node *)((unsigned long)entry & ~XA_INTERNAL_ENTRY);
> 
> Additionally, it is better to modify the if condition below 
> in the mas_store_root() function of lib/maple_tree.c to the xa_is_internal() inline function.
> 
> - else if (((unsigned long) (entry) & 3) == 2)
> + else if (xa_is_internal(entry))
> 
> And there is no reason to declare XA_CHECK_SCHED as an enum data type.
> -enum {
> -	XA_CHECK_SCHED = 4096,
> -};
> +#define XA_CHECK_SCHED          4096

Thank you for your patch.  I agree with none of this.  Rejected.


From rgbi3307 at gmail.com  Fri May 24 18:02:23 2024
From: rgbi3307 at gmail.com (JaeJoon Jung)
Date: Sat, 25 May 2024 10:02:23 +0900
Subject: [PATCH] maple_tree: modified return type of mas_wr_store_entry()
Message-ID: <20240525010223.1704-1-rgbi3307@naver.com>

From: Jung-JaeJoon <rgbi3307 at gmail.com>

Since there is no place to use the return value of the mas_wr_store_entry() function,
it is correct to modify it to void.

Signed-off-by: JaeJoon Jung <rgbi3307 at gmail.com>
---
 lib/maple_tree.c | 15 ++++++---------
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/lib/maple_tree.c b/lib/maple_tree.c
index 2d7d27e6ae3c..da30977aab0f 100644
--- a/lib/maple_tree.c
+++ b/lib/maple_tree.c
@@ -4203,31 +4203,28 @@ static inline void mas_wr_modify(struct ma_wr_state *wr_mas)
  *
  * Return: The contents that was stored at the index.
  */
-static inline void *mas_wr_store_entry(struct ma_wr_state *wr_mas)
+static inline void mas_wr_store_entry(struct ma_wr_state *wr_mas)
 {
 	struct ma_state *mas = wr_mas->mas;
 
 	wr_mas->content = mas_start(mas);
 	if (mas_is_none(mas) || mas_is_ptr(mas)) {
 		mas_store_root(mas, wr_mas->entry);
-		return wr_mas->content;
+		return;
 	}
 
 	if (unlikely(!mas_wr_walk(wr_mas))) {
 		mas_wr_spanning_store(wr_mas);
-		return wr_mas->content;
+		return;
 	}
 
 	/* At this point, we are at the leaf node that needs to be altered. */
 	mas_wr_end_piv(wr_mas);
 	/* New root for a single pointer */
-	if (unlikely(!mas->index && mas->last == ULONG_MAX)) {
+	if (unlikely(!mas->index && mas->last == ULONG_MAX))
 		mas_new_root(mas, wr_mas->entry);
-		return wr_mas->content;
-	}
-
-	mas_wr_modify(wr_mas);
-	return wr_mas->content;
+        else
+	        mas_wr_modify(wr_mas);
 }
 
 /**
-- 
2.17.1



From Liam.Howlett at oracle.com  Mon May 27 08:08:32 2024
From: Liam.Howlett at oracle.com (Liam R. Howlett)
Date: Mon, 27 May 2024 11:08:32 -0400
Subject: [PATCH] maple_tree: modified return type of mas_wr_store_entry()
In-Reply-To: <20240525010223.1704-1-rgbi3307@naver.com>
References: <20240525010223.1704-1-rgbi3307@naver.com>
Message-ID: <ojvx3usqalady6zp5cwbqjrvtrhjgym4ai7hagbpjvfkfztsu3@2o6nq3hgiblu>

* JaeJoon Jung <rgbi3307 at gmail.com> [240524 21:02]:
> From: Jung-JaeJoon <rgbi3307 at gmail.com>
> 

Thank you for your cleanup patch.

I have added two more mailing lists to the Cc.  Please Cc them on any
other patches related to the maple tree and mm area.

> Since there is no place to use the return value of the mas_wr_store_entry() function,
> it is correct to modify it to void.

This comment isn't clear.

Maybe something like (please, modify it to your liking):
"Since the return value of mas_wr_store_entry() is not used, the return
type can be changed to void"

> 
> Signed-off-by: JaeJoon Jung <rgbi3307 at gmail.com>
> ---
>  lib/maple_tree.c | 15 ++++++---------
>  1 file changed, 6 insertions(+), 9 deletions(-)
> 
> diff --git a/lib/maple_tree.c b/lib/maple_tree.c
> index 2d7d27e6ae3c..da30977aab0f 100644
> --- a/lib/maple_tree.c
> +++ b/lib/maple_tree.c
> @@ -4203,31 +4203,28 @@ static inline void mas_wr_modify(struct ma_wr_state *wr_mas)
>   *
>   * Return: The contents that was stored at the index.
>   */
> -static inline void *mas_wr_store_entry(struct ma_wr_state *wr_mas)
> +static inline void mas_wr_store_entry(struct ma_wr_state *wr_mas)
>  {
>  	struct ma_state *mas = wr_mas->mas;
>  
>  	wr_mas->content = mas_start(mas);
>  	if (mas_is_none(mas) || mas_is_ptr(mas)) {
>  		mas_store_root(mas, wr_mas->entry);
> -		return wr_mas->content;
> +		return;
>  	}
>  
>  	if (unlikely(!mas_wr_walk(wr_mas))) {
>  		mas_wr_spanning_store(wr_mas);
> -		return wr_mas->content;
> +		return;
>  	}
>  
>  	/* At this point, we are at the leaf node that needs to be altered. */
>  	mas_wr_end_piv(wr_mas);
>  	/* New root for a single pointer */
> -	if (unlikely(!mas->index && mas->last == ULONG_MAX)) {
> +	if (unlikely(!mas->index && mas->last == ULONG_MAX))
>  		mas_new_root(mas, wr_mas->entry);
> -		return wr_mas->content;

Please keep this return statement, as you did above, for consistency and
code clarity.

> -	}
> -
> -	mas_wr_modify(wr_mas);
> -	return wr_mas->content;
> +        else
> +	        mas_wr_modify(wr_mas);
>  }
>  
>  /**
> -- 
> 2.17.1
> 


From rgbi3307 at gmail.com  Mon May 27 16:20:27 2024
From: rgbi3307 at gmail.com (JaeJoon Jung)
Date: Tue, 28 May 2024 08:20:27 +0900
Subject: [PATCH] maple_tree: modified return type of mas_wr_store_entry()
In-Reply-To: <ojvx3usqalady6zp5cwbqjrvtrhjgym4ai7hagbpjvfkfztsu3@2o6nq3hgiblu>
References: <20240525010223.1704-1-rgbi3307@naver.com> <ojvx3usqalady6zp5cwbqjrvtrhjgym4ai7hagbpjvfkfztsu3@2o6nq3hgiblu>
Message-ID: <CAHOvCC67kLqZ9Z+ecKNyhz0gSk50N1rn5=twN=Z0p=_0qmGAbA@mail.gmail.com>

Thank you so much for clarifying and correcting my comments and
sharing it with relevant groups.

On Tue, 28 May 2024 at 00:08, Liam R. Howlett <Liam.Howlett at oracle.com> wrote:
>
> * JaeJoon Jung <rgbi3307 at gmail.com> [240524 21:02]:
> > From: Jung-JaeJoon <rgbi3307 at gmail.com>
> >
>
> Thank you for your cleanup patch.
>
> I have added two more mailing lists to the Cc.  Please Cc them on any
> other patches related to the maple tree and mm area.
>
> > Since there is no place to use the return value of the mas_wr_store_entry() function,
> > it is correct to modify it to void.
>
> This comment isn't clear.
>
> Maybe something like (please, modify it to your liking):
> "Since the return value of mas_wr_store_entry() is not used, the return
> type can be changed to void"
>
> >
> > Signed-off-by: JaeJoon Jung <rgbi3307 at gmail.com>
> > ---
> >  lib/maple_tree.c | 15 ++++++---------
> >  1 file changed, 6 insertions(+), 9 deletions(-)
> >
> > diff --git a/lib/maple_tree.c b/lib/maple_tree.c
> > index 2d7d27e6ae3c..da30977aab0f 100644
> > --- a/lib/maple_tree.c
> > +++ b/lib/maple_tree.c
> > @@ -4203,31 +4203,28 @@ static inline void mas_wr_modify(struct ma_wr_state *wr_mas)
> >   *
> >   * Return: The contents that was stored at the index.
> >   */
> > -static inline void *mas_wr_store_entry(struct ma_wr_state *wr_mas)
> > +static inline void mas_wr_store_entry(struct ma_wr_state *wr_mas)
> >  {
> >       struct ma_state *mas = wr_mas->mas;
> >
> >       wr_mas->content = mas_start(mas);
> >       if (mas_is_none(mas) || mas_is_ptr(mas)) {
> >               mas_store_root(mas, wr_mas->entry);
> > -             return wr_mas->content;
> > +             return;
> >       }
> >
> >       if (unlikely(!mas_wr_walk(wr_mas))) {
> >               mas_wr_spanning_store(wr_mas);
> > -             return wr_mas->content;
> > +             return;
> >       }
> >
> >       /* At this point, we are at the leaf node that needs to be altered. */
> >       mas_wr_end_piv(wr_mas);
> >       /* New root for a single pointer */
> > -     if (unlikely(!mas->index && mas->last == ULONG_MAX)) {
> > +     if (unlikely(!mas->index && mas->last == ULONG_MAX))
> >               mas_new_root(mas, wr_mas->entry);
> > -             return wr_mas->content;
>
> Please keep this return statement, as you did above, for consistency and
> code clarity.
>
> > -     }
> > -
> > -     mas_wr_modify(wr_mas);
> > -     return wr_mas->content;
> > +        else
> > +             mas_wr_modify(wr_mas);
> >  }
> >
> >  /**
> > --
> > 2.17.1
> >


From quic_jjohnson at quicinc.com  Fri May 31 17:13:16 2024
From: quic_jjohnson at quicinc.com (Jeff Johnson)
Date: Fri, 31 May 2024 17:13:16 -0700
Subject: [PATCH] test_maple_tree: add the missing MODULE_DESCRIPTION()
 macro
Message-ID: <20240531-md-lib-test_maple_tree-v1-1-7b1b485aeec3@quicinc.com>

make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in lib/test_maple_tree.o

Add the missing invocation of the MODULE_DESCRIPTION() macro.

Signed-off-by: Jeff Johnson <quic_jjohnson at quicinc.com>
---
 lib/test_maple_tree.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/test_maple_tree.c b/lib/test_maple_tree.c
index 399380db449c..31561e0e1a0d 100644
--- a/lib/test_maple_tree.c
+++ b/lib/test_maple_tree.c
@@ -3946,4 +3946,5 @@ static void __exit maple_tree_harvest(void)
 module_init(maple_tree_seed);
 module_exit(maple_tree_harvest);
 MODULE_AUTHOR("Liam R. Howlett <Liam.Howlett at Oracle.com>");
+MODULE_DESCRIPTION("maple tree API test module");
 MODULE_LICENSE("GPL");

---
base-commit: b050496579632f86ee1ef7e7501906db579f3457
change-id: 20240531-md-lib-test_maple_tree-51da39617917



From rgbi3307 at gmail.com  Fri May 31 19:37:14 2024
From: rgbi3307 at gmail.com (Jung-JaeJoon)
Date: Sat,  1 Jun 2024 11:37:14 +0900
Subject: [PATCH] maple_tree: add mas_node_count() before going to slow_path in mas_wr_modify()
Message-ID: <20240601023714.21226-1-rgbi3307@naver.com>

From: Jung-JaeJoon <rgbi3307 at gmail.com>

If there are not enough nodes, mas_node_count() set an error state via mas_set_err()
and return control flow to the beginning.

In the return flow, mas_nomem() checks the error status, allocates new nodes,
and resumes execution again.

In particular,
if this happens in mas_split() in the slow_path section executed in mas_wr_modify(),
unnecessary work is repeated, causing a slowdown in speed as below flow:

_begin:
mas_wr_modify() --> if (new_end >= mt_slots[wr_mas->type]) --> goto slow_path
slow_path:
    --> mas_wr_bnode() --> mas_store_b_node() --> mas_commit_b_node() --> mas_split()
    --> mas_node_count() return to _begin

But, in the above flow, if mas_node_count() is executed before entering slow_path,
execution efficiency is improved by allocating nodes without entering slow_path repeatedly.

Signed-off-by: JaeJoon Jung <rgbi3307 at gmail.com>
---
 lib/maple_tree.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/lib/maple_tree.c b/lib/maple_tree.c
index 2d7d27e6ae3c..b42a4e70d229 100644
--- a/lib/maple_tree.c
+++ b/lib/maple_tree.c
@@ -4176,8 +4176,13 @@ static inline void mas_wr_modify(struct ma_wr_state *wr_mas)
 	 * path.
 	 */
 	new_end = mas_wr_new_end(wr_mas);
-	if (new_end >= mt_slots[wr_mas->type])
+	if (new_end >= mt_slots[wr_mas->type]) }
+                mas->depth = mas_mt_height(mas);
+                mas_node_count(mas, 1 + mas->depth * 2);
+                if (mas_is_err(mas))
+                        return;
 		goto slow_path;
+        }
 
 	/* Attempt to append */
 	if (mas_wr_append(wr_mas, new_end))
-- 
2.17.1



From rgbi3307 at gmail.com  Fri May 31 19:55:36 2024
From: rgbi3307 at gmail.com (Jung-JaeJoon)
Date: Sat,  1 Jun 2024 11:55:36 +0900
Subject: [PATCH] maple_tree: add mas_node_count() before going to slow_path in mas_wr_modify()
Message-ID: <20240601025536.25682-1-rgbi3307@naver.com>

From: Jung-JaeJoon <rgbi3307 at gmail.com>

If there are not enough nodes, mas_node_count() set an error state via mas_set_err()
and return control flow to the beginning.

In the return flow, mas_nomem() checks the error status, allocates new nodes,
and resumes execution again.

In particular,
if this happens in mas_split() in the slow_path section executed in mas_wr_modify(),
unnecessary work is repeated, causing a slowdown in speed as below flow:

_begin:
mas_wr_modify() --> if (new_end >= mt_slots[wr_mas->type]) --> goto slow_path
slow_path:
    --> mas_wr_bnode() --> mas_store_b_node() --> mas_commit_b_node() --> mas_split()
    --> mas_node_count() return to _begin

But, in the above flow, if mas_node_count() is executed before entering slow_path,
execution efficiency is improved by allocating nodes without entering slow_path repeatedly.

Signed-off-by: JaeJoon Jung <rgbi3307 at gmail.com>
---
 lib/maple_tree.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/lib/maple_tree.c b/lib/maple_tree.c
index 2d7d27e6ae3c..8ffabd73619f 100644
--- a/lib/maple_tree.c
+++ b/lib/maple_tree.c
@@ -4176,8 +4176,13 @@ static inline void mas_wr_modify(struct ma_wr_state *wr_mas)
 	 * path.
 	 */
 	new_end = mas_wr_new_end(wr_mas);
-	if (new_end >= mt_slots[wr_mas->type])
+	if (new_end >= mt_slots[wr_mas->type]) {
+                mas->depth = mas_mt_height(mas);
+                mas_node_count(mas, 1 + mas->depth * 2);
+                if (mas_is_err(mas))
+                        return;
 		goto slow_path;
+        }
 
 	/* Attempt to append */
 	if (mas_wr_append(wr_mas, new_end))
-- 
2.17.1



