public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [BUG] kernel BUG in ext4_do_writepages
@ 2026-03-06  5:42 Xianying Wang
  2026-03-07  0:16 ` yebin (H)
  0 siblings, 1 reply; 4+ messages in thread
From: Xianying Wang @ 2026-03-06  5:42 UTC (permalink / raw)
  To: tytso; +Cc: adilger.kernel, linux-ext4, linux-kernel

Hi,

I would like to report a kernel BUG triggered by a syzkaller
reproducer in the ext4 filesystem writeback path.

The issue was originally observed on Linux 6.19.0-rc8 and can also be
reproduced on Linux 7.0-rc2. The crash occurs in the ext4 writeback
routine while the background writeback worker is flushing dirty pages
to disk.

During the crash, the filesystem reports that no free blocks are
available while dirty pages and reserved blocks still exist. Under
this condition, the writeback worker continues processing pending
writeback operations and eventually reaches an internal consistency
check inside the ext4 writeback routine, which triggers a kernel BUG.

Based on the execution context, the issue appears to be related to the
interaction between delayed allocation and the writeback mechanism
when the filesystem runs out of available blocks. When the writeback
thread attempts to flush dirty pages in this state, ext4 enters an
unexpected internal state that causes the BUG to be triggered.

This can be reproduced on:

HEAD commit:

11439c4635edd669ae435eec308f4ab8a0804808

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

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

kernel config : https://pastebin.com/7hk2cU0G

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

Let me know if you need more details or testing.

Best regards,

Xianying

^ permalink raw reply	[flat|nested] 4+ messages in thread
* [BUG] kernel BUG in ext4_do_writepages
@ 2026-01-14  7:49 Xianying Wang
  0 siblings, 0 replies; 4+ messages in thread
From: Xianying Wang @ 2026-01-14  7:49 UTC (permalink / raw)
  To: tytso; +Cc: adilger.kernel, linux-ext4, linux-kernel

Hi,

I am reporting a kernel BUG triggered in the ext4 writeback path,
reproducible with a syzkaller-generated workload on v6.18.0-rc7 and
v6.17.0.

The crash may caused by a violated internal assumption in
ext4_do_writepages() . During writeback, the code reaches a path that
assumes the inode is not using journaled data, but
ext4_should_journal_data(inode) evaluates to true, triggering a
BUG_ON() and crashing the kernel.

The BUG is triggered at:

: ext4_do_writepages()

specifically at the assertion:

BUG_ON(ext4_should_journal_data(inode));

From code inspection, ext4_do_writepages() contains earlier logic to
handle journaled-data inodes by disabling mapping (mpd->can_map = 0).
However, later in the function, the code unconditionally asserts that
journaled data must not be in effect. This suggests an internal state
inconsistency: either the inode metadata indicates journaled data
unexpectedly, or the writeback state (mpd) allows the control flow to
reach a path that is incompatible with journaled data inodes.

This can be reproduced on:

HEAD commit:

v6.18-rc7: ac3fd01e4c1efce8f2c054cdeb2ddd2fc0fb150d

v6.17.0: e5f0a698b34ed76002dc5cff3804a61c80233a7a

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

console output v6.18-rc7 :https://pastebin.com/raw/a88x4vQt

console output v6.17.0: https://pastebin.com/raw/s3cfkbmC

kernel config : https://pastebin.com/raw/1grwrT16

C reproducer :https://pastebin.com/raw/0nLHxWck

Let me know if you need more details or testing.

Best regards,

Xianying

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2026-03-09  8:02 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-03-06  5:42 [BUG] kernel BUG in ext4_do_writepages Xianying Wang
2026-03-07  0:16 ` yebin (H)
2026-03-09  8:02   ` Xianying Wang
  -- strict thread matches above, loose matches on Subject: below --
2026-01-14  7:49 Xianying Wang

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox