Stop using the maple big node for rebalance operations by changing to
more align with spanning store.  The rebalance operation needs its own
data calculation in rebalance_data().

In the event of too much data, the rebalance tries to push the data
using push_data_sib().  If there is insufficient data, the rebalance
operation will rebalance against a sibling (found with rebalance_sib()).

The rebalance starts at the leaf and works its way upward in the tree
using rebalance_ascend().  Most of the code is shared with spanning
store such as the copy node having a new root, but is fundamentally
different in that the data must come from a sibling.

A parent maple state is used to track the parent location to avoid
multiple mas_ascend() calls.  The maple state tree location is copied
from the parent to the mas (child) in the ascend step.  Ascending itself
is done in the main loop.

Signed-off-by: Liam R. Howlett <Liam.Howlett@oracle.com>
---
 lib/maple_tree.c | 212 +++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 205 insertions(+), 7 deletions(-)

diff --git a/lib/maple_tree.c b/lib/maple_tree.c
index 326d6026afee3..9b1686fbd2d8e 100644
--- a/lib/maple_tree.c
+++ b/lib/maple_tree.c
@@ -2298,6 +2298,19 @@ static inline void mte_mid_split_check(struct maple_enode **l,
 	*split = mid_split;
 }
 
+static inline void rebalance_sib(struct ma_state *parent, struct ma_state *sib)
+{
+	*sib = *parent;
+	/* Prioritize move right to pull data left */
+	if (sib->offset < sib->end)
+		sib->offset++;
+	else
+		sib->offset--;
+
+	mas_descend(sib);
+	sib->end = mas_data_end(sib);
+}
+
 static inline
 void spanning_sib(struct ma_wr_state *l_wr_mas,
 		struct ma_wr_state *r_wr_mas, struct ma_state *nneighbour)
@@ -2848,6 +2861,111 @@ static inline void cp_data_calc(struct maple_copy *cp,
 	cp->data += r_wr_mas->mas->end - r_wr_mas->offset_end;
 }
 
