* [BUG] WARNING in bdev_getblk
@ 2025-06-09 8:39 Xianying Wang
2025-06-09 13:54 ` Jan Kara
0 siblings, 1 reply; 4+ messages in thread
From: Xianying Wang @ 2025-06-09 8:39 UTC (permalink / raw)
To: viro; +Cc: brauner, jack, linux-fsdevel, linux-kernel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [BUG] WARNING in bdev_getblk
2025-06-09 8:39 [BUG] WARNING in bdev_getblk Xianying Wang
@ 2025-06-09 13:54 ` Jan Kara
2025-06-09 20:48 ` Matthew Wilcox
0 siblings, 1 reply; 4+ messages in thread
From: Jan Kara @ 2025-06-09 13:54 UTC (permalink / raw)
To: Xianying Wang; +Cc: viro, brauner, jack, linux-fsdevel, linux-kernel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [BUG] WARNING in bdev_getblk
2025-06-09 13:54 ` Jan Kara
@ 2025-06-09 20:48 ` Matthew Wilcox
2025-06-10 8:02 ` Jan Kara
0 siblings, 1 reply; 4+ messages in thread
From: Matthew Wilcox @ 2025-06-09 20:48 UTC (permalink / raw)
To: Jan Kara; +Cc: Xianying Wang, viro, brauner, linux-fsdevel, linux-kernel
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [BUG] WARNING in bdev_getblk
2025-06-09 20:48 ` Matthew Wilcox
@ 2025-06-10 8:02 ` Jan Kara
0 siblings, 0 replies; 4+ messages in thread
From: Jan Kara @ 2025-06-10 8:02 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Jan Kara, Xianying Wang, viro, brauner, linux-fsdevel,
linux-kernel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2025-06-10 8:02 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-06-09 8:39 [BUG] WARNING in bdev_getblk Xianying Wang
2025-06-09 13:54 ` Jan Kara
2025-06-09 20:48 ` Matthew Wilcox
2025-06-10 8:02 ` Jan Kara
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).