From: "Lorenzo Stoakes (Oracle)" <ljs@kernel.org>
To: Vlastimil Babka <vbabka@suse.com>
Cc: Lance Yang <lance.yang@linux.dev>,
syzbot <syzbot+8961cb270ae74b4129fb@syzkaller.appspotmail.com>,
david@kernel.org, willy@infradead.org,
Mark Brown <broonie@kernel.org>,
baolin.wang@linux.alibaba.com, npache@redhat.com,
linux-mm@kvack.org, baohua@kernel.org, ryan.roberts@arm.com,
syzkaller-bugs@googlegroups.com, dev.jain@arm.com,
ziy@nvidia.com, linux-kernel@vger.kernel.org,
Liam.Howlett@oracle.com, akpm@linux-foundation.org
Subject: Re: [syzbot] [mm?] kernel BUG in collapse_scan_file
Date: Thu, 19 Mar 2026 11:04:07 +0000 [thread overview]
Message-ID: <a94ff663-1df9-4a3c-82c9-8ae8d0f8fdc3@lucifer.local> (raw)
In-Reply-To: <5eaa234e-76e5-45ec-833d-64d76903d1bf@suse.com>
On Thu, Mar 19, 2026 at 11:56:21AM +0100, Vlastimil Babka wrote:
> On 3/19/26 09:05, 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].
> >
> > [1]
> > https://lore.kernel.org/all/69757ea0.a00a0220.33ccc7.0017.GAE@google.com/
> > [2] https://lore.kernel.org/all/20260125121001.32733-1-lance.yang@linux.dev/
> > [3]
> > https://lore.kernel.org/all/7bce9231-714c-424a-a4e3-dd42734fb767@kernel.org/
>
> That "needs more thought" was Jan 5. After 2.5 months later this is still
> messing up linux-next testing due to a known unfixed problem. Completely
> unnaceptable. Willy, you need to drop the new bug check until the known
> problem is fixed.
>
> Mark, please drop https://git.infradead.org/users/willy/xarray.git from
> linux-next until it stops breaking linux-next. Thanks.
Thanks, also I don't see a Link: tag or any discussion of this patch anywhere
on-list (maybe I missed it?) the only think a search on lore brings up is a bug
report from jan 5th [0] about it.
If this is heading for a Linus PR, could we have the patch actually posted to
lore somewhere so there can be some discussion?
And is there a way to ensure this doesn't land in the next merge window unless
it's fixed? Not sure through which tree it's going (Willy's?).
In general I'm very uncomfortable 'just leaving' splatting kernels in the
-next tree.
[0]:https://lore.kernel.org/all/aVvz3tYdu49TGkjI@mozart.vkv.me/
Thanks, Lorenzo
next prev parent reply other threads:[~2026-03-19 11:04 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-19 7:20 syzbot
2026-03-19 7:22 ` David Hildenbrand (Arm)
2026-03-19 8:05 ` Lance Yang
2026-03-19 8:53 ` Lorenzo Stoakes (Oracle)
2026-03-19 9:00 ` David Hildenbrand (Arm)
2026-03-19 9:14 ` Lance Yang
2026-03-19 9:21 ` David Hildenbrand (Arm)
2026-03-19 10:27 ` Lorenzo Stoakes (Oracle)
2026-03-19 10:59 ` David Hildenbrand (Arm)
2026-03-19 11:07 ` Lorenzo Stoakes (Oracle)
2026-03-19 11:10 ` David Hildenbrand (Arm)
2026-03-19 11:12 ` Lorenzo Stoakes (Oracle)
2026-03-19 10:56 ` Vlastimil Babka
2026-03-19 11:04 ` Lorenzo Stoakes (Oracle) [this message]
2026-03-19 12:17 ` Mark Brown
2026-03-20 12:39 ` Mark Brown
2026-03-20 13:17 ` Lorenzo Stoakes (Oracle)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a94ff663-1df9-4a3c-82c9-8ae8d0f8fdc3@lucifer.local \
--to=ljs@kernel.org \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=broonie@kernel.org \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=lance.yang@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=npache@redhat.com \
--cc=ryan.roberts@arm.com \
--cc=syzbot+8961cb270ae74b4129fb@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=vbabka@suse.com \
--cc=willy@infradead.org \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox