[BUG] WARNING in bdev_getblk

[BUG] WARNING in bdev_getblk

[Xianying Wang]

Hi,

I encountered a kernel WARNING in the function bdev_getblk() when
fuzzing the Linux 6.12 kernel using Syzkaller. The crash occurs during
a block buffer allocation path, where __alloc_pages_noprof() fails
under memory pressure, and triggers a WARNING due to an internal
allocation failure.

Root Cause:

Code Path: The failure originates from the function bdev_getblk() in
fs/buffer.c, which attempts to allocate a new buffer via
grow_buffers() → grow_dev_folio() → __filemap_get_folio().
Memory Allocation Failure: Under specific memory pressure and
vm.zone_reclaim_mode settings, the internal call to alloc_pages() in
__alloc_pages_noprof() fails, resulting in the observed warning.

I recommend reviewing the block buffer allocation path in
bdev_getblk(), particularly how it handles allocation failures under
memory pressure.

This can be reproduced on:

HEAD commit:

commit adc218676eef25575469234709c2d87185ca223a

report: https://pastebin.com/raw/wqAeZJxF

console output : https://pastebin.com/raw/aLaVQpzR

kernel config : https://pastebin.com/x48ijkN8

C reproducer : https://pastebin.com/raw/whJgYnHk

Best regards,

Xianying

Re: [BUG] WARNING in bdev_getblk

[Jan Kara]

Hi!

On Mon 09-06-25 16:39:15, Xianying Wang wrote:
> I encountered a kernel WARNING in the function bdev_getblk() when
> fuzzing the Linux 6.12 kernel using Syzkaller. The crash occurs during
> a block buffer allocation path, where __alloc_pages_noprof() fails
> under memory pressure, and triggers a WARNING due to an internal
> allocation failure.

Ah, this is a warning about GFP_NOFAIL allocation from direct reclaim:

[   44.141691] ------------[ cut here ]------------
[   44.142325] WARNING: CPU: 1 PID: 3002 at mm/page_alloc.c:4238 __alloc_pages_noprof+0x1746/0x1ef0
[   44.143484] Modules linked in:
[   44.143868] CPU: 1 UID: 0 PID: 3002 Comm: syz-executor.0 Not tainted 6.12.0 #1
[   44.144651] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[   44.145679] RIP: 0010:__alloc_pages_noprof+0x1746/0x1ef0
[   44.146277] Code: 89 fa 48 c1 ea 03 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 82 07 00 00 f6 43 2d 08 0f 84 0d ee ff ff 90 <0f> 0b 90 e9 04 ee ff ff 44 89 4c 24 40 65 8b 15 52 fc 8c 7e 89 d2
[   44.148206] RSP: 0018:ffff8880195f6940 EFLAGS: 00010202
[   44.148758] RAX: 0000000000000007 RBX: ffff8880156be480 RCX: 1ffff1100fffb931
[   44.149516] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff8880156be4ac
[   44.150278] RBP: 0000000000000400 R08: 0000000000000801 R09: 000000000000000b
[   44.151030] R10: ffff88807ffdcd87 R11: 0000000000000000 R12: 0000000000000000
[   44.152622] R13: ffff8880195f6a10 R14: 0000000000148c48 R15: 0000000000148c48
[   44.153657] FS:  00007fdccd5c76c0(0000) GS:ffff88806d300000(0000) knlGS:0000000000000000
[   44.155023] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   44.155659] CR2: 00007f1d26fa6000 CR3: 000000000e67a000 CR4: 0000000000350ef0
[   44.156431] Call Trace:
[   44.156706]  <TASK>
[   44.156946]  ? __warn+0xea/0x2c0
[   44.157343]  ? __alloc_pages_noprof+0x1746/0x1ef0
[   44.157865]  ? report_bug+0x2f5/0x3f0
[   44.158298]  ? __alloc_pages_noprof+0x1746/0x1ef0
[   44.158812]  ? __alloc_pages_noprof+0x1747/0x1ef0
[   44.159347]  ? handle_bug+0xe5/0x180
[   44.159753]  ? exc_invalid_op+0x35/0x80
[   44.160216]  ? asm_exc_invalid_op+0x1a/0x20
[   44.160683]  ? __alloc_pages_noprof+0x1746/0x1ef0
[   44.161237]  ? __pte_offset_map+0xe9/0x1f0
[   44.161693]  ? __pte_offset_map+0xf4/0x1f0
[   44.162168]  ? __sanitizer_cov_trace_pc+0x8/0x80
[   44.162677]  ? __pte_offset_map+0x12f/0x1f0
[   44.163175]  ? __pfx___alloc_pages_noprof+0x10/0x10
[   44.163710]  ? pte_offset_map_nolock+0x106/0x1b0
[   44.164253]  ? check_pte+0x253/0x2e0
[   44.164661]  ? page_vma_mapped_walk+0x62c/0x1640
[   44.165192]  ? __sanitizer_cov_trace_switch+0x54/0x90
[   44.165742]  ? policy_nodemask+0xeb/0x4b0
[   44.166206]  alloc_pages_mpol_noprof+0xf2/0x330
[   44.166704]  ? __pfx_alloc_pages_mpol_noprof+0x10/0x10
[   44.167285]  ? xas_load+0x6a/0x2a0
[   44.167674]  folio_alloc_noprof+0x21/0x70
[   44.168138]  filemap_alloc_folio_noprof+0x324/0x360
[   44.168676]  ? __pfx_filemap_get_entry+0x10/0x10
[   44.169209]  ? __pfx_filemap_alloc_folio_noprof+0x10/0x10
[   44.169798]  ? __filemap_get_folio+0x149/0x4e0
[   44.170313]  __filemap_get_folio+0x213/0x4e0
[   44.170792]  bdev_getblk+0x1d4/0x500
[   44.171221]  __ext4_get_inode_loc+0x4fa/0x1350
[   44.171713]  ? _raw_spin_lock_irq+0x81/0xe0
[   44.172206]  ? __pfx__raw_spin_lock_irq+0x10/0x10
[   44.172730]  ? __pfx___ext4_get_inode_loc+0x10/0x10
[   44.173287]  ? folio_mapping+0xdc/0x1f0
[   44.173725]  ? __sanitizer_cov_trace_switch+0x54/0x90
[   44.174307]  ext4_get_inode_loc+0xbe/0x160
[   44.174769]  ? __pfx_ext4_get_inode_loc+0x10/0x10
[   44.175312]  ext4_reserve_inode_write+0xce/0x280
[   44.175825]  ? folio_referenced+0x2d0/0x4f0
[   44.176315]  __ext4_mark_inode_dirty+0x105/0x730
[   44.176828]  ? __pfx___ext4_mark_inode_dirty+0x10/0x10
[   44.177421]  ? blk_mq_flush_plug_list+0x5b5/0x1580
[   44.177954]  ? ext4_journal_check_start+0x1a4/0x2b0
[   44.178522]  ? __ext4_journal_start_sb+0x199/0x460
[   44.179075]  ? ext4_dirty_inode+0xa5/0x130
[   44.179533]  ? __pfx__raw_spin_lock+0x10/0x10
[   44.180015]  ? __pfx_ext4_dirty_inode+0x10/0x10
[   44.180537]  ext4_dirty_inode+0xdd/0x130
[   44.180977]  __mark_inode_dirty+0x121/0x9d0
[   44.181465]  iput.part.0+0xfc/0x6c0
[   44.181857]  iput+0x62/0x80
[   44.182202]  dentry_unlink_inode+0x2c7/0x4b0
[   44.182672]  __dentry_kill+0x1d5/0x5e0
[   44.183108]  shrink_dentry_list+0xf3/0x1f0
[   44.183551]  prune_dcache_sb+0xeb/0x150
[   44.183971]  ? down_read_trylock+0x114/0x1c0
[   44.184493]  ? __pfx_prune_dcache_sb+0x10/0x10
[   44.184977]  ? __pfx_ext4_es_scan+0x10/0x10
[   44.185457]  super_cache_scan+0x339/0x550
[   44.185895]  shrink_slab+0x51c/0xa90
[   44.186321]  ? __pfx_shrink_slab+0x10/0x10
[   44.186765]  ? __pfx__raw_spin_lock_irq+0x10/0x10
[   44.187293]  shrink_node+0x606/0x1760
[   44.187702]  ? throttle_direct_reclaim+0xcd/0x8f0
[   44.188244]  do_try_to_free_pages+0x2aa/0x1260
[   44.188733]  try_to_free_pages+0x215/0x470
[   44.189196]  ? __pfx_try_to_free_pages+0x10/0x10
[   44.189692]  ? wake_all_kswapds+0x12d/0x2e0

