Re: [syzbot] [ext4?] WARNING in ext4_dio_write_end_io

[Jan Kara]

On Wed 22-11-23 07:10:31, syzbot wrote:
> syzbot found the following issue on:
> 
> HEAD commit:    98b1cc82c4af Linux 6.7-rc2
> git tree:       upstream
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=15e09a9f680000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=6ae1a4ee971a7305
> dashboard link: https://syzkaller.appspot.com/bug?extid=47479b71cdfc78f56d30
> compiler:       gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=13c09a00e80000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=151d5320e80000
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/39c6cdad13fc/disk-98b1cc82.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/5a77b5daef9b/vmlinux-98b1cc82.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/5e09ae712e0d/bzImage-98b1cc82.xz
> 
> The issue was bisected to:
> 
> commit 91562895f8030cb9a0470b1db49de79346a69f91
> Author: Jan Kara <jack@xxxxxxx>
> Date:   Fri Oct 13 12:13:50 2023 +0000
> 
>     ext4: properly sync file size update after O_SYNC direct IO
> 
> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=17d0f0c8e80000
> final oops:     https://syzkaller.appspot.com/x/report.txt?x=1430f0c8e80000
> console output: https://syzkaller.appspot.com/x/log.txt?x=1030f0c8e80000
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+47479b71cdfc78f56d30@xxxxxxxxxxxxxxxxxxxxxxxxx
> Fixes: 91562895f803 ("ext4: properly sync file size update after O_SYNC direct IO")
> 
> ------------[ cut here ]------------
> WARNING: CPU: 1 PID: 4481 at fs/ext4/file.c:391 ext4_dio_write_end_io+0x1db/0x220 fs/ext4/file.c:391

OK, so I could easily reproduce this which is good :). It took a bit longer
to actually debug what's going on. In the end I've confirmed this is a
false positive (the assertion isn't 100% reliable). What happens is that
the IO end completion races with expanding truncate (which is not
synchronized with DIO in any way) and the assertion sees a situation where
i_disksize was updated but i_size not yet. This is mostly harmless but we
better should complete the DIO only once we are sure truncate has updated
the i_size as well. I'll think how to best do this.

								Honza
-- 
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR