[syzbot] [mm?] WARNING in shrink_one

[syzbot] [mm?] WARNING in shrink_one

[syzbot]

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
Modules linked in:

CPU: 3 UID: 0 PID: 5706 Comm: syz-executor Tainted: G             L      syzkaller #0 PREEMPT(full) 
Tainted: [L]=SOFTLOCKUP
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:__alloc_pages_slowpath mm/page_alloc.c:4816 [inline]
RIP: 0010:__alloc_frozen_pages_noprof+0x1eac/0x3300 mm/page_alloc.c:5449
Code: 38 d0 7c 08 84 d2 0f 85 de 12 00 00 65 48 8b 05 c2 6c 1c 13 c7 84 24 94 00 00 00 00 80 00 00 f6 40 2d 08 0f 84 ba e7 ff ff 90 <0f> 0b 90 e9 b1 e7 ff ff 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03
RSP: 0000:ffffc900045465e8 EFLAGS: 00010202

RAX: ffff88802a07a580 RBX: 0000000000000000 RCX: 1ffff1100fffad29
RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff88803fffd938
RBP: ffff88802a07a5ac R08: 0000000000008000 R09: 0000000000000001
R10: 0000000000000002 R11: 0000000000000000 R12: 0000000000048c40
R13: ffff88803fffb900 R14: 0000000000000000 R15: 1ffff920008a8cd7
FS:  0000000000000000(0000) GS:ffff888095a4a000(0063) knlGS:00000000567714c0
CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: 00000000f7159f10 CR3: 00000000265ed000 CR4: 0000000000352ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 00000000000f000e DR6: 00000000ffff0ff0 DR7: 0000000000000400
Call Trace:
 <TASK>
 alloc_pages_mpol+0x201/0x550 mm/mempolicy.c:2486
 alloc_pages_noprof mm/mempolicy.c:2577 [inline]
 folio_alloc_noprof+0x22/0x250 mm/mempolicy.c:2587
 filemap_alloc_folio_noprof.part.0+0x3db/0x440 mm/filemap.c:1019
 shrink_one+0x398/0x850 mm/vmscan.c:5119
 shrink_many mm/vmscan.c:5180 [inline]
 lru_gen_shrink_node mm/vmscan.c:5258 [inline]
 shrink_node+0x2b20/0x4320 mm/vmscan.c:6247
 shrink_zones mm/vmscan.c:6503 [inline]
 do_try_to_free_pages+0x33e/0x16d0 mm/vmscan.c:6565
 try_to_free_pages+0x2a0/0x740 mm/vmscan.c:6804
 __perform_reclaim mm/page_alloc.c:4451 [inline]
 __alloc_pages_direct_reclaim mm/page_alloc.c:4478 [inline]
 __alloc_pages_slowpath mm/page_alloc.c:4939 [inline]
 __alloc_frozen_pages_noprof+0xf8a/0x3300 mm/page_alloc.c:5449
 alloc_pages_mpol+0x201/0x550 mm/mempolicy.c:2486
 alloc_pages_noprof mm/mempolicy.c:2577 [inline]
 folio_alloc_noprof+0x22/0x250 mm/mempolicy.c:2587
 filemap_alloc_folio_noprof.part.0+0x3db/0x440 mm/filemap.c:1019
 filemap_alloc_folio_noprof mm/filemap.c:2033 [inline]
 __filemap_get_folio_mpol+0x653/0x1280 mm/filemap.c:2018
 __filemap_get_folio include/linux/pagemap.h:761 [inline]
 filemap_fault+0x879/0x3130 mm/filemap.c:3607
 __do_fault+0x10b/0x440 mm/memory.c:5565
 do_read_fault mm/memory.c:6000 [inline]
 do_fault+0xb3f/0x1830 mm/memory.c:6134
 do_pte_missing mm/memory.c:4700 [inline]
 handle_pte_fault mm/memory.c:6558 [inline]
 __handle_mm_fault+0x150b/0x2f60 mm/memory.c:6707
 handle_mm_fault+0x363/0xa20 mm/memory.c:6876
 do_user_addr_fault+0x59c/0x12f0 arch/x86/mm/fault.c:1343
 handle_page_fault arch/x86/mm/fault.c:1483 [inline]
 exc_page_fault+0x6f/0xd0 arch/x86/mm/fault.c:1536
 asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:595
RIP: 0023:0xf7159f10
Code: Unable to access opcode bytes at 0xf7159ee6.
RSP: 002b:00000000ffdf10b0 EFLAGS: 00010283
RAX: 0000000000000051 RBX: 00000000f73ebff4 RCX: 0000000000000050
RDX: 0000000056792cf8 RSI: 0000000056792748 RDI: 00000000f73f2760
RBP: 00000000000005b0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000292 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
 </TASK>


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

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