In this case slab reclaim has dropped the last inode reference which
triggered update of lazy time, thus inode is dirtied which needs to do
GFP_NOFAIL memory allocation to handle all the block updates & journalling.
I think we should rather teach flush worker to handle these delayed lazy
time updates instead of handling them in iput_final(). At least for
PF_MEMALLOC cases...

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [BUG] WARNING in bdev_getblk

[Matthew Wilcox]

On Mon, Jun 09, 2025 at 03:54:01PM +0200, Jan Kara wrote:
> Hi!
> 
> On Mon 09-06-25 16:39:15, Xianying Wang wrote:
> > I encountered a kernel WARNING in the function bdev_getblk() when
> > fuzzing the Linux 6.12 kernel using Syzkaller. The crash occurs during
> > a block buffer allocation path, where __alloc_pages_noprof() fails
> > under memory pressure, and triggers a WARNING due to an internal
> > allocation failure.
> 
> Ah, this is a warning about GFP_NOFAIL allocation from direct reclaim:

It's the same discussion we had at LSFMM.  It seems like we have a lot
of "modified syzkaller" people trying this kind of thing.

Re: [BUG] WARNING in bdev_getblk

[Jan Kara]

On Mon 09-06-25 21:48:49, Matthew Wilcox wrote:
> On Mon, Jun 09, 2025 at 03:54:01PM +0200, Jan Kara wrote:
> > Hi!
> > 
> > On Mon 09-06-25 16:39:15, Xianying Wang wrote:
> > > I encountered a kernel WARNING in the function bdev_getblk() when
> > > fuzzing the Linux 6.12 kernel using Syzkaller. The crash occurs during
> > > a block buffer allocation path, where __alloc_pages_noprof() fails
> > > under memory pressure, and triggers a WARNING due to an internal
> > > allocation failure.
> > 
> > Ah, this is a warning about GFP_NOFAIL allocation from direct reclaim:
> 
> It's the same discussion we had at LSFMM.  It seems like we have a lot
> of "modified syzkaller" people trying this kind of thing.

Well, yes, it's from modified syzkaller and I'm not going to run the
reproducer but in this case it's clear just from the stacktrace what the
problem is and it looks like a valid (although relatively minor) issue.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR