On 30/05/25 4:17 am, Zi Yan wrote:
On 28 May 2025, at 23:17, Dev Jain wrote:

On 28/05/25 10:42 pm, Zi Yan wrote:
On 28 May 2025, at 7:31, Dev Jain wrote:

Suppose xas is pointing somewhere near the end of the multi-entry batch.
Then it may happen that the computed slot already falls beyond the batch,
thus breaking the loop due to !xa_is_sibling(), and computing the wrong
order. Thus ensure that the caller is aware of this by triggering a BUG
when the entry is a sibling entry.
Is it possible to add a test case in lib/test_xarray.c for this?
You can compile the tests with “make -C tools/testing/radix-tree”
and run “./tools/testing/radix-tree/xarray”.

Sorry forgot to Cc you.
I can surely do that later, but does this patch look fine?
I am not sure the exact situation you are describing, so I asked you
to write a test case to demonstrate the issue. :)
I added the following:
diff --git a/lib/test_xarray.c b/lib/test_xarray.c
index 080a39d22e73..44fcc947a5b6 100644
--- a/lib/test_xarray.c
+++ b/lib/test_xarray.c
@@ -2111,6 +2111,8 @@ static noinline void check_xas_get_order(struct xarray *xa)
rcu_read_lock();
xas_load(&xas);
XA_BUG_ON(xa, xas_get_order(&xas) != order);
+ if (xas.xa_node)
+ XA_BUG_ON(xa, xa_is_sibling(xa_entry(xas.xa, xas.xa_node, xas.xa_offset)));
rcu_read_unlock();
}
and the test passes.

    





          
This patch is motivated by code inspection and not a real bug report.

Signed-off-by: Dev Jain <dev.jain@arm.com>
---
The patch applies on 6.15 kernel.

  lib/xarray.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/lib/xarray.c b/lib/xarray.c
index 9644b18af18d..0f699766c24f 100644
--- a/lib/xarray.c
+++ b/lib/xarray.c
@@ -1917,6 +1917,8 @@ int xas_get_order(struct xa_state *xas)
  	if (!xas->xa_node)
  		return 0;

+	XA_NODE_BUG_ON(xas->xa_node, xa_is_sibling(xa_entry(xas->xa,
+		       xas->xa_node, xas->xa_offset)));
  	for (;;) {
  		unsigned int slot = xas->xa_offset + (1 << order);

-- 
2.30.2
Best Regards,
Yan, Zi

Best Regards,
Yan, Zi