Re: [syzbot] [mm?] WARNING in xfs_init_fs_context

Re: [syzbot] [mm?] WARNING in xfs_init_fs_context

[Vlastimil Babka]

+CC xfs and few more

On 7/2/25 3:41 AM, Tetsuo Handa wrote:
> On 2025/07/02 0:01, Zi Yan wrote:
>>>  __alloc_frozen_pages_noprof+0x319/0x370 mm/page_alloc.c:4972
>>>  alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2419
>>>  alloc_slab_page mm/slub.c:2451 [inline]
>>>  allocate_slab+0xe2/0x3b0 mm/slub.c:2627
>>>  new_slab mm/slub.c:2673 [inline]
>>
>> new_slab() allows __GFP_NOFAIL, since GFP_RECLAIM_MASK has it.
>> In allocate_slab(), the first allocation without __GFP_NOFAIL
>> failed, the retry used __GFP_NOFAIL but kmem_cache order
>> was greater than 1, which led to the warning above.
>>
>> Maybe allocate_slab() should just fail when kmem_cache
>> order is too big and first trial fails? I am no expert,
>> so add Vlastimil for help.

Thanks Zi. Slab shouldn't fail with __GFP_NOFAIL, that would only lead
to subsystems like xfs to reintroduce their own forever retrying
wrappers again. I think it's going the best it can for the fallback
attempt by using the minimum order, so the warning will never happen due
to the calculated optimal order being too large, but only if the
kmalloc()/kmem_cache_alloc() requested/object size is too large itself.

Hm but perhaps enabling slab_debug can inflate it over the threshold, is
it the case here? I think in that rare case we could convert such
fallback allocations to large kmalloc to avoid adding the debugging
overhead - we can't easily create an individual slab page without the
debugging layout for a kmalloc cache with debugging enabled.

>> Barry, who added the nofail
>> warning is cc’d.

Barry's commit 903edea6c53f0 reorganized the warnings, but it existed
already long before.

> Indeed. In allocate_slab(struct kmem_cache *s, gfp_t flags, int node),
> 
> 	/*
> 	 * Let the initial higher-order allocation fail under memory pressure
> 	 * so we fall-back to the minimum order allocation.
> 	 */
> 	alloc_gfp = (flags | __GFP_NOWARN | __GFP_NORETRY) & ~__GFP_NOFAIL;
> 	if ((alloc_gfp & __GFP_DIRECT_RECLAIM) && oo_order(oo) > oo_order(s->min))
> 		alloc_gfp = (alloc_gfp | __GFP_NOMEMALLOC) & ~__GFP_RECLAIM;
> 
> 	slab = alloc_slab_page(alloc_gfp, node, oo);
> 	if (unlikely(!slab)) {
> 		oo = s->min;
> 		alloc_gfp = flags;
> 		/*
> 		 * Allocation may have failed due to fragmentation.
> 		 * Try a lower order alloc if possible
> 		 */
> 		slab = alloc_slab_page(alloc_gfp, node, oo);
> 
> __GFP_NOFAIL needs to be dropped unless s->min is either 0 or 1.

No, that would violate __GFP_NOFAIL semantics.

> 
> 		if (unlikely(!slab))
> 			return NULL;
> 		stat(s, ORDER_FALLBACK);
> 	}
> 
> 
> 
> By the way, why is xfs_init_fs_context() using __GFP_NOFAIL ?
> 
> 	mp = kzalloc(sizeof(struct xfs_mount), GFP_KERNEL | __GFP_NOFAIL);
> 	if (!mp)
> 		return -ENOMEM;
> 
> This looks an allocation attempt which can fail safely.

Indeed. Dave Chinner's commit f078d4ea82760 ("xfs: convert kmem_alloc()
to kmalloc()") dropped the xfs wrapper. This allocation didn't use
KM_MAYFAIL so it got __GFP_NOFAIL. The commit mentions this high-order
nofail issue for another allocation site that had to use xlog_kvmalloc().

I think either this allocation really can fail as the code (return
-ENOMEM) suggests and thus can drop __GFP_NOFAIL, or it can use
kvmalloc() - I think the wrapper for that can be removed now too after
the discussion in [1] resulted in commit 46459154f997 ("mm: kvmalloc:
make kmalloc fast path real fast path").

[1] https://lore.kernel.org/all/Z_XI6vBE8v_cIhjZ@dread.disaster.area/

Re: [syzbot] [mm?] WARNING in xfs_init_fs_context

[Harry Yoo]

On Wed, Jul 02, 2025 at 09:30:30AM +0200, Vlastimil Babka wrote:
> +CC xfs and few more
> 
> On 7/2/25 3:41 AM, Tetsuo Handa wrote:
> > On 2025/07/02 0:01, Zi Yan wrote:
> >>>  __alloc_frozen_pages_noprof+0x319/0x370 mm/page_alloc.c:4972
> >>>  alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2419
> >>>  alloc_slab_page mm/slub.c:2451 [inline]
> >>>  allocate_slab+0xe2/0x3b0 mm/slub.c:2627
> >>>  new_slab mm/slub.c:2673 [inline]
> >>
> >> new_slab() allows __GFP_NOFAIL, since GFP_RECLAIM_MASK has it.
> >> In allocate_slab(), the first allocation without __GFP_NOFAIL
> >> failed, the retry used __GFP_NOFAIL but kmem_cache order
> >> was greater than 1, which led to the warning above.
> >>
> >> Maybe allocate_slab() should just fail when kmem_cache
> >> order is too big and first trial fails? I am no expert,
> >> so add Vlastimil for help.
> 
> Thanks Zi. Slab shouldn't fail with __GFP_NOFAIL, that would only lead
> to subsystems like xfs to reintroduce their own forever retrying
> wrappers again. I think it's going the best it can for the fallback
> attempt by using the minimum order, so the warning will never happen due
> to the calculated optimal order being too large, but only if the
> kmalloc()/kmem_cache_alloc() requested/object size is too large itself.

Right. The warning would trigger only if the object size is bigger
than 8k (PAGE_SIZE * 2).

> Hm but perhaps enabling slab_debug can inflate it over the threshold, is
> it the case here?

CONFIG_CMDLINE="earlyprintk=serial net.ifnames=0 sysctl.kernel.hung_task_all_cpu_backtrace=1 ima_policy=tcb nf-conntrack-ftp.ports=20000 nf-conntrack-tftp.ports=20000 nf-conntrack-sip.ports=20000 nf-conntrack-irc.ports=20000 nf-conntrack-sane.ports=20000 binder.debug_mask=0 rcupdate.rcu_expedited=1 rcupdate.rcu_cpu_stall_cputime=1 no_hash_pointers page_owner=on sysctl.vm.nr_hugepages=4 sysctl.vm.nr_overcommit_hugepages=4 secretmem.enable=1 sysctl.max_rcu_stall_to_panic=1 msr.allow_writes=off coredump_filter=0xffff root=/dev/sda console=ttyS0 vsyscall=native numa=fake=2 kvm-intel.nested=1 spec_store_bypass_disable=prctl nopcid vivid.n_devs=64 vivid.multiplanar=1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2 netrom.nr_ndevs=32 rose.rose_ndevs=32 smp.csd_lock_timeout=100000 watchdog_thresh=55 workqueue.watchdog_thresh=140 sysctl.net.core.netdev_unregister_timeout_secs=140 dummy_hcd.num=32 max_loop=32 nbds_max=32 panic_on_warn=1"

CONFIG_SLUB_DEBUG=y
# CONFIG_SLUB_DEBUG_ON is not set

It seems no slab_debug is involved here.

I downloaded the config and built the kernel, and
sizeof(struct xfs_mount) is 4480 bytes. It should have allocated using
order 1?

Not sure why the min order was greater than 1?
Not sure what I'm missing...

> I think in that rare case we could convert such
> fallback allocations to large kmalloc to avoid adding the debugging
> overhead - we can't easily create an individual slab page without the
> debugging layout for a kmalloc cache with debugging enabled.

Yeah that can be doable when the size is exactly 8k or very close to 8k.

-- 
Cheers,
Harry / Hyeonggon

Re: [syzbot] [mm?] WARNING in xfs_init_fs_context

[Vlastimil Babka]

On 7/4/25 10:26, Harry Yoo wrote:
> On Wed, Jul 02, 2025 at 09:30:30AM +0200, Vlastimil Babka wrote:
>> +CC xfs and few more
>> 
>> On 7/2/25 3:41 AM, Tetsuo Handa wrote:
>> > On 2025/07/02 0:01, Zi Yan wrote:
>> >>>  __alloc_frozen_pages_noprof+0x319/0x370 mm/page_alloc.c:4972
>> >>>  alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2419
>> >>>  alloc_slab_page mm/slub.c:2451 [inline]
>> >>>  allocate_slab+0xe2/0x3b0 mm/slub.c:2627
>> >>>  new_slab mm/slub.c:2673 [inline]
>> >>
>> >> new_slab() allows __GFP_NOFAIL, since GFP_RECLAIM_MASK has it.
>> >> In allocate_slab(), the first allocation without __GFP_NOFAIL
>> >> failed, the retry used __GFP_NOFAIL but kmem_cache order
>> >> was greater than 1, which led to the warning above.
>> >>
>> >> Maybe allocate_slab() should just fail when kmem_cache
>> >> order is too big and first trial fails? I am no expert,
>> >> so add Vlastimil for help.
>> 
>> Thanks Zi. Slab shouldn't fail with __GFP_NOFAIL, that would only lead
>> to subsystems like xfs to reintroduce their own forever retrying
>> wrappers again. I think it's going the best it can for the fallback
>> attempt by using the minimum order, so the warning will never happen due
>> to the calculated optimal order being too large, but only if the
>> kmalloc()/kmem_cache_alloc() requested/object size is too large itself.
> 
> Right. The warning would trigger only if the object size is bigger
> than 8k (PAGE_SIZE * 2).
> 
>> Hm but perhaps enabling slab_debug can inflate it over the threshold, is
>> it the case here?
> 
> CONFIG_CMDLINE="earlyprintk=serial net.ifnames=0 sysctl.kernel.hung_task_all_cpu_backtrace=1 ima_policy=tcb nf-conntrack-ftp.ports=20000 nf-conntrack-tftp.ports=20000 nf-conntrack-sip.ports=20000 nf-conntrack-irc.ports=20000 nf-conntrack-sane.ports=20000 binder.debug_mask=0 rcupdate.rcu_expedited=1 rcupdate.rcu_cpu_stall_cputime=1 no_hash_pointers page_owner=on sysctl.vm.nr_hugepages=4 sysctl.vm.nr_overcommit_hugepages=4 secretmem.enable=1 sysctl.max_rcu_stall_to_panic=1 msr.allow_writes=off coredump_filter=0xffff root=/dev/sda console=ttyS0 vsyscall=native numa=fake=2 kvm-intel.nested=1 spec_store_bypass_disable=prctl nopcid vivid.n_devs=64 vivid.multiplanar=1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2 netrom.nr_ndevs=32 rose.rose_ndevs=32 smp.csd_lock_timeout=100000 watchdog_thresh=55 workqueue.watchdog_thresh=140 sysctl.net.core.netdev_unregister_timeout_secs=140 dummy_hcd.num=32 max_loop=32 nbds_max=32 panic_on_warn=1"
> 
> CONFIG_SLUB_DEBUG=y
> # CONFIG_SLUB_DEBUG_ON is not set
> 
> It seems no slab_debug is involved here.
> 
> I downloaded the config and built the kernel, and
> sizeof(struct xfs_mount) is 4480 bytes. It should have allocated using
> order 1?

So it should be the kmalloc-8k cache, its min order should be get_order(8k)
thus 1. If the object was larger than 8k it would be a large kmalloc anyway
and also trigger the __GFP_NOFAIL warning but with a different stacktrace.

> Not sure why the min order was greater than 1?
> Not sure what I'm missing...

The only sane explanation is that slab debugging is enabled but not via
CONFIG_CMDLINE but via options passed to the qemu execution? But I don't see
those, nor the full dmesg (that would report them) in the syzbot dashboard.

Hm or actually it might be kasan_cache_create() bumping our size when called
from calculate_sizes(). KASAN seems enabled...

>> I think in that rare case we could convert such
>> fallback allocations to large kmalloc to avoid adding the debugging
>> overhead - we can't easily create an individual slab page without the
>> debugging layout for a kmalloc cache with debugging enabled.
> 
> Yeah that can be doable when the size is exactly 8k or very close to 8k.
> 

Re: [syzbot] [mm?] WARNING in xfs_init_fs_context

[Dave Chinner]

On Wed, Jul 02, 2025 at 09:30:30AM +0200, Vlastimil Babka wrote:
> On 7/2/25 3:41 AM, Tetsuo Handa wrote:
> > By the way, why is xfs_init_fs_context() using __GFP_NOFAIL ?
> > 
> > 	mp = kzalloc(sizeof(struct xfs_mount), GFP_KERNEL | __GFP_NOFAIL);
> > 	if (!mp)
> > 		return -ENOMEM;
> > 
> > This looks an allocation attempt which can fail safely.

It's irrelevant - it shouldn't fail regardless of __GFP_NOFAIL being
specified.

> Indeed. Dave Chinner's commit f078d4ea82760 ("xfs: convert kmem_alloc()
> to kmalloc()") dropped the xfs wrapper. This allocation didn't use
> KM_MAYFAIL so it got __GFP_NOFAIL. The commit mentions this high-order
> nofail issue for another allocation site that had to use xlog_kvmalloc().

I don't see how high-order allocation behaviour is relevant here.

Pahole says the struct xfs_mount is 4224 bytes in length. It is an
order-1 allocation and if we've fragmented memory so badly that slab
can't allocate an order-1 page then *lots* of other stuff is going
to be stalling. (e.g. slab pages for inodes are typically order-3,
same as the kmalloc-8kk slab).

Note that the size of the structure is largely because of the
embedded cpumask for inodegc:

	struct cpumask             m_inodegc_cpumask;    /*  3104  1024 */

This should probably be pulled out into a dynamically allocated
inodegc specific structure. Then the struct xfs_mount is only a
order-0 allocation and should never fail, regardless of
__GFP_NOFAIL being specified or not.

> I think either this allocation really can fail as the code (return
> -ENOMEM) suggests and thus can drop __GFP_NOFAIL, or it can use
> kvmalloc() - I think the wrapper for that can be removed now too after
> the discussion in [1] resulted in commit 46459154f997 ("mm: kvmalloc:
> make kmalloc fast path real fast path").

I know about that - I have patches that I'm testing that replace
xlog_kvmalloc() with kvmalloc calls.

-Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: [syzbot] [mm?] WARNING in xfs_init_fs_context

[Vlastimil Babka]

On 7/8/25 00:10, Dave Chinner wrote:
> On Wed, Jul 02, 2025 at 09:30:30AM +0200, Vlastimil Babka wrote:
>> On 7/2/25 3:41 AM, Tetsuo Handa wrote:
>> > By the way, why is xfs_init_fs_context() using __GFP_NOFAIL ?
>> > 
>> > 	mp = kzalloc(sizeof(struct xfs_mount), GFP_KERNEL | __GFP_NOFAIL);
>> > 	if (!mp)
>> > 		return -ENOMEM;
>> > 
>> > This looks an allocation attempt which can fail safely.
> 
> It's irrelevant - it shouldn't fail regardless of __GFP_NOFAIL being
> specified.

If you mean the "too small to fail" behavior then it's generally true,
except in some corner cases like being an oom victim, in which case the
allocation can fail - the userspace process is doomed anyway. But a (small)
kernel allocation not handling NULL would still need __GFP_NOFAIL to prevent
that corner case.

>> Indeed. Dave Chinner's commit f078d4ea82760 ("xfs: convert kmem_alloc()
>> to kmalloc()") dropped the xfs wrapper. This allocation didn't use
>> KM_MAYFAIL so it got __GFP_NOFAIL. The commit mentions this high-order
>> nofail issue for another allocation site that had to use xlog_kvmalloc().
> 
> I don't see how high-order allocation behaviour is relevant here.
> 
> Pahole says the struct xfs_mount is 4224 bytes in length. It is an
> order-1 allocation and if we've fragmented memory so badly that slab
> can't allocate an order-1 page then *lots* of other stuff is going
> to be stalling. (e.g. slab pages for inodes are typically order-3,
> same as the kmalloc-8kk slab).

Elsewhere in this thread we figured it out since I wrote the quoted reply.
4224 bytes means kmalloc-8k where the fallback allocation (the one that
passes on the __GFP_NOFAIL) order is 1 normally. But due to KASAN enabled
its metadata means the per-object size goes above 8k and thus the fallback
order will be 2. It's a corner case that wasn't anticipated and existed for
years without known reports. We'll need to deal with it somehow.

> Note that the size of the structure is largely because of the
> embedded cpumask for inodegc:
> 
> 	struct cpumask             m_inodegc_cpumask;    /*  3104  1024 */
> 
> This should probably be pulled out into a dynamically allocated
> inodegc specific structure. Then the struct xfs_mount is only a
> order-0 allocation and should never fail, regardless of
> __GFP_NOFAIL being specified or not.
> 
>> I think either this allocation really can fail as the code (return
>> -ENOMEM) suggests and thus can drop __GFP_NOFAIL, or it can use
>> kvmalloc() - I think the wrapper for that can be removed now too after
>> the discussion in [1] resulted in commit 46459154f997 ("mm: kvmalloc:
>> make kmalloc fast path real fast path").
> 
> I know about that - I have patches that I'm testing that replace
> xlog_kvmalloc() with kvmalloc calls.

Great, thanks!

> -Dave.

Re: [syzbot] [mm?] WARNING in xfs_init_fs_context

[Tetsuo Handa]

On 2025/07/08 17:50, Vlastimil Babka wrote:
> On 7/8/25 00:10, Dave Chinner wrote:
>> On Wed, Jul 02, 2025 at 09:30:30AM +0200, Vlastimil Babka wrote:
>>> On 7/2/25 3:41 AM, Tetsuo Handa wrote:
>>>> By the way, why is xfs_init_fs_context() using __GFP_NOFAIL ?
>>>>
>>>> 	mp = kzalloc(sizeof(struct xfs_mount), GFP_KERNEL | __GFP_NOFAIL);
>>>> 	if (!mp)
>>>> 		return -ENOMEM;
>>>>
>>>> This looks an allocation attempt which can fail safely.
>>
>> It's irrelevant - it shouldn't fail regardless of __GFP_NOFAIL being
>> specified.
> 
> If you mean the "too small to fail" behavior then it's generally true,
> except in some corner cases like being an oom victim, in which case the
> allocation can fail - the userspace process is doomed anyway. But a (small)
> kernel allocation not handling NULL would still need __GFP_NOFAIL to prevent
> that corner case.

init_fs_context() is allowed to fail.

https://elixir.bootlin.com/linux/v6.16-rc4/source/fs/fs_context.c#L318
https://elixir.bootlin.com/linux/v6.16-rc4/source/fs/ext4/super.c#L1990

Therefore, I wonder why xfs does not want xfs_init_fs_context() to fail
with -ENOMEM.

Re: [syzbot] [mm?] WARNING in xfs_init_fs_context

[syzbot]

syzbot has found a reproducer for the following issue on:

HEAD commit:    51a24b7deaae Merge tag 'trace-tools-v6.17-rc5' of git://gi..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1268bf12580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=bf99f2510ef92ba5
dashboard link: https://syzkaller.appspot.com/bug?extid=359a67b608de1ef72f65
compiler:       Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=11a20334580000

Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-51a24b7d.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/2d2422223a2d/vmlinux-51a24b7d.xz
kernel image: https://storage.googleapis.com/syzbot-assets/3f33b7e0feca/bzImage-51a24b7d.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/345ccb8f827e/mount_8.gz
  fsck result: failed (log: https://syzkaller.appspot.com/x/fsck.log?x=161e6ae2580000)

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+359a67b608de1ef72f65@syzkaller.appspotmail.com

loop0: detected capacity change from 0 to 32768
------------[ cut here ]------------
WARNING: CPU: 0 PID: 6463 at mm/page_alloc.c:4619 __alloc_pages_slowpath+0xcb3/0xce0 mm/page_alloc.c:4619
Modules linked in:
CPU: 0 UID: 0 PID: 6463 Comm: syz.0.279 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
RIP: 0010:__alloc_pages_slowpath+0xcb3/0xce0 mm/page_alloc.c:4619
Code: d8 48 c1 e8 03 0f b6 04 08 84 c0 75 2e f6 43 01 08 48 8b 14 24 0f 84 a2 f3 ff ff 90 0f 0b 90 e9 99 f3 ff ff e8 3e 9e 64 09 90 <0f> 0b 90 f7 c5 00 04 00 00 75 bc 90 0f 0b 90 eb b6 89 d9 80 e1 07
RSP: 0018:ffffc9000e2ff8f0 EFLAGS: 00010246
RAX: 97af8c55b4e88b00 RBX: 0000000000000002 RCX: dffffc0000000000
RDX: ffffc9000e2ffa00 RSI: 0000000000000002 RDI: 0000000000048cc0
RBP: 0000000000048cc0 R08: ffff88805ffd7297 R09: 1ffff1100bffae52
R10: dffffc0000000000 R11: ffffed100bffae53 R12: ffffc9000e2ffa00
R13: 1ffff92001c5ff3c R14: 0000000000048cc0 R15: dffffc0000000000
FS:  00007fb4ec9696c0(0000) GS:ffff88808d007000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fb4ebb72b60 CR3: 00000000516af000 CR4: 0000000000352ef0
Call Trace:
 <TASK>
 __alloc_frozen_pages_noprof+0x319/0x370 mm/page_alloc.c:5161
 alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2416
 alloc_slab_page mm/slub.c:2492 [inline]
 allocate_slab+0xd9/0x370 mm/slub.c:2668
 new_slab mm/slub.c:2714 [inline]
 ___slab_alloc+0xbeb/0x1420 mm/slub.c:3901
 __slab_alloc mm/slub.c:3992 [inline]
 __slab_alloc_node mm/slub.c:4067 [inline]
 slab_alloc_node mm/slub.c:4228 [inline]
 __kmalloc_cache_noprof+0x296/0x3d0 mm/slub.c:4402
 kmalloc_noprof include/linux/slab.h:905 [inline]
 kzalloc_noprof include/linux/slab.h:1039 [inline]
 xfs_init_fs_context+0x54/0x500 fs/xfs/xfs_super.c:2278
 alloc_fs_context+0x64e/0x7d0 fs/fs_context.c:318
 do_new_mount+0x16f/0x9e0 fs/namespace.c:3787
 do_mount fs/namespace.c:4136 [inline]
 __do_sys_mount fs/namespace.c:4347 [inline]
 __se_sys_mount+0x317/0x410 fs/namespace.c:4324
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fb4ebb9066a
Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb a6 e8 de 1a 00 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fb4ec968e68 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007fb4ec968ef0 RCX: 00007fb4ebb9066a
RDX: 0000200000009600 RSI: 0000200000009640 RDI: 00007fb4ec968eb0
RBP: 0000200000009600 R08: 00007fb4ec968ef0 R09: 0000000000200800
R10: 0000000000200800 R11: 0000000000000246 R12: 0000200000009640
R13: 00007fb4ec968eb0 R14: 0000000000009644 R15: 00002000000002c0
 </TASK>


---
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

Re: [syzbot] [mm?] WARNING in xfs_init_fs_context

[Christoph Hellwig]

This looks like slub turning a < PAGE_SIZE allocation into a order > 0
folio allocation, which the page allocator then complains about.

We'll either need to make slab not propagate < PAGE_SIZE allocations
to order > 0 page allocation, or make the page allocator handle the
latter.

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

Re: [syzbot] [mm?] WARNING in xfs_init_fs_context

[Vlastimil Babka]

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