[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ca63328b-1c57-478c-b8aa-af0974b7f188@redhat.com>
Date: Fri, 31 Oct 2025 11:40:17 +0100
From: David Hildenbrand <david@...hat.com>
To: Ackerley Tng <ackerleytng@...gle.com>, willy@...radead.org,
akpm@...ux-foundation.org, linux-fsdevel@...r.kernel.org,
linux-mm@...ck.org, linux-kernel@...r.kernel.org
Cc: michael.roth@....com, vannapurve@...gle.com
Subject: Re: Hit an assertion within lib/xarray.c from lib/test_xarray.c,
would like help debugging
On 28.10.25 23:34, Ackerley Tng wrote:
> Hi!
>
Hi!
> I'm trying to use multi-index xarrays and I was experimenting with
> test_xarray.c.
>
> I'm trying to use xa_erase() on every index after splitting the entry in the
> xarray. (and I commented out every other test case just to focus on this test)
>
> Should erasing every index within the xarray after splitting be a supported use
> case?
>
> Here's the diff:
>
> diff --git i/lib/test_xarray.c w/lib/test_xarray.c
> index 5ca0aefee9aa5..fe74f44bbbd92 100644
> --- i/lib/test_xarray.c
> +++ w/lib/test_xarray.c
> @@ -1868,6 +1868,9 @@ static void check_split_1(struct xarray *xa, unsigned long index,
> rcu_read_unlock();
> XA_BUG_ON(xa, found != 1 << (order - new_order));
>
> + for (i = 0; i < (1 << order); i++)
> + xa_erase(xa, index + i);
> +
> xa_destroy(xa);
> }
>
> And made a call to
>
> check_split_1(xa, 0, 3, 2);
>
> Here's the assertion I hit:
>
> node 0x7c4de89e01c0x offset 0 parent 0x7c4de89e0100x shift 0 count 4 values 254 array 0x55edd2dd8940x list 0x7c4de89e01d8x 0x7c4de89e01d8x marks 0 10 0
> xarray: ../shared/../../../lib/xarray.c:764: update_node: Assertion `!(1)' failed.
>
>
> I think I've narrowed down the issue to the for (;;) loop in xas_store(), which
> I believe isn't counting the `values` to be updated in update_node() correctly.
I wish i could help, but I'm not an expert on that code and it's not the
easiest code to read :) But staring at it a bit I assume you are right
on that one.
>
> Is `values += !xa_is_value(first) - !value;` intended to compute the increase in
> number of values with replacement of every slot being iterated by the new entry?
Unfortunately that I am also not 100% sure about that one.
--
Cheers
David / dhildenb
Powered by blists - more mailing lists