(cc gfs2 maintainers) On Tue, 20 Jul 2021 19:07:25 -0700 syzbot <syzbot+0d5b462a6f07447991b3@xxxxxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxx ------------[ 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
