On Thu 19-05-22 16:14:17, Tadeusz Struk wrote: > On 5/19/22 05:23, Jan Kara wrote: > > Hi! > > > > On Tue 10-05-22 15:28:38, Tadeusz Struk wrote: > > > Syzbot found another BUG in ext4_writepages [1]. > > > This time it complains about inode with inline data. > > > C reproducer can be found here [2] > > > I was able to trigger it on 5.18.0-rc6 > > > > > > [1] https://syzkaller.appspot.com/bug?id=a1e89d09bbbcbd5c4cb45db230ee28c822953984 > > > [2] https://syzkaller.appspot.com/text?tag=ReproC&x=129da6caf00000 > > > > Thanks for report. This should be fixed by: > > > > https://lore.kernel.org/all/20220516012752.17241-1-yebin10@xxxxxxxxxx/ > > > In case of the syzbot bug there is something messed up with PAGE DIRTY flags > and the way syzbot sets up the write. This is what triggers the crash: Can you tell me where exactly we hit the bug? I've now noticed that this is on 5.10 kernel and on vanilla 5.10 there's no BUG_ON on line 2753. > $ ftrace -f ./repro > ... > [pid 2395] open("./bus", O_RDWR|O_CREAT|O_SYNC|O_NOATIME, 000 <unfinished ...> > [pid 2395] <... open resumed> ) = 6 > ... > [pid 2395] write(6, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 22 <unfinished ...> > ... > [pid 2395] <... write resumed> ) = 22 > > One way I could fix it was to clear the PAGECACHE_TAG_DIRTY on the mapping in > ext4_try_to_write_inline_data() after the page has been updated: > > diff --git a/fs/ext4/inline.c b/fs/ext4/inline.c > index 9c076262770d..e4bbb53fa26f 100644 > --- a/fs/ext4/inline.c > +++ b/fs/ext4/inline.c > @@ -715,6 +715,7 @@ int ext4_try_to_write_inline_data(struct address_space *mapping, > put_page(page); > goto out_up_read; > } > + __xa_clear_mark(&mapping->i_pages, 0, PAGECACHE_TAG_DIRTY); > } > ret = 1; > > Please let me know it if makes sense any I will send a proper patch. No, this looks really wrong... We need to better understand what's going on. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
