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=-7.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 8B3D7C6377D for ; Thu, 22 Jul 2021 13:52:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 441F961249 for ; Thu, 22 Jul 2021 13:52:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 441F961249 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 7B3386B0036; Thu, 22 Jul 2021 09:52:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 73BB26B005D; Thu, 22 Jul 2021 09:52:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5B5A86B006C; Thu, 22 Jul 2021 09:52:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0123.hostedemail.com [216.40.44.123]) by kanga.kvack.org (Postfix) with ESMTP id 3BD616B0036 for ; Thu, 22 Jul 2021 09:52:14 -0400 (EDT) Received: from smtpin31.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id DE6CC8249980 for ; Thu, 22 Jul 2021 13:52:13 +0000 (UTC) X-FDA: 78390362946.31.C4C4109 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf10.hostedemail.com (Postfix) with ESMTP id 51A3D60019A5 for ; Thu, 22 Jul 2021 13:52:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1626961932; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ESge0KHDhWJ77b/8SSXjjC4o9lBAjOzbV5TN7hr2oSw=; b=JuisFENm7gig11jlMBn2euap56VykJH6+udwTja8RqhXaH5ebHjY/NXGv4OkknMYfh5F+4 JEtJXVpfS05SYjhJirIk2l0YniXR36TxYEl46k3YDDHxWSCAK0HBKBwH2v5YFexuFemM32 B7rsUIxPasT48h/GpDftFDcGlAORY7g= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-479-zVYsI1bGODSE2FnxRZ2lTw-1; Thu, 22 Jul 2021 09:52:10 -0400 X-MC-Unique: zVYsI1bGODSE2FnxRZ2lTw-1 Received: by mail-wm1-f70.google.com with SMTP id h22-20020a7bc9360000b0290215b0f3da63so410054wml.3 for ; Thu, 22 Jul 2021 06:52:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:organization:user-agent:mime-version :content-transfer-encoding; bh=ESge0KHDhWJ77b/8SSXjjC4o9lBAjOzbV5TN7hr2oSw=; b=PLuHw1z29VK6wlElw3X7UPWN4cKGeiI52585kLGag9srI3tckpH6Os1I5BadnDNgno XPcdKvFBZEYNsp4uZ9LrxyeSRFL35ssDwf6GWfcBKnrvpAvvwvW6JecfYiYm79zxOGXh b0uljd31+ixwpK/Xro+pyVwOGPnJBrXHyzu31dpaxoUCrpCKa7F9IlvS2vL1C6UDWwG5 w/9F43XQlB7EHH6/mNlqWAn2vYyMYMoz37pLef1axvMDriedE+5PK6iJDaOWI52qeRXs APw/1NNngCJDlJeoNcNZOZrZf1HsyyZcxCzJkQIzVrUrqITyianjkxpWLXw5X58pfClD MLyg== X-Gm-Message-State: AOAM530yx83wR85ED+xoYPScNjjHgpN8vA72MosIfDwRLDZbJ0PCAvxK tr/I8CStQE0x1K7T8Tl7hbgJJoPmMhE6xPHEThNr27IJ9sUBHfqG+pT88H+GjUz8mqlQ7gHSZ2K jpFEpUUXKiCk= X-Received: by 2002:a05:6000:1b0c:: with SMTP id f12mr48780178wrz.225.1626961929255; Thu, 22 Jul 2021 06:52:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzYVurwPTRb97ntwTd8UIDowdCWmKx3cnpZmclnzQMDREqVCvrbQz316b0cKwU/u4lpKBycHQ== X-Received: by 2002:a05:6000:1b0c:: with SMTP id f12mr48780142wrz.225.1626961928817; Thu, 22 Jul 2021 06:52:08 -0700 (PDT) Received: from 0.7.3.c.2.b.0.0.0.3.7.8.9.5.0.2.0.0.0.0.a.d.f.f.0.b.8.0.1.0.0.2.ip6.arpa (0.7.3.c.2.b.0.0.0.3.7.8.9.5.0.2.0.0.0.0.a.d.f.f.0.b.8.0.1.0.0.2.ip6.arpa. [2001:8b0:ffda:0:2059:8730:b2:c370]) by smtp.gmail.com with ESMTPSA id c125sm3063781wme.36.2021.07.22.06.52.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Jul 2021 06:52:08 -0700 (PDT) Message-ID: <2b8e94f7a401fc98a7fce3daaa9fd63e7324e426.camel@redhat.com> Subject: Re: [Cluster-devel] [syzbot] WARNING in __set_page_dirty From: Steven Whitehouse To: Bob Peterson , Andrew Morton , syzbot Cc: cluster-devel@redhat.com, linux-mm@kvack.org, syzkaller-bugs@googlegroups.com, linux-kernel@vger.kernel.org Date: Thu, 22 Jul 2021 14:52:02 +0100 In-Reply-To: <302c13da-9bca-efb4-9659-6a0e9979c0bb@redhat.com> References: <000000000000b25bb805c798a1a5@google.com> <20210721145801.8ca097bc1d9ad3d0018517bd@linux-foundation.org> <302c13da-9bca-efb4-9659-6a0e9979c0bb@redhat.com> Organization: Red Hat UK Ltd User-Agent: Evolution 3.34.4 (3.34.4-1.fc31) MIME-Version: 1.0 X-Mimecast-Spam-Score: 1 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=JuisFENm; spf=none (imf10.hostedemail.com: domain of swhiteho@redhat.com has no SPF policy when checking 216.205.24.124) smtp.mailfrom=swhiteho@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspamd-Server: rspam02 X-Stat-Signature: ryjun4sqxpctmxxku4xsctuk1hmwezeu X-Rspamd-Queue-Id: 51A3D60019A5 X-HE-Tag: 1626961933-17873 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: Hi, On Thu, 2021-07-22 at 08:16 -0500, Bob Peterson wrote: > 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 > > The reason for having address_spaces pointed to by many inodes is to allow for stackable filesytems so that you can make the file content available on the upper layer by just pointing the upper layer inode at the lower layer address_space. That is presumably what Jan is thinking of. This however seems to be an issue with a page flag, so it isn't clear why that would relate to the address_space? If the page is metadata which would be the most usual case for something being unpinned, then that page should definitely be up to date. Looking back at the earlier rgrp fix mentioned above, the fix is not unreasonable since there only needs to be a single inode to contain all the rgrps. For the inode metadata that is not the case, there is a one to one mapping between inodes and metadata address_spaces, and if the working assumption is that multiple address_spaces per inode is not allowed, then I think that has changed over time. I'm pretty sure that I had checked the expectations way back when we adopted this solution, and that there were no issues with the multiple address_spaces per inode case. We definitely don't want to go back to adding an additional struct inode structure (which does nothing except take up space!) to each "real" inode in cache, because it is a big overhead in case of a filesystem with many small files. Still if this is only a lockdep issue, then we likely have some time to figure out a good long term solution, Steve.