On Wed, 4 Jun 2025 09:45:33 +0530 Dev Jain <dev.jain@xxxxxxx> 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.
