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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C5F4BC36010 for ; Mon, 7 Apr 2025 18:21:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5B49C6B0007; Mon, 7 Apr 2025 14:21:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4E8726B000A; Mon, 7 Apr 2025 14:21:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 362616B000C; Mon, 7 Apr 2025 14:21:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 149FF6B0007 for ; Mon, 7 Apr 2025 14:21:24 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 66F821414B0 for ; Mon, 7 Apr 2025 18:21:24 +0000 (UTC) X-FDA: 83308065288.13.16ADB2B Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf19.hostedemail.com (Postfix) with ESMTP id 3806B1A0003 for ; Mon, 7 Apr 2025 18:21:21 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=XSgNTSwr; dmarc=pass (policy=quarantine) header.from=redhat.com; spf=pass (imf19.hostedemail.com: domain of agruenba@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=agruenba@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744050082; a=rsa-sha256; cv=none; b=hHCO7Tng0c4WeX7pTwWPuqSaT6rpPQuYu1KZzy0ONXwV42Sc9oc+foT2h4tHFjHpZ4ZCrc AnH1KAFZs01KljFjUOs0KpAskcsfsY9SYtUKQTo6nJGCJrd7kPj08dbx9+TW+06W7V0bht aIigAU1YBAmheutDUvNpYIGO/WpOL6Y= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=XSgNTSwr; dmarc=pass (policy=quarantine) header.from=redhat.com; spf=pass (imf19.hostedemail.com: domain of agruenba@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=agruenba@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744050082; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=q8XINgkR0EpGHnvrRPK+wYqXQDcUTHVKWdQf0hfOUpA=; b=wY0gC0HmMuBZL9iwUtBsNLry+qOVN3PJg6xD8dDKjaec+6DI8yUYGsxrv/ZnytV5rkn6VX /7DQc1hTVw1kvoq2LhexEkvK7VDx1ZJSrI3K88+6hDfzvCIqax0pfvTF2YNhPnRpUwY0bY yV7+o8vq3Y5V7mj5ZM5kfAFRpLdydWE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1744050080; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=q8XINgkR0EpGHnvrRPK+wYqXQDcUTHVKWdQf0hfOUpA=; b=XSgNTSwrpJzUYjzZrLoItwqc3v3VCKbxT4J5As0AogTSiKcsPx1i7dnlBNVxSbNtFWRNpC jupdYD2ck0qz0VkXK0tW2xyNfJ/8m3FmMoBxIkwi03PtCg1esTau8l9VWe9Fh1FgUxujOc d+D1NNA/KQqx+nRBiAeFGjIPIGxGaow= Received: from mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-621-hgifSGuqOx2mCksrpurQvA-1; Mon, 07 Apr 2025 14:21:11 -0400 X-MC-Unique: hgifSGuqOx2mCksrpurQvA-1 X-Mimecast-MFC-AGG-ID: hgifSGuqOx2mCksrpurQvA_1744050069 Received: from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 070CC195608A; Mon, 7 Apr 2025 18:21:09 +0000 (UTC) Received: from pasta.fast.eng.rdu2.dc.redhat.com (unknown [10.45.224.15]) by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 919361828AB9; Mon, 7 Apr 2025 18:21:05 +0000 (UTC) From: Andreas Gruenbacher To: cgroups@vger.kernel.org Cc: Andreas Gruenbacher , Tetsuo Handa , Jan Kara , Rafael Aquini , gfs2@lists.linux.dev, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [RFC 0/2] Fix false warning in inode_to_wb Date: Mon, 7 Apr 2025 20:21:00 +0200 Message-ID: <20250407182104.716631-1-agruenba@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.93 X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 3806B1A0003 X-Stat-Signature: 97uok74zg6fapmsxqd9xdixa6ko3judt X-HE-Tag: 1744050081-834759 X-HE-Meta: U2FsdGVkX1+NObW8TmE41wCU1X8NLT2VY5xlfHP6N8AYSRFN/jm3/7h9WSIicXGA9ulIk5NaqMuFfav433TNu5i9wtUXSQS4ZHX7IbL4Me3CrR/apdTzrVBn25nlzAVGBNeuCpQHHBNjO5QnH9V5D688ubDqPk6NTTo/dkDoFVn6ur/+iJmU02+MATzzSedmPXQ5fhXNVaen/39mnZ0sWjMzZGcHIXoEWsi2A7zdounMAnHj0CI1+uDYRHZ/pRbTpTWCmSI9a92eTr8C28UTdwUh+QKD3xa/RN8ZUNHXQ7z22nAU17OG+XfNbxc8cwkykEB0qjVx7dNnRdsN0NhisSH43VYuin9tAH2s8cNGuXhvZEsnEe0hWOhW5kDxQI3ZHWhwMBA9Uul9ttyTOTsFDFnzbPUJlD7jNWGIMBVHPOjl9jocMNYb/2QU5xbfJGz+xjxbd+mdiK5/xZP4nDiEWBggoGf0IHookgggkF2Dcvax2/ydzqUy+ZQSvjUAacCfh8zI9/OF/b41lS/IKsVI+ZVxqaNlXQNsJD08Zo/+HM5P256dM17G48F4EO2yLdsZ/2ydcL6Eu7QI1mjXhAgaCY1glp4fIQrZz3tWWs9eu1Ksy4MI/C6cLxkxNyQMyU0V1vRKNtoC+YgauenoxdmLydn8nMPJ46hfyApSEZs9fpyPquF2TiOnIEhGmx/zPLwV8I0epN+JggH17OA6D27gD5aqvGr2Bs28B4LMVOowilbPu/0vp1jN++P6k0K+ZwHSbzpsW8OgCQJHvBjgSbL5/1rQxyfbMcfc9dcneji3/FR885qP+RWiUojixg+wjKE7PqxKkSC1t7Jj0ctE8hE3Y9H6kBEfsuveLxrekHCWN/uh7T494DzATZNu4KCVaXkKjEobjjwQi3182ZmnkgZBWmQqnoCQjSGPCVFIv1cS0gMH84iCW6godKbmHTABW+qwHEnbKxH6Rv4X91uGarf +YTTaEPI sfC94/WKHDBXl/Ymc+yyL4JJ7mi8/iZ5UDP/d1qbjO6rhSagxjS7d/woGLeYzZY94Go4qfVnBmmtf2fpcXhdnk/p3WGmKkjGWIH8ydJ9tuy45GQTnD0nlC5DkjJqvKX42Bkb5nmvbqtFzczjdt3dWgmWsJ7csi8c132peI915gQI2SwdIyyrMUrKEauRgJs30XqH6LWko3w0E2ue0nWdU2u28MBiRttg7LBSAuyCClWviR/csh/K2UlTKE46nVz/e4sqiKJrCxcM9kIVCyKjl4EOxx6cWEd2EInspb370jNbH2YnRf9mGiLxHwnZTP0KgAgWeO79HzWPT1z71t/NVKeZ+UvVtbC6JMNvC/ttnCkMy1aV++FJgwz1+wiG9S1h0Ix5u1Ezr88Iq3di/4AXiTQ+kaw== 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: List-Subscribe: List-Unsubscribe: Hello, when CONFIG_LOCKDEP is enabled, gfs2 triggers the following warning in inode_to_wb() (include/linux/backing-dev.h) for a number of filesystem-internal inodes: static inline struct bdi_writeback *inode_to_wb(const struct inode *inode) { #ifdef CONFIG_LOCKDEP WARN_ON_ONCE(debug_locks && (!lockdep_is_held(&inode->i_lock) && !lockdep_is_held(&inode->i_mapping->i_pages.xa_lock) && !lockdep_is_held(&inode->i_wb->list_lock))); #endif return inode->i_wb; } This unfortunately makes lockdep unusable for gfs2. In the most recent bug report about that problem [1], Jan Kara dug into this and he concluded that when cgroup writeback is disabled, inode->i_wb should be stable without any additional locking and the warnings are not justified. So can we please add an inode_cgwb_enabled() check to inode_to_wb() as in Jan's patch in this series? With that, a minor problem remains at the filesystem level: Cgroup writeback is only enabled on filesystems that enable the SB_I_CGROUPWB super block flag. Unfortunately, gfs2 creates a separate address space for filesystem metadata (sd_aspace) and sets its mapping->host to sb->s_bdev->bd_mapping->host. That's a "bdev" inode with a super block that has SB_I_CGROUPWB set. I'm not aware of any other filesystems doing that. To fix that, the first patch in this series creates an anonymous inode instead of an isolated address space. In that inode, ->i_mapping->host points back at the inode and ->i_sb points at a gfs2 super block which and doesn't have SB_I_CGROUPWB set. And then there is another peculiarity of gfs2: while an 'ordinary' inode has one address space for managing the inode's page cache, a gfs2 inode also has a second address space for managing the inode's metadata cache. These address spaces also point at sb->s_bdev->bd_mapping->host, causing the same problem as above. To fix that, the first patch changes ->host of those address spaces to point at the new anonymous inode as well. Using address spaces in this particular way seems to be pretty unusual and there's a real risk that it will break some day, but I haven't found a reasonable alternative so far. Two previous discussions about this bug can be found here: [1] https://lore.kernel.org/gfs2/ebfe4024-f908-458d-9979-6ff2931c460d@I-love.SAKURA.ne.jp/ [2] https://lore.kernel.org/all/20210713180958.66995-11-rpeterso@redhat.com/ Thanks, Andreas Andreas Gruenbacher (1): gfs2: replace sd_aspace with sd_inode Jan Kara (1): writeback: Fix false warning in inode_to_wb() fs/gfs2/glock.c | 3 +-- fs/gfs2/glops.c | 4 ++-- fs/gfs2/incore.h | 9 ++++++++- fs/gfs2/meta_io.c | 2 +- fs/gfs2/meta_io.h | 4 +--- fs/gfs2/ops_fstype.c | 24 +++++++++++++----------- fs/gfs2/super.c | 2 +- include/linux/backing-dev.h | 3 ++- 8 files changed, 29 insertions(+), 22 deletions(-) -- 2.48.1