[Cluster-devel] [syzbot] WARNING in __set_page_dirty

[Bob Peterson]

On 7/21/21 4:58 PM, Andrew Morton wrote:
> (cc gfs2 maintainers)
>
> On Tue, 20 Jul 2021 19:07:25 -0700 syzbot <syzbot+0d5b462a6f07447991b3 at syzkaller.appspotmail.com> 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 at 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/cluster-devel/attachments/20210722/e1a3c285/attachment.htm>