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

[Andrew Morton <akpm@linux-foundation.org>]

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