<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 7/21/21 4:58 PM, Andrew Morton
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:20210721145801.8ca097bc1d9ad3d0018517bd@linux-foundation.org">
      <pre class="moz-quote-pre" wrap="">(cc gfs2 maintainers)

On Tue, 20 Jul 2021 19:07:25 -0700 syzbot <a class="moz-txt-link-rfc2396E" href="mailto:syzbot+0d5b462a6f07447991b3@syzkaller.appspotmail.com"><syzbot+0d5b462a6f07447991b3@syzkaller.appspotmail.com></a> wrote:

</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">Hello,

syzbot found the following issue on:

HEAD commit:    d936eb238744 Revert "Makefile: Enable -Wimplicit-fallthrou..
git tree:       upstream
console output: <a class="moz-txt-link-freetext" href="https://syzkaller.appspot.com/x/log.txt?x=1512834a300000">https://syzkaller.appspot.com/x/log.txt?x=1512834a300000</a>
kernel config:  <a class="moz-txt-link-freetext" href="https://syzkaller.appspot.com/x/.config?x=f1b998c1afc13578">https://syzkaller.appspot.com/x/.config?x=f1b998c1afc13578</a>
dashboard link: <a class="moz-txt-link-freetext" href="https://syzkaller.appspot.com/bug?extid=0d5b462a6f07447991b3">https://syzkaller.appspot.com/bug?extid=0d5b462a6f07447991b3</a>
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: <a class="moz-txt-link-abbreviated" href="mailto:syzbot+0d5b462a6f07447991b3@syzkaller.appspotmail.com">syzbot+0d5b462a6f07447991b3@syzkaller.appspotmail.com</a>

------------[ 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
</pre>
      </blockquote>
      <br>
    </blockquote>
    <p>Okay, sorry for the brain fart earlier. After taking a better
      look, I know exactly what this is.<br>
      This goes back to this discussion from April 2018:</p>
    <p><a class="moz-txt-link-freetext"
href="https://listman.redhat.com/archives/cluster-devel/2018-April/msg00017.html">https://listman.redhat.com/archives/cluster-devel/2018-April/msg00017.html</a><br>
    </p>
    <p>in which Jan Kara pointed out that:</p>
    <pre>"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!"</pre>
    <p>The problem is that GFS2 keeps separate address spaces for its
      glocks, and they<br>
      don't correspond 1:1 to any inode. So mapping->host is not
      really an inode for these,<br>
      and there's really almost no relation between the
      glock->mapping and the inode it<br>
      points to.</p>
    <p>Even in the recent past, GFS2 did this for all metadata for both
      its media-backed glocks:<br>
      resource groups and inodes.<br>
      <br>
      I recently posted a patch set to cluster-devel ("gfs2: replace
      sd_aspace with sd_inode" -<br>
<a class="moz-txt-link-freetext" href="https://listman.redhat.com/archives/cluster-devel/2021-July/msg00066.html">https://listman.redhat.com/archives/cluster-devel/2021-July/msg00066.html</a>)
      in which<br>
      I fixed half the problem, which is the resource group case.</p>
    <p>Unfortunately, for inode glocks it gets a lot trickier and I
      haven't found a proper solution.<br>
      But as I said, it's been a known issue for several years now. The
      errors only appear<br>
      if LOCKDEP is turned on. It would be ideal if address spaces were
      treated as fully<br>
      independent from their inodes, but no one seemed to jump on that
      idea, nor even try to<br>
      explain why we make the assumptions Jan Kara pointed out.</p>
    <p>In the meantime, I'll keep looking for a more proper solution.
      This won't be an easy<br>
      thing to fix or I would have already fixed it.<br>
    </p>
    <p>Regards,</p>
    <p>Bob Peterson</p>
    <p><br>
    </p>
  </body>
</html>