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

Lance Yang
2026-03-19T09:14:21Z

On 2026/3/19 17:00, David Hildenbrand (Arm) wrote:
> 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.

Right. That does not appear to be in upstream, I only see it 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

Yep. So this particular BUG_ON is not affecting upstream directly.

That said, syzbot will likely keep hitting it in linux-next and
generating noise for us until it is addressed there ...