linux-kernel - Re: [syzbot] [mm?] WARNING in xfs_init_fs

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] [day] [month] [year] [list]

Message-ID: <3d54a546-77dd-4913-bcd0-7472aec8f53c@suse.cz>
Date: Mon, 29 Sep 2025 09:05:45 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Christoph Hellwig <hch@...radead.org>,
 syzbot <syzbot+359a67b608de1ef72f65@...kaller.appspotmail.com>
Cc: akpm@...ux-foundation.org, apopple@...dia.com, baohua@...nel.org,
 byungchul@...com, cem@...nel.org, david@...morbit.com, david@...hat.com,
 gourry@...rry.net, harry.yoo@...cle.com, joshua.hahnjy@...il.com,
 linux-kernel@...r.kernel.org, linux-mm@...ck.org, linux-xfs@...r.kernel.org,
 matthew.brost@...el.com, mhocko@...e.com,
 penguin-kernel@...ove.sakura.ne.jp, rakie.kim@...com,
 syzkaller-bugs@...glegroups.com, willy@...radead.org,
 ying.huang@...ux.alibaba.com, ziy@...dia.com
Subject: Re: [syzbot] [mm?] WARNING in xfs_init_fs_context

On 9/29/25 08:40, Christoph Hellwig wrote:
> This looks like slub turning a < PAGE_SIZE allocation into a order > 0
> folio allocation, which the page allocator then complains about.

It's order-1 to order-2 but in principle yes.

> We'll either need to make slab not propagate < PAGE_SIZE allocations
> to order > 0 page allocation

It normally doesn't, but enabling debugging stuff can do that. In this case
it seems to be KASAN, but could be also slub's own redzones etc.

, or make the page allocator handle the
> latter.

It handles it, but warns you're doing something you shouldn't, as
__GFP_NOFAIL allocations shouldn't be large. We could just silence it if
it's due to debugging. SLUB could check if page allocation is bloated due to
debugging and there's __GFP_NOFAIL, and then add an extra gfp flag to
silence the warning. We could use __GFP_NOWARN with the risk of someone else
combining __GFP_NOFAIL and __GFP_NOWARN to silence this. Or invent some
other internal flag, but there's not many bits left.

> And XFS shouldn't need the NOFAIL allocation here, but this will break
> things elsewhere as well.
>