Re: [syzbot ci] Re: ext4: use iomap for regular file's buffered I/O path

[Ojaswin Mujoo]

On Sat, Oct 10, 2026 at 04:44:52PM +0800, Zhang Yi wrote:
> On 10/10/2026 1:54 AM, syzbot ci wrote:
> > syzbot ci has tested the following series
> > 
> 
> [...]
> 
> > and found the following issue:
> > WARNING in ext4_do_writepages
> > 
> > Full report is available here:
> > https://ci.syzbot.org/series/3711c951-acf4-4ebe-a920-9cc89b6be2ff
> > 
> > ***
> > 
> > WARNING in ext4_do_writepages
> > 
> > tree:      vfs
> > URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/vfs/vfs.git
> > base:      3d399224425573875b6f6f1181bd8cf9a28cc7d1
> > arch:      amd64
> > compiler:  Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8
> > config:    https://ci.syzbot.org/builds/c3c01f8c-846d-4c7a-955a-fd7427af6b0d/config
> > 
> > ------------[ cut here ]------------
> > !err
> > WARNING: fs/ext4/inode.c:2512 at ext4_do_writepages+0x33b3/0x44a0, CPU#0: kworker/u9:3/147
> > Modules linked in:
> > CPU: 0 UID: 0 PID: 147 Comm: kworker/u9:3 Not tainted syzkaller #0 PREEMPT(full) 
> > Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
> > Workqueue: writeback wb_workfn (flush-7:1)
> > RIP: 0010:ext4_do_writepages+0x33b3/0x44a0
> > Code: 0f 0b 90 e9 b6 d9 ff ff e8 6a e2 36 ff 90 0f 0b 90 e9 e6 dc ff ff e8 5c e2 36 ff 90 0f 0b 90 e9 94 df ff ff e8 4e e2 36 ff 90 <0f> 0b 90 bb ea ff ff ff e9 ae f8 ff ff e8 3b e2 36 ff 48 8d 3d 64
> > RSP: 0018:ffffc90003106ce0 EFLAGS: 00010293
> > RAX: ffffffff8290e912 RBX: 0000000000000000 RCX: ffff8881053f9e00
> > RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
> > RBP: ffffc900031070f0 R08: ffff888025da4a37 R09: 1ffff11004bb4946
> > R10: dffffc0000000000 R11: ffffed1004bb4947 R12: ffffc900031071a0
> > R13: dffffc0000000000 R14: 0000000000000000 R15: 1ffff11004bb495d
> > FS:  0000000000000000(0000) GS:ffff88818d6c9000(0000) knlGS:0000000000000000
> > CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 00005555565a5a28 CR3: 0000000031f66000 CR4: 00000000000006f0
> > Call Trace:
> >  <TASK>
> >  ext4_writepages+0x241/0x3b0
> >  do_writepages+0x338/0x560
> >  __writeback_single_inode+0x136/0x1220
> >  writeback_sb_inodes+0x9de/0x1b00
> >  wb_writeback+0x41c/0xad0
> >  wb_workfn+0x431/0x10f0
> >  process_scheduled_works+0xc3d/0x1630
> >  worker_thread+0xa47/0xfb0
> >  kthread+0x38b/0x480
> >  ret_from_fork+0x514/0xb70
> >  ret_from_fork_asm+0x1a/0x30
> >  </TASK>
> > 
> > 
> 
> This WARNING was newly introduced by patch 8, "ext4: skip block
> allocation for holes in the data submission path". It doesn't actually
> cause a new regression, it just appears to expose a pre-existing issue
> in the buffer_head buffered I/O path, where an inconsistency between
> the bh and extent state could potentially lead to allocating a block and
> writing data into a hole. The logic of the patch itself is fine. To
> avoid noise, I can drop the WARN_ON_ONCE() while still keeping return
> -EINVAL. Thoughts?

Hi Zhang,

I think we can keep the WARN_ON. Failing in writeback here will anyways
throw out some error messages about data loss so having an extra WARN
dump should be okay. It will help us find and eliminate paths that cause
this quickly, like your patch for the inline truncate fix.

Regards,
ojaswin

> 
> Thanks,
> Yi.
> 
> > ***
> > 
> > If these findings have caused you to resend the series or submit a
> > separate fix, please add the following tag to your commit message:
> >   Tested-by: syzbot@xxxxxxxxxxxxxxxxxxxxxxxxx
> > 
> > ---
> > This report is generated by a bot. It may contain errors.
> > syzbot ci engineers can be reached at syzkaller@xxxxxxxxxxxxxxxx.
> > 
> > To test a fix for this bug, please reply with `#syz test`
> > (on a separate line) and attach the patch to the email.
> > 
> > Notes:
> > - The patch will be applied on top of the tested series (as an
> >   incremental fix).
> > - To test a new version of the whole series, please send it directly
> >   to syzbot@xxxxxxxxxxxxxxx.
> > - Arguments like custom git repos and branches are not supported.
>