+static bool data_fits(struct ma_state *sib, struct ma_state *mas,
+		struct maple_copy *cp)
+{
+	unsigned char new_data;
+	enum maple_type type;
+	unsigned char space;
+	unsigned char end;
+
+	type = mte_node_type(mas->node);
+	space = 2 * mt_slots[type];
+	end = sib->end;
+
+	new_data = end + 1 + cp->data;
+	if (new_data > space)
+		return false;
+
+	/*
+	 * This is off by one by design.  The extra space is left to reduce
+	 * jitter in operations that add then remove two entries.
+	 *
+	 * end is an index while new space and data are both sizes.  Adding one
+	 * to end to convert the index to a size means that the below
+	 * calculation should be <=, but we want to keep an extra space in nodes
+	 * to reduce jitter.
+	 *
+	 * Note that it is still possible to get a full node on the left by the
+	 * NULL landing exactly on the split.  The NULL ending of a node happens
+	 * in the dst_setup() function, where we will either increase the split
+	 * by one or decrease it by one, if possible.  In the case of split
+	 * (this case), it is always possible to shift the spilt by one - again
+	 * because there is at least one slot free by the below checking.
+	 */
+	if (new_data < space)
+		return true;
+
+	return false;
+}
+
+static inline void push_data_sib(struct maple_copy *cp, struct ma_state *mas,
+		struct ma_state *sib, struct ma_state *parent)
+{
+
+	if (mte_is_root(mas->node))
+		goto no_push;
+
+
+	*sib = *parent;
+	if (sib->offset) {
+		sib->offset--;
+		mas_descend(sib);
+		sib->end = mas_data_end(sib);
+		if (data_fits(sib, mas, cp))	/* Push left */
+			return;
+
+		*sib = *parent;
+	}
+
+	if (sib->offset >= sib->end)
+		goto no_push;
+
+	sib->offset++;
+	mas_descend(sib);
+	sib->end = mas_data_end(sib);
+	if (data_fits(sib, mas, cp))		/* Push right*/
+		return;
+
+no_push:
+	sib->end = 0;
+}
+
+/*
+ * rebalance_data() - Calculate the @cp data, populate @sib if insufficient or
+ * if the data can be pushed into a sibling.
+ * @cp: The maple copy node
+ * @wr_mas: The left write maple state
+ * @sib: The maple state of the sibling.
+ *
+ * Note: @cp->data is a size and not indexed by 0. @sib->end may be set to 0 to
+ * indicate it will not be used.
+ *
+ */
+static inline void rebalance_data(struct maple_copy *cp,
+		struct ma_wr_state *wr_mas, struct ma_state *sib,
+		struct ma_state *parent)
+{
+	cp_data_calc(cp, wr_mas, wr_mas);
+	sib->end = 0;
+	if (cp->data >= mt_slots[wr_mas->type]) {
+		push_data_sib(cp, wr_mas->mas, sib, parent);
+		if (sib->end)
+			goto use_sib;
+	} else if (cp->data <= mt_min_slots[wr_mas->type]) {
+		if ((wr_mas->mas->min != 0) ||
+		    (wr_mas->mas->max != ULONG_MAX)) {
+			rebalance_sib(parent, sib);
+			goto use_sib;
+		}
+	}
+
+	return;
+
+use_sib:
+		cp->data += sib->end + 1;
+}
+
 /*
  * spanning_data() - Calculate the @cp data and populate @sib if insufficient
  * @cp: The maple copy node
@@ -3405,6 +3523,55 @@ static bool spanning_ascend(struct maple_copy *cp, struct ma_state *mas,
 	return true;
 }
 
+/*
+ * rebalance_ascend() - Ascend the tree and set up for the next loop - if
+ * necessary
+ *
+ * Return: True if there another rebalancing operation on the next level is
+ * needed, false otherwise.
+ */
+static inline bool rebalance_ascend(struct maple_copy *cp,
+		struct ma_wr_state *wr_mas, struct ma_state *sib,
+		struct ma_state *parent)
+{
+	struct ma_state *mas;
+	unsigned long min, max;
+
+	mas = wr_mas->mas;
+	if (!sib->end) {
+		min = mas->min;
+		max = mas->max;
+	} else if (sib->min > mas->max) { /* Move right succeeded */
+		min = mas->min;
+		max = sib->max;
+		wr_mas->offset_end = parent->offset + 1;
+	} else {
+		min = sib->min;
+		max = mas->max;
+		wr_mas->offset_end = parent->offset;
+		parent->offset--;
+	}
+
+	cp_dst_to_slots(cp, min, max, mas);
+	if (cp_is_new_root(cp, mas))
+		return false;
+
+	if (cp->d_count == 1 && !sib->end) {
+		cp->dst[0].node->parent = ma_parent_ptr(mas_mn(mas)->parent);
+		return false;
+	}
+
+	cp->height++;
+	mas->node = parent->node;
+	mas->offset = parent->offset;
+	mas->min = parent->min;
+	mas->max = parent->max;
+	mas->end = parent->end;
+	mas->depth = parent->depth;
+	wr_mas_setup(wr_mas, mas);
+	return true;
+}
+
 /*
  * mas_rebalance() - Rebalance a given node.
  * @mas: The maple state
@@ -4372,16 +4539,47 @@ static noinline_for_kasan void mas_wr_split(struct ma_wr_state *wr_mas)
  * mas_wr_rebalance() - Insufficient data in one node needs to either get data
  * from a sibling or absorb a sibling all together.
  * @wr_mas: The write maple state
+ *
+ * Rebalance is different than a spanning store in that the write state is
+ * already at the leaf node that's being altered.
  */
