From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BE7C9C63793 for ; Thu, 22 Jul 2021 13:16:34 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 41BA861353 for ; Thu, 22 Jul 2021 13:16:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 41BA861353 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A24806B0033; Thu, 22 Jul 2021 09:16:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9D5E96B005D; Thu, 22 Jul 2021 09:16:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 89C406B006C; Thu, 22 Jul 2021 09:16:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0211.hostedemail.com [216.40.44.211]) by kanga.kvack.org (Postfix) with ESMTP id 707D16B0033 for ; Thu, 22 Jul 2021 09:16:33 -0400 (EDT) Received: from smtpin31.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 1DA64181AEF39 for ; Thu, 22 Jul 2021 13:16:33 +0000 (UTC) X-FDA: 78390273066.31.9DAE6DA Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf09.hostedemail.com (Postfix) with ESMTP id 898BE3000132 for ; Thu, 22 Jul 2021 13:16:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1626959791; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zrvM6++D/Cm+PTxmLVCCo7fkYATcdC5zIdtektSyf68=; b=W0pjkFE7GJObyqeUP+ct3/G3xIPCuKPKq/Eze3ZpdSHBgT9P8DqKECRjjVwYl6yiGI3Hae Zbi1B+DFdR5mv33ufWVpg4YM6RRGyAzzqPIUkVjrq5QTALgNioEhH5dT5+FmIjrneFY54w PElbPdCRQlM9TOi1zDvD2xAZLLrlBNw= Received: from mail-il1-f200.google.com (mail-il1-f200.google.com [209.85.166.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-241-jXkBjQnhNN-nPrtuCZ8aEQ-1; Thu, 22 Jul 2021 09:16:28 -0400 X-MC-Unique: jXkBjQnhNN-nPrtuCZ8aEQ-1 Received: by mail-il1-f200.google.com with SMTP id t12-20020a92c0cc0000b0290210d3ffca31so3503770ilf.21 for ; Thu, 22 Jul 2021 06:16:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=zrvM6++D/Cm+PTxmLVCCo7fkYATcdC5zIdtektSyf68=; b=WuaHkp1kGSxKPe6fG9OehaV5AZzU+DXntePkKQcMUo8381+2UZnrp1C6fGYjSme6pl VqwElLcmTOpqEoVE3QJTBLxMyEOMld9cdwIRgTSKGi5arDPt7TW68wgQhDbbDhMXuOSK 0azAe6DZwJ4GPq+G1oPCLL8pTzXOXWOMRg5kuJCJKx1DwW/RbCxwj7oavGbT0vrlrkf9 K+8uFvxmnf7mT1ED/ivkPNlK/wwrq/cYJKupd8b3NDIuw7Y5EBwPMTCuNarJxlz7801D ucRJGVDm8Dp+mOImLipXdhY2YY+VpJzPDVeEsc5wSHyKUlUXK4CchlO4n3XUoeTMlB6D JqgQ== X-Gm-Message-State: AOAM531WmMz9T+AD4rs81tpxxc+lhPJXJl8lkYFt/Koyt04NIZLIT08+ qCmOAEccSMGs1/ssELBhHhByMbey80ve4SPFKo0Uy7KPzZEfmCPrBKGa/w2r5Trlk79gmP2+liv oqgIPSUKTDzU= X-Received: by 2002:a6b:6f11:: with SMTP id k17mr30463107ioc.114.1626959787532; Thu, 22 Jul 2021 06:16:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwwUDlSDVYG0sqmY8X3IQtXtYMmB6Lha2xjhU7I+R0ilxqWKIFRLvwIKzgGiUxiJnhuYVNV7A== X-Received: by 2002:a6b:6f11:: with SMTP id k17mr30463096ioc.114.1626959787312; Thu, 22 Jul 2021 06:16:27 -0700 (PDT) Received: from [172.16.0.19] (209-212-39-192.brainerd.net. [209.212.39.192]) by smtp.gmail.com with ESMTPSA id e9sm14544197ils.61.2021.07.22.06.16.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Jul 2021 06:16:26 -0700 (PDT) Subject: Re: [syzbot] WARNING in __set_page_dirty To: Andrew Morton , syzbot Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, syzkaller-bugs@googlegroups.com, Andreas Gruenbacher , cluster-devel@redhat.com References: <000000000000b25bb805c798a1a5@google.com> <20210721145801.8ca097bc1d9ad3d0018517bd@linux-foundation.org> From: Bob Peterson Message-ID: <302c13da-9bca-efb4-9659-6a0e9979c0bb@redhat.com> Date: Thu, 22 Jul 2021 08:16:25 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210721145801.8ca097bc1d9ad3d0018517bd@linux-foundation.org> X-Mimecast-Spam-Score: 1 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="------------A74727354DA106E60F37481C" Content-Language: en-US Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=W0pjkFE7; spf=none (imf09.hostedemail.com: domain of rpeterso@redhat.com has no SPF policy when checking 216.205.24.124) smtp.mailfrom=rpeterso@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 898BE3000132 X-Stat-Signature: zrm87jdza1tu36xrrpior1pd5peob7w7 X-HE-Tag: 1626959792-775043 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: This is a multi-part message in MIME format. --------------A74727354DA106E60F37481C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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 --------------A74727354DA106E60F37481C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
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@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@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


--------------A74727354DA106E60F37481C--