On Sat 30-11-19 00:30:03, Tetsuo Handa wrote: > On 2019/11/29 23:41, Vlastimil Babka wrote: > > On 11/29/19 9:19 AM, syzbot wrote: > >> Hello, > >> > >> syzbot found the following crash on: > >> > >> HEAD commit: 089cf7f6 Linux 5.3-rc7 > > > > Ugh, why test previous cycle's rc7 now? Typo for 5.4? > > > >> git tree: upstream > >> console output: https://syzkaller.appspot.com/x/log.txt?x=1210a761600000 > >> kernel config: https://syzkaller.appspot.com/x/.config?x=b89bb446a3faaba4 > >> dashboard link: https://syzkaller.appspot.com/bug?extid=fe601f9e887449d40112 > >> compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > Please open the dashboard link. The first occurrence was 5.3-rc7 and the last > occurrence was 5.4-rc7+. In other words, this bug is likely not yet fixed. I've briefly looked at this so I'll dump my memory state here in case someone wants to have a look (or for me when I get more time to look into this): The problem always happens on block device mapping. What I think is happening is that truncate_inode_pages() races with some filesystem on top of that block device holding buffer_head reference and calling mark_buffer_dirty(). The buffer_head reference makes block_invalidatepage() fail invalidating page buffers (try_to_release_page() respectively) and following mark_buffer_dirty() call will happily redirty the page in whatever state it is. Now I didn't yet made up my mind what would be a proper way to fix this... Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR