Re: [syzbot] [mm?] kernel BUG in collapse_scan_file

David Hildenbrand (Arm)
2026-03-19T09:00:10Z

On 3/19/26 09:53, Lorenzo Stoakes (Oracle) wrote:
> On Thu, Mar 19, 2026 at 04:05:38PM +0800, Lance Yang wrote:
>> Ccing Willy
>>
>> IIUC, this is a dup of the earlier report[1], which I looked into back
>> in January. The root cause is the same: collapse_file() calls
>> xas_lock_irq() without resetting the xas state first, tripping the
>> XAS_INVALID() assertion:
>>
>> #define xas_lock_irq(xas) xa_lock_irq(XAS_INVALID(xas)->xa)
>>
>> static inline struct xa_state *XAS_INVALID(struct xa_state *xas)
>> {
>> XA_NODE_BUG_ON(xas->xa_node, xas_valid(xas));
>> return xas;
>> }
>>
>> Added by commit:
>>
>> commit 43b00759f21b10142094d1ae5ff65cbb368953a3
>> Author: Matthew Wilcox (Oracle) <willy@infradead.org>
>> Date: Sun Dec 14 10:53:31 2025 -0500
>>
>> XArray: Add extra debugging check to xas_lock and friends
>>
>> While tracking down a recent bug, we discovered somewhere that had
>> forgotten to call xas_reset() before calling xas_lock(). Add a debug
>> check to be sure that doesn't happen in future and fix all the places in
>> the test suite which were carelessly doing just this.
>>
>> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
>> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
>>
>> I posted a HACK fix at the time[2], but David pointed out that Willy
>> had mentioned it likely needs more thought[3].
>
> Hmm we shouldn't leave this bug in place while working for a fancier fix??
>
> Can we get _something_ going as an upstream fix? We can improve whatever we do
> later right?
>
> David, thoughts?

I recall Willy mentioning that the issue is likely a false positive.

IIUC, that commit is not upstream? So it only triggers in linux-next.

Which means:

1) If it's a false positive, upstream is not effected (no XA_NODE_BUG_ON)

2) If it's not a false positive, upstream is effected but does not
trigger the XA_NODE_BUG_ON

--
Cheers,

David