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

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

[Andrew Morton]

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

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

[Barry Song]

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

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

[Shakeel Butt]

+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