On 7/21/21 4:58 PM, Andrew Morton wrote: > (cc gfs2 maintainers) > > On Tue, 20 Jul 2021 19:07:25 -0700 syzbot wrote: > >> Hello, >> >> syzbot found the following issue on: >> >> HEAD commit: d936eb238744 Revert "Makefile: Enable -Wimplicit-fallthrou.. >> git tree: upstream >> console output: https://syzkaller.appspot.com/x/log.txt?x=1512834a300000 >> kernel config: https://syzkaller.appspot.com/x/.config?x=f1b998c1afc13578 >> dashboard link: https://syzkaller.appspot.com/bug?extid=0d5b462a6f07447991b3 >> userspace arch: i386 >> >> Unfortunately, I don't have any reproducer for this issue yet. >> >> IMPORTANT: if you fix the issue, please add the following tag to the commit: >> Reported-by: syzbot+0d5b462a6f07447991b3@syzkaller.appspotmail.com >> >> ------------[ cut here ]------------ >> WARNING: CPU: 0 PID: 8696 at include/linux/backing-dev.h:283 inode_to_wb include/linux/backing-dev.h:283 [inline] >> WARNING: CPU: 0 PID: 8696 at include/linux/backing-dev.h:283 account_page_dirtied mm/page-writeback.c:2435 [inline] >> WARNING: CPU: 0 PID: 8696 at include/linux/backing-dev.h:283 __set_page_dirty+0xace/0x1070 mm/page-writeback.c:2483 > Okay, sorry for the brain fart earlier. After taking a better look, I know exactly what this is. This goes back to this discussion from April 2018: https://listman.redhat.com/archives/cluster-devel/2018-April/msg00017.html in which Jan Kara pointed out that: "The problem is we really do expect mapping->host->i_mapping == mapping as we pass mapping and inode interchangebly in the mm code. The address_space and inodes are separate structures because you can have many inodes pointing to one address space (block devices). However it is not allowed for several address_spaces to point to one inode!" The problem is that GFS2 keeps separate address spaces for its glocks, and they don't correspond 1:1 to any inode. So mapping->host is not really an inode for these, and there's really almost no relation between the glock->mapping and the inode it points to. Even in the recent past, GFS2 did this for all metadata for both its media-backed glocks: resource groups and inodes. I recently posted a patch set to cluster-devel ("gfs2: replace sd_aspace with sd_inode" - https://listman.redhat.com/archives/cluster-devel/2021-July/msg00066.html) in which I fixed half the problem, which is the resource group case. Unfortunately, for inode glocks it gets a lot trickier and I haven't found a proper solution. But as I said, it's been a known issue for several years now. The errors only appear if LOCKDEP is turned on. It would be ideal if address spaces were treated as fully independent from their inodes, but no one seemed to jump on that idea, nor even try to explain why we make the assumptions Jan Kara pointed out. In the meantime, I'll keep looking for a more proper solution. This won't be an easy thing to fix or I would have already fixed it. Regards, Bob Peterson