* Re: [syzbot] [mm?] WARNING in shrink_one
2026-10-19 23:46 ` [syzbot] [mm?] WARNING in shrink_one Andrew Morton
@ 2026-10-20 0:35 ` Barry Song
2026-10-20 1:25 ` Shakeel Butt
1 sibling, 0 replies; 3+ messages in thread
From: Barry Song @ 2026-10-20 0:35 UTC (permalink / raw)
To: Andrew Morton
Cc: syzbot, david, gourry, joshua.hahnjy, linux-kernel, linux-mm,
rakie.kim, syzkaller-bugs, ying.huang, ziy, linux-ext4,
Vlastimil Babka, Theodore Ts'o
On Tue, Oct 20, 2026 at 7:46 AM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Mon, 19 Oct 2026 12:40:33 -0700 syzbot <syzbot+54f6a8926b40a171f2c8@syzkaller.appspotmail.com> wrote:
>
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit: a0ff06b3a7bd Merge tag 'firewire-fixes-7.3-final' of git:/..
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=12cdb20d580000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=44ac479246d4559b
> > dashboard link: https://syzkaller.appspot.com/bug?extid=54f6a8926b40a171f2c8
> > compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
> > userspace arch: i386
> >
> > Unfortunately, I don't have any reproducer for this issue yet.
> >
> > Downloadable assets:
> > disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-a0ff06b3.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-assets/3f4bcbceb92e/vmlinux-a0ff06b3.xz
> > kernel image: https://storage.googleapis.com/syzbot-assets/bf4df8252e54/bzImage-a0ff06b3.xz
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+54f6a8926b40a171f2c8@syzkaller.appspotmail.com
> >
> > ------------[ cut here ]------------
> > current->flags & PF_MEMALLOC
> > WARNING: mm/page_alloc.c:4816 at __alloc_pages_slowpath mm/page_alloc.c:4816 [inline], CPU#3: syz-executor/5706
> > WARNING: mm/page_alloc.c:4816 at __alloc_frozen_pages_noprof+0x1eac/0x3300 mm/page_alloc.c:5449, CPU#3: syz-executor/5706
>
> Thanks. The stack trace is missing important bits for some reason, but
> it appears to be ext4 disagreeing with page reclaim.
>
> __alloc_pages_slowpath():
> if (unlikely(nofail)) {
> /*
> * We don't support __GFP_NOFAIL without __GFP_DIRECT_RECLAIM,
> * otherwise, we may result in lockup.
> */
> WARN_ON_ONCE(!can_direct_reclaim);
> /*
> * PF_MEMALLOC request from this context is rather bizarre
> * because we cannot reclaim anything and only can loop waiting
> * for somebody to do a work for us.
> */
> -->> WARN_ON_ONCE(current->flags & PF_MEMALLOC);
> }
>
> The electrical think machine said:
>
>
> filemap_fault()
> -> direct reclaim
> -> shrink_slab()
> -> super_cache_scan()
> -> prune_icache_sb()
> -> evict()
> -> ext4_evict_inode()
> -> ext4_clear_inode()
> -> ext4_discard_preallocations()
> -> ext4_mb_load_buddy_gfp(
> GFP_NOFS | __GFP_NOFAIL)
> -> __filemap_get_folio()
> -> page allocator
> -> WARN_ON(PF_MEMALLOC)
>
>
> The task enters direct reclaim after a filemap allocation failure.
> Reclaim calls shrink_slab(), which evicts an ext4 inode via
> super_cache_scan() and prune_icache_sb(). The eviction path eventually
> calls ext4_discard_preallocations(), which explicitly does:
>
> err = ext4_mb_load_buddy_gfp(sb, group, &e4b,
> GFP_NOFS | __GFP_NOFAIL);
>
> If the buddy-cache folio isn't resident, ext4_mb_load_buddy_gfp()
> allocates one through __filemap_get_folio(). This reaches
> __alloc_pages_slowpath() with __GFP_NOFAIL while PF_MEMALLOC is set,
> triggering the warning.
Right. The problem is that ext4, while running under direct reclaim,
allocates memory with __GFP_NOFAIL, and that allocation can itself
re-enter direct reclaim.
>
> Simply removing __GFP_NOFAIL doesn't look safe. The preallocations
> have already been detached from the inode's tree, and failure to load
> the buddy information can prevent their space from being released
> correctly.
>
> It seems that ext4 needs a way to complete this mandatory cleanup
> without performing a NOFAIL allocation from the slab-shrinker context.
> Perhaps the preallocation cleanup could be restructured so that it
> doesn't require allocating buddy-cache folios during reclaim?
Checking the code,
2 5686 fs/ext4/mballoc.c <<ext4_discard_preallocations>>
err = ext4_mb_load_buddy_gfp(sb, group, &e4b,
It does check if (err) there.
err = ext4_mb_load_buddy_gfp(sb, group, &e4b,
GFP_NOFS|__GFP_NOFAIL);
if (err) {
ext4_error_err(sb, -err, "Error %d loading
buddy information for %u",
err, group);
continue;
}
So maybe it's safe to drop __GFP_NOFAIL.
In any case, we need the ext4 folks to look into this.
>
> The syzbot report is at:
> https://syzkaller.appspot.com/bug?extid=54f6a8926b40a171f2c8
>
Best Regards
Barry
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [syzbot] [mm?] WARNING in shrink_one
2026-10-19 23:46 ` [syzbot] [mm?] WARNING in shrink_one Andrew Morton
2026-10-20 0:35 ` Barry Song
@ 2026-10-20 1:25 ` Shakeel Butt
1 sibling, 0 replies; 3+ messages in thread
From: Shakeel Butt @ 2026-10-20 1:25 UTC (permalink / raw)
To: Andrew Morton
Cc: syzbot, david, gourry, joshua.hahnjy, linux-kernel, linux-mm,
rakie.kim, syzkaller-bugs, ying.huang, ziy, linux-ext4,
Vlastimil Babka, Barry Song, Theodore Ts'o, jack
+Jan Kara
On Mon, Oct 19, 2026 at 04:46:38PM -0700, Andrew Morton wrote:
> On Mon, 19 Oct 2026 12:40:33 -0700 syzbot <syzbot+54f6a8926b40a171f2c8@syzkaller.appspotmail.com> wrote:
>
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit: a0ff06b3a7bd Merge tag 'firewire-fixes-7.3-final' of git:/..
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=12cdb20d580000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=44ac479246d4559b
> > dashboard link: https://syzkaller.appspot.com/bug?extid=54f6a8926b40a171f2c8
> > compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
> > userspace arch: i386
> >
> > Unfortunately, I don't have any reproducer for this issue yet.
> >
> > Downloadable assets:
> > disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-a0ff06b3.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-assets/3f4bcbceb92e/vmlinux-a0ff06b3.xz
> > kernel image: https://storage.googleapis.com/syzbot-assets/bf4df8252e54/bzImage-a0ff06b3.xz
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+54f6a8926b40a171f2c8@syzkaller.appspotmail.com
> >
> > ------------[ cut here ]------------
> > current->flags & PF_MEMALLOC
> > WARNING: mm/page_alloc.c:4816 at __alloc_pages_slowpath mm/page_alloc.c:4816 [inline], CPU#3: syz-executor/5706
> > WARNING: mm/page_alloc.c:4816 at __alloc_frozen_pages_noprof+0x1eac/0x3300 mm/page_alloc.c:5449, CPU#3: syz-executor/5706
>
> Thanks. The stack trace is missing important bits for some reason, but
> it appears to be ext4 disagreeing with page reclaim.
>
> __alloc_pages_slowpath():
> if (unlikely(nofail)) {
> /*
> * We don't support __GFP_NOFAIL without __GFP_DIRECT_RECLAIM,
> * otherwise, we may result in lockup.
> */
> WARN_ON_ONCE(!can_direct_reclaim);
> /*
> * PF_MEMALLOC request from this context is rather bizarre
> * because we cannot reclaim anything and only can loop waiting
> * for somebody to do a work for us.
> */
> -->> WARN_ON_ONCE(current->flags & PF_MEMALLOC);
> }
>
> The electrical think machine said:
>
>
> filemap_fault()
> -> direct reclaim
> -> shrink_slab()
> -> super_cache_scan()
> -> prune_icache_sb()
> -> evict()
> -> ext4_evict_inode()
> -> ext4_clear_inode()
> -> ext4_discard_preallocations()
> -> ext4_mb_load_buddy_gfp(
> GFP_NOFS | __GFP_NOFAIL)
> -> __filemap_get_folio()
> -> page allocator
> -> WARN_ON(PF_MEMALLOC)
>
>
> The task enters direct reclaim after a filemap allocation failure.
> Reclaim calls shrink_slab(), which evicts an ext4 inode via
> super_cache_scan() and prune_icache_sb(). The eviction path eventually
> calls ext4_discard_preallocations(), which explicitly does:
>
> err = ext4_mb_load_buddy_gfp(sb, group, &e4b,
> GFP_NOFS | __GFP_NOFAIL);
>
> If the buddy-cache folio isn't resident, ext4_mb_load_buddy_gfp()
> allocates one through __filemap_get_folio(). This reaches
> __alloc_pages_slowpath() with __GFP_NOFAIL while PF_MEMALLOC is set,
> triggering the warning.
>
> Simply removing __GFP_NOFAIL doesn't look safe. The preallocations
> have already been detached from the inode's tree, and failure to load
> the buddy information can prevent their space from being released
> correctly.
>
> It seems that ext4 needs a way to complete this mandatory cleanup
> without performing a NOFAIL allocation from the slab-shrinker context.
> Perhaps the preallocation cleanup could be restructured so that it
> doesn't require allocating buddy-cache folios during reclaim?
>
> The syzbot report is at:
> https://syzkaller.appspot.com/bug?extid=54f6a8926b40a171f2c8
Jan already has a series which will fix these kind of issues:
http://lore.kernel.org/20261009133253.20102-1-jack@suse.cz
^ permalink raw reply [flat|nested] 3+ messages in thread