Re: [BUG] kernel BUG in ext4_do_writepages

[Xianying Wang]

Hi，

I checked the history of ext4_do_writepages() using git log -L and
found that the function was recently modified by commit
bbbf150f3f85619569ac19dc6458cca7c492e715 ("ext4: reserved credits for
one extent during the folio writeback").

This patch appears potentially related because it changes the journal
credit reservation logic as well as the transaction restart / folio
resubmission behavior in the writeback path. These changes seem
relevant to the crash context I observed in ext4_do_writepages(),
where the filesystem reports free_blocks=0 while dirty_blocks are
still present.

As an additional observation, I was able to reproduce this issue on
Linux v6.17 and Linux v6.18-rc7 as well. However, I cannot confirm yet
that this commit is the exact introducing commit.

If helpful, I can also try to run a git bisect to identify the
introducing commit more precisely.

Please let me know if more information is needed.

Best regards，

Xianying

yebin (H) <yebin10@xxxxxxxxxx> 于2026年3月7日周六 08:16写道：
>
>
>
> On 2026/3/6 13:42, Xianying Wang wrote:
> > Hi,
> >
> > I would like to report a kernel BUG triggered by a syzkaller
> > reproducer in the ext4 filesystem writeback path.
> >
>
> There was a period when I also noticed block allocation failures during
> write-back, but after the configuration was changed, it didn't seem to
> happen again.
>
> > 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
>
> Can you identify which patch or which patchset introduced the issue?
>
> > 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
> >
>
> Can you add these to the email as attachments?
>
> > Let me know if you need more details or testing.
> >
> > Best regards,
> >
> > Xianying
> >
> >
> > .
> >

Attachment: repro.report
Description: Binary data

Attachment: repro.cprog
Description: Binary data

Attachment: repro.log
Description: Binary data

Attachment: config
Description: Binary data