-static noinline_for_kasan void mas_wr_rebalance(struct ma_wr_state *wr_mas)
+static void mas_wr_rebalance(struct ma_wr_state *wr_mas)
 {
-	struct maple_big_node b_node;
+	struct maple_enode *old_enode;
+	struct ma_state parent;
+	struct ma_state *mas;
+	struct maple_copy cp;
+	struct ma_state sib;
 
-	trace_ma_write(__func__, wr_mas->mas, 0, wr_mas->entry);
-	memset(&b_node, 0, sizeof(struct maple_big_node));
-	mas_store_b_node(wr_mas, &b_node, wr_mas->offset_end);
-	WARN_ON_ONCE(wr_mas->mas->store_type != wr_rebalance);
-	return mas_rebalance(wr_mas->mas, &b_node);
+	/*
+	 * Rebalancing occurs if a node is insufficient.  Data is rebalanced
+	 * against the node to the right if it exists, otherwise the node to the
+	 * left of this node is rebalanced against this node.  If rebalancing
+	 * causes just one node to be produced instead of two, then the parent
+	 * is also examined and rebalanced if it is insufficient.  Every level
+	 * tries to combine the data in the same way.  If one node contains the
+	 * entire range of the tree, then that node is used as a new root node.
+	 */
+
+	mas = wr_mas->mas;
+	trace_ma_op(TP_FCT, mas);
+	parent = *mas;
+	cp_leaf_init(&cp, mas, wr_mas, wr_mas);
+	do {
+		if (!mte_is_root(parent.node)) {
+			mas_ascend(&parent);
+			parent.end = mas_data_end(&parent);
+		}
+		rebalance_data(&cp, wr_mas, &sib, &parent);
+		multi_src_setup(&cp, wr_mas, wr_mas, &sib);
+		dst_setup(&cp, mas, wr_mas->type);
+		cp_data_write(&cp, mas);
+	} while (rebalance_ascend(&cp, wr_mas, &sib, &parent));
+
+	old_enode = mas->node;
+	mas->node = mt_slot_locked(mas->tree, cp.slot, 0);
+	mas_wmb_replace(mas, old_enode, cp.height);
+	mtree_range_walk(mas);
 }
 
 /*
-- 
2.47.3

On Wed, Jan 21, 2026 at 11:45:19AM -0500, Liam R. Howlett wrote:
> Stop using the maple big node for rebalance operations by changing to
> more align with spanning store.  The rebalance operation needs its own
> data calculation in rebalance_data().
> 
> In the event of too much data, the rebalance tries to push the data
> using push_data_sib().  If there is insufficient data, the rebalance
> operation will rebalance against a sibling (found with rebalance_sib()).

I'm seeing a test failure in the LTP linkat02 test on arm64 which we're
also seeing on a range of platforms in the Arm lab.  A NULL pointer
deference is generated handling the syscall in the updated code (log for
the actual next-20260126 commit):

[  361.882849] /opt/kirk/kirk[432]: linkat02: start (command: linkat02)

....

[  362.680362] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000

...

[  362.917911]  __pi_memset_generic (arch/arm64/lib/memset.S:198) (P)
[  362.922582]  mas_wr_rebalance (lib/maple_tree.c:3497)
[  362.926723]  mas_wr_store_entry (lib/maple_tree.c:3534)
[  362.930953]  mas_erase (lib/maple_tree.c:1125 lib/maple_tree.c:4981 lib/maple_tree.c:5590)
[  362.934390]  mtree_erase (lib/maple_tree.c:5916)
[  362.937827]  simple_offset_remove (fs/libfs.c:260 fs/libfs.c:335)
[  362.942057]  shmem_unlink (mm/shmem.c:3999)
[  362.945583]  vfs_unlink (fs/namei.c:5470)
[  362.949020]  filename_unlinkat (fs/namei.c:5540 (discriminator 1))
[  362.953162]  __arm64_sys_unlinkat (fs/namei.c:5569 (discriminator 1) fs/namei.c:5561 (discriminator 1) fs/namei.c:5561 (discriminator 1))
[  362.957391]  invoke_syscall (arch/arm64/include/asm/current.h:19 arch/arm64/kernel/syscall.c:54)

Full log:

   https://lava.sirena.org.uk/scheduler/job/2407192#L3795

These appear to bisect to this commit, there were some issues with the
setup of the bisect which fortunately don't seem to have confused things
and some timeouts stopped the last couple of jobs completing but we've
got adjacent commits showing passes and fails and of the two candidates
the other is a refactoring that doesn't look at all plausible.  I'm
rerunning a clean bisect but expect it to confirm this result.

# good: [50814c5ce8d8f6751fd49c818abeb8853f8be2df] Merge branch 'for-linux-next-fixes' of https://gitlab.freedesktop.org/drm/misc/kernel.git

...

# bad: [a85cfbd09f2d2f3bfab8fbe8246d0ae43a0c1628] Merge branch 'master' of https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git
git bisect bad a85cfbd09f2d2f3bfab8fbe8246d0ae43a0c1628
# test job: [75fe66db9e85a2fd9743f7598a2aaea9eb5fbfd7] https://lava.sirena.org.uk/scheduler/job/2407316
# bad: [75fe66db9e85a2fd9743f7598a2aaea9eb5fbfd7] Merge branch 'xtensa-for-next' of https://github.com/jcmvbkbc/linux-xtensa.git
git bisect bad 75fe66db9e85a2fd9743f7598a2aaea9eb5fbfd7
# test job: [0578997f52fb9a1b9adfc5fe5a95ceab4bb331d2] https://lava.sirena.org.uk/scheduler/job/2407382
# bad: [0578997f52fb9a1b9adfc5fe5a95ceab4bb331d2] Merge branch 'soc_fsl' of https://git.kernel.org/pub/scm/linux/kernel/git/chleroy/linux.git
git bisect bad 0578997f52fb9a1b9adfc5fe5a95ceab4bb331d2
# test job: [a85886367078a64dcffefe0ccd9054f6237b791a] https://lava.sirena.org.uk/scheduler/job/2407432
# bad: [a85886367078a64dcffefe0ccd9054f6237b791a] Merge branch 'mm-unstable' of https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
git bisect bad a85886367078a64dcffefe0ccd9054f6237b791a
# test job: [3b545d6116fcf6d257bf2d50e7607351fdc81b76] https://lava.sirena.org.uk/scheduler/job/2407463
# good: [3b545d6116fcf6d257bf2d50e7607351fdc81b76] mm/memory: add tree limit to free_pgtables()
git bisect good 3b545d6116fcf6d257bf2d50e7607351fdc81b76
# test job: [8d2b3ef6f7d7b0a531c4c733224583af946a424b] https://lava.sirena.org.uk/scheduler/job/2407522
# good: [8d2b3ef6f7d7b0a531c4c733224583af946a424b] maple_tree: inline mas_wr_spanning_rebalance()
git bisect good 8d2b3ef6f7d7b0a531c4c733224583af946a424b
# test job: [b75bed193d677f6ae26df8851f4d5546fb7d3599] https://lava.sirena.org.uk/scheduler/job/2407554
# good: [b75bed193d677f6ae26df8851f4d5546fb7d3599] tsacct: skip all kernel threads
git bisect good b75bed193d677f6ae26df8851f4d5546fb7d3599
# test job: [4aededd81f86a8090ea8c294071425aa12116ef8] https://lava.sirena.org.uk/scheduler/job/2407597
# good: [4aededd81f86a8090ea8c294071425aa12116ef8] Merge branch 'pin-init-next' of https://github.com/Rust-for-Linux/linux.git
git bisect good 4aededd81f86a8090ea8c294071425aa12116ef8
# test job: [201b27d852d1aecf3abce28721c6004ec2690b8d] https://lava.sirena.org.uk/scheduler/job/2407634
# good: [201b27d852d1aecf3abce28721c6004ec2690b8d] Merge branch 'mm-nonmm-stable' of https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
git bisect good 201b27d852d1aecf3abce28721c6004ec2690b8d
# test job: [7bc25a7aa0443b3beb3610e505d3147eece02766] https://lava.sirena.org.uk/scheduler/job/2407673
# bad: [7bc25a7aa0443b3beb3610e505d3147eece02766] maple_tree: add cp_converged() helper
git bisect bad 7bc25a7aa0443b3beb3610e505d3147eece02766
# test job: [a2c17a4f4db66772701547fc30f66d1df2fceafb] https://lava.sirena.org.uk/scheduler/job/2407724
# good: [a2c17a4f4db66772701547fc30f66d1df2fceafb] maple_tree: add cp_is_new_root() helper
git bisect good a2c17a4f4db66772701547fc30f66d1df2fceafb
# test job: [525e5511c009c0d6725e534134ec31eeba148da0] https://lava.sirena.org.uk/scheduler/job/2407765
# bad: [525e5511c009c0d6725e534134ec31eeba148da0] maple_tree: add copy_tree_location() helper
git bisect bad 525e5511c009c0d6725e534134ec31eeba148da0
# test job: [6ad069085c621d39fad4d1835af7e563975dcf7e] https://lava.sirena.org.uk/scheduler/job/2407822
# skip: [6ad069085c621d39fad4d1835af7e563975dcf7e] maple_tree: use maple copy node for mas_wr_rebalance() operation
git bisect skip 6ad069085c621d39fad4d1835af7e563975dcf7e
# only skipped commits left to test
# possible first bad commit: [525e5511c009c0d6725e534134ec31eeba148da0] maple_tree: add copy_tree_location() helper
# possible first bad commit: [6ad069085c621d39fad4d1835af7e563975dcf7e] maple_tree: use maple copy node for mas_wr_rebalance() operation

On Tue, Jan 27, 2026 at 11:05:54PM +0000, Mark Brown wrote:
> On Wed, Jan 21, 2026 at 11:45:19AM -0500, Liam R. Howlett wrote:

> > Stop using the maple big node for rebalance operations by changing to
> > more align with spanning store.  The rebalance operation needs its own
> > data calculation in rebalance_data().

> > In the event of too much data, the rebalance tries to push the data
> > using push_data_sib().  If there is insufficient data, the rebalance
> > operation will rebalance against a sibling (found with rebalance_sib()).

> These appear to bisect to this commit, there were some issues with the
> setup of the bisect which fortunately don't seem to have confused things
> and some timeouts stopped the last couple of jobs completing but we've
> got adjacent commits showing passes and fails and of the two candidates
> the other is a refactoring that doesn't look at all plausible.  I'm
> rerunning a clean bisect but expect it to confirm this result.

Confirmed:

git bisect start
# status: waiting for both good and bad commits
# bad: [615aad0f61e0c7a898184a394dc895c610100d4f] Add linux-next specific files for 20260126
git bisect bad 615aad0f61e0c7a898184a394dc895c610100d4f
# status: waiting for good commit(s), bad commit known
# good: [50814c5ce8d8f6751fd49c818abeb8853f8be2df] Merge branch 'for-linux-next-fixes' of https://gitlab.freedesktop.org/drm/misc/kernel.git
git bisect good 50814c5ce8d8f6751fd49c818abeb8853f8be2df
# bad: [b047f48069330e050431e9ad762bd838af43337f] Merge branch 'mtd/next' of https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git
git bisect bad b047f48069330e050431e9ad762bd838af43337f
# bad: [75fe66db9e85a2fd9743f7598a2aaea9eb5fbfd7] Merge branch 'xtensa-for-next' of https://github.com/jcmvbkbc/linux-xtensa.git
git bisect bad 75fe66db9e85a2fd9743f7598a2aaea9eb5fbfd7
# bad: [0578997f52fb9a1b9adfc5fe5a95ceab4bb331d2] Merge branch 'soc_fsl' of https://git.kernel.org/pub/scm/linux/kernel/git/chleroy/linux.git
git bisect bad 0578997f52fb9a1b9adfc5fe5a95ceab4bb331d2
# bad: [a85886367078a64dcffefe0ccd9054f6237b791a] Merge branch 'mm-unstable' of https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
git bisect bad a85886367078a64dcffefe0ccd9054f6237b791a
# good: [3b545d6116fcf6d257bf2d50e7607351fdc81b76] mm/memory: add tree limit to free_pgtables()
git bisect good 3b545d6116fcf6d257bf2d50e7607351fdc81b76
# good: [8d2b3ef6f7d7b0a531c4c733224583af946a424b] maple_tree: inline mas_wr_spanning_rebalance()
git bisect good 8d2b3ef6f7d7b0a531c4c733224583af946a424b
# good: [b75bed193d677f6ae26df8851f4d5546fb7d3599] tsacct: skip all kernel threads
git bisect good b75bed193d677f6ae26df8851f4d5546fb7d3599
# good: [4aededd81f86a8090ea8c294071425aa12116ef8] Merge branch 'pin-init-next' of https://github.com/Rust-for-Linux/linux.git
git bisect good 4aededd81f86a8090ea8c294071425aa12116ef8
# good: [201b27d852d1aecf3abce28721c6004ec2690b8d] Merge branch 'mm-nonmm-stable' of https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
git bisect good 201b27d852d1aecf3abce28721c6004ec2690b8d
# bad: [7bc25a7aa0443b3beb3610e505d3147eece02766] maple_tree: add cp_converged() helper
git bisect bad 7bc25a7aa0443b3beb3610e505d3147eece02766
# good: [a2c17a4f4db66772701547fc30f66d1df2fceafb] maple_tree: add cp_is_new_root() helper
git bisect good a2c17a4f4db66772701547fc30f66d1df2fceafb
# bad: [525e5511c009c0d6725e534134ec31eeba148da0] maple_tree: add copy_tree_location() helper
git bisect bad 525e5511c009c0d6725e534134ec31eeba148da0
# bad: [6ad069085c621d39fad4d1835af7e563975dcf7e] maple_tree: use maple copy node for mas_wr_rebalance() operation
git bisect bad 6ad069085c621d39fad4d1835af7e563975dcf7e
# first bad commit: [6ad069085c621d39fad4d1835af7e563975dcf7e] maple_tree: use maple copy node for mas_wr_rebalance() operation

* Mark Brown <broonie@kernel.org> [260128 05:53]:
> On Tue, Jan 27, 2026 at 11:05:54PM +0000, Mark Brown wrote:
> > On Wed, Jan 21, 2026 at 11:45:19AM -0500, Liam R. Howlett wrote:
> 
> > > Stop using the maple big node for rebalance operations by changing to
> > > more align with spanning store.  The rebalance operation needs its own
> > > data calculation in rebalance_data().
> 
> > > In the event of too much data, the rebalance tries to push the data
> > > using push_data_sib().  If there is insufficient data, the rebalance
> > > operation will rebalance against a sibling (found with rebalance_sib()).
> 
> > These appear to bisect to this commit, there were some issues with the
> > setup of the bisect which fortunately don't seem to have confused things
> > and some timeouts stopped the last couple of jobs completing but we've
> > got adjacent commits showing passes and fails and of the two candidates
> > the other is a refactoring that doesn't look at all plausible.  I'm
> > rerunning a clean bisect but expect it to confirm this result.
> 
> Confirmed:
> 
> # first bad commit: [6ad069085c621d39fad4d1835af7e563975dcf7e] maple_tree: use maple copy node for mas_wr_rebalance() operation


Thanks for bisecting and the test name (linkat02 on arm64) from ltp, I
really appreciate the details on this.

I'm working on a fix.  Please let me know if any other platforms or
tests showed errors and I'll try them here before it's re-added to
-next.

Cheers,
Liam

On Wed, Jan 28, 2026 at 09:36:51AM -0500, Liam R. Howlett wrote:
> * Mark Brown <broonie@kernel.org> [260128 05:53]:

> > # first bad commit: [6ad069085c621d39fad4d1835af7e563975dcf7e] maple_tree: use maple copy node for mas_wr_rebalance() operation

> Thanks for bisecting and the test name (linkat02 on arm64) from ltp, I
> really appreciate the details on this.

> I'm working on a fix.  Please let me know if any other platforms or
> tests showed errors and I'll try them here before it's re-added to
> -next.

I've not noticed anything else showing this, but I'm not running LTP on
anything except arm64 and it wouldn't surprise me if the same test were
to fail on other architectures.  No other reports internally either.

On Tue, 27 Jan 2026 23:05:48 +0000 Mark Brown <broonie@kernel.org> wrote:

> On Wed, Jan 21, 2026 at 11:45:19AM -0500, Liam R. Howlett wrote:
> > Stop using the maple big node for rebalance operations by changing to
> > more align with spanning store.  The rebalance operation needs its own
> > data calculation in rebalance_data().
> > 
> > In the event of too much data, the rebalance tries to push the data
> > using push_data_sib().  If there is insufficient data, the rebalance
> > operation will rebalance against a sibling (found with rebalance_sib()).
> 
> I'm seeing a test failure in the LTP linkat02 test on arm64 which we're
> also seeing on a range of platforms in the Arm lab.  A NULL pointer
> deference is generated handling the syscall in the updated code (log for
> the actual next-20260126 commit):

Cool, thanks.

Liam, I'll move this series back into mm-new to avoid disrupting
linux-next testing.

* Andrew Morton <akpm@linux-foundation.org> [260127 18:16]:
> On Tue, 27 Jan 2026 23:05:48 +0000 Mark Brown <broonie@kernel.org> wrote:
> 
> > On Wed, Jan 21, 2026 at 11:45:19AM -0500, Liam R. Howlett wrote:
> > > Stop using the maple big node for rebalance operations by changing to
> > > more align with spanning store.  The rebalance operation needs its own
> > > data calculation in rebalance_data().
> > > 
> > > In the event of too much data, the rebalance tries to push the data
> > > using push_data_sib().  If there is insufficient data, the rebalance
> > > operation will rebalance against a sibling (found with rebalance_sib()).
> > 
> > I'm seeing a test failure in the LTP linkat02 test on arm64 which we're
> > also seeing on a range of platforms in the Arm lab.  A NULL pointer
> > deference is generated handling the syscall in the updated code (log for
> > the actual next-20260126 commit):
> 
> Cool, thanks.
> 
> Liam, I'll move this series back into mm-new to avoid disrupting
> linux-next testing.
> 
> 

I know you like fixup patches on larger sets, but I've done three things
to the patch set now:

1. A small fix for this issue
2. Added a new test in its own patch for this issue
3. Cleaned up the old compiler pointer warning in a more readable way

Would you like me to send the delta or a new patch set?

Thanks,
Liam

On Fri, 30 Jan 2026 11:42:49 -0500 "Liam R. Howlett" <Liam.Howlett@oracle.com> wrote:

> * Andrew Morton <akpm@linux-foundation.org> [260127 18:16]:
> > On Tue, 27 Jan 2026 23:05:48 +0000 Mark Brown <broonie@kernel.org> wrote:
> > 
> > > On Wed, Jan 21, 2026 at 11:45:19AM -0500, Liam R. Howlett wrote:
> > > > Stop using the maple big node for rebalance operations by changing to
> > > > more align with spanning store.  The rebalance operation needs its own
> > > > data calculation in rebalance_data().
> > > > 
> > > > In the event of too much data, the rebalance tries to push the data
> > > > using push_data_sib().  If there is insufficient data, the rebalance
> > > > operation will rebalance against a sibling (found with rebalance_sib()).
> > > 
> > > I'm seeing a test failure in the LTP linkat02 test on arm64 which we're
> > > also seeing on a range of platforms in the Arm lab.  A NULL pointer
> > > deference is generated handling the syscall in the updated code (log for
> > > the actual next-20260126 commit):
> > 
> > Cool, thanks.
> > 
> > Liam, I'll move this series back into mm-new to avoid disrupting
> > linux-next testing.
> > 
> > 
> 
> I know you like fixup patches on larger sets, but I've done three things
> to the patch set now:
> 
> 1. A small fix for this issue
> 2. Added a new test in its own patch for this issue
> 3. Cleaned up the old compiler pointer warning in a more readable way
> 
> Would you like me to send the delta or a new patch set?

A new patchset works.  I'll send my heres-what-changed-since v2 email to
aid people who reviewed v2 and so you can scan it and think "yup, I
meant to do that".