[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20250603213338.7d80bbe0e021052c20e1c5f5@linux-foundation.org>
Date: Tue, 3 Jun 2025 21:33:38 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Dev Jain <dev.jain@....com>
Cc: willy@...radead.org, linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, david@...hat.com, anshuman.khandual@....com,
ryan.roberts@....com, ziy@...dia.com, aneesh.kumar@...nel.org
Subject: Re: [PATCH v2] xarray: Add a BUG_ON() to ensure caller is not
sibling
On Wed, 4 Jun 2025 09:45:33 +0530 Dev Jain <dev.jain@....com> 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. For example, suppose we have a shift-6 node having an order-9
> entry => 8 - 1 = 7 siblings, so assume the slots are at offset 0 till 7 in
> this node. If xas->xa_offset is 6, then the code will compute order as
> 1 + xas->xa_node->shift = 7. Therefore, the order computation must start
> from the beginning of the multi-slot entries, that is, the non-sibling
> entry. Thus ensure that the caller is aware of this by triggering a BUG
> when the entry is a sibling entry.
Why check this thing in particular? There are a zillion things we
could check...
> Note that this BUG_ON() is only
> active while running selftests, so there is no overhead in a running
> kernel.
hm, how do we know this? Now and in the future? xa_get_order() and
xas_get_order() have callers all over the place.
Powered by blists - more mailing lists