linux-kernel - Re: [PATCH v2] xarray: Add a BUG_ON() to ensure caller is not sibling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <35449e83-11f2-4414-abdd-41f6cd68b4c3@arm.com>
Date: Wed, 4 Jun 2025 10:23:31 +0530
From: Dev Jain <dev.jain@....com>
To: Andrew Morton <akpm@...ux-foundation.org>
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 04/06/25 10:03 am, Andrew Morton wrote:
> 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...

Well, it jumped out to me while reading code. If the concensus is that
a BUG_ON() is totally unnecessary, I will at least prefer a comment.
I just thought that there are XA_NODE_BUG_ON()'s all over the place,
and they must be there for some good reason, so let's follow that.

>> 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.

XA_NODE_BUG_ON() depends on #ifdef XA_DEBUG(), which is defined in a tools/testing
directory...and in the future if this changes then I think that work will include
removing all XA_NODE_BUG_ON()'s...



>