Received: by 2002:a05:6358:51dd:b0:131:369:b2a3 with SMTP id 29csp1292813rwl; Thu, 10 Aug 2023 09:04:31 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEaHokjwcF67mGkBvKKGrD5NcLsQ2iKVdLHRHmfnV8TtkY2jizb29EdhRG9GOz93zpxjNWw X-Received: by 2002:a05:6a00:23d4:b0:67e:4313:811e with SMTP id g20-20020a056a0023d400b0067e4313811emr2920801pfc.0.1691683471275; Thu, 10 Aug 2023 09:04:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691683471; cv=none; d=google.com; s=arc-20160816; b=yRfrfZtaHEKvwBpcxaKFH5KBSebOVzsCvAc5p+FQIqG/78oB6l7Vq0x0uM30SCUiZ/ C6B/qMJqj4kTKue/htU+99fZv3wxwbqVjSPTEWmLWyCD403tdgRrSjggO1ziu4Zo7mx/ jQg9pFvGGaN1+inxvcPoEIqxqygmLos1+JvDSpvMXSVhH0dPuoan6XL1pom7rOtvBy+r hy2DI6raMdH1QQSg1he2Kx2kr/GsF1B9n6ucy0vBXJxkrP6lL0lhHVW03f0tzgJ4wxZB Qk5jILIEIwy0gDF94JGEewAlBHyO3t4aYZoUekTlH7Gu2NheXOh3xsdArD1MgapMFO1C S+WQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=oJjxYB+VnOdznQbJ/7HapldR2GGcFMXDHqjGFJ5VUgc=; fh=QvUukaToVvmwKTWPQ2FjRVQpBGonqX2KMXZgemhKeqo=; b=QlmUhRcEc/QMQKsZVnIJFav2q2KBIfofFITaiTtCSqQY6ZcEgs4QccO6nMIYvnMuOL SiI64TluoOH4TT7de0O8fQRqFbbvMqxhmBJAtaTBw4y7oC67YsBSNV+Lobe+ZhuMf8Ky nGYhsKdfyAcHKDbdbaJjD27RCDwRArpwlGiyHGChBOiR0mzM9ZddDEBq7OjnwbyyciuW wzxBBvVhaFv0yHSxhA7s5JqwbrMxkDVux7PSiy8MmRF915Ft0sq7R2WiKYbTdQ+deGXJ 5qgD5xDwxMPxjEsbqylNo/+eJmDyXTWALbsbHpU2ObPpnbqV3qONE6rcHjE4UQByHxta ESWg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=cq1+RYpO; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f6-20020a056a00228600b00687427c1ac1si1874007pfe.25.2023.08.10.09.04.14; Thu, 10 Aug 2023 09:04:31 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=cq1+RYpO; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235544AbjHJP5M (ORCPT + 99 others); Thu, 10 Aug 2023 11:57:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47012 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236317AbjHJP5H (ORCPT ); Thu, 10 Aug 2023 11:57:07 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 541521994; Thu, 10 Aug 2023 08:57:07 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id E369E66112; Thu, 10 Aug 2023 15:57:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3DA41C433C7; Thu, 10 Aug 2023 15:57:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1691683026; bh=k+0hriTLgqlay4j5d2D8hsnyhR1p1Uo2rvxvVbvjk20=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=cq1+RYpOf/dpj9Ex4Aq+Pk0UdxzluXEPyZ2wq6nyBPypfunvwgea22KiY8po6muY+ 18mDN04IOsNi2Ij1TOaRobtt/uw/pzxr5OojiWdbfDdn9G5wMWHF0SpWzXNp/Mn79y 0yShEovF4IyaS+2hWaeSagtr+K1aq9DJIC+GBvDl2ux497v9XbBhEf8caAszVZ0/yS K1nfyIDjojLE+Ul6d8ttKvyIwkdwSTf8y9sNQM2WaWru+nXdwS0mLnJZ9K4iKNt0j6 zzvuuw9vgdbFYr239u3uIdIiYTGbrcggcabaM5j5PdXI7kUUyRFI1GtBN0tLPFbROG WUFFGgqdjk1rA== Date: Thu, 10 Aug 2023 08:57:05 -0700 From: "Darrick J. Wong" To: Matthew Wilcox Cc: Christoph Hellwig , Al Viro , Christian Brauner , Namjae Jeon , Sungjong Seo , Theodore Ts'o , Andreas Dilger , Konstantin Komarov , linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, ntfs3@lists.linux.dev, linux-xfs@vger.kernel.org Subject: Re: [PATCH 07/13] xfs: document the invalidate_bdev call in invalidate_bdev Message-ID: <20230810155705.GC11352@frogsfrogsfrogs> References: <20230809220545.1308228-1-hch@lst.de> <20230809220545.1308228-8-hch@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Thu, Aug 10, 2023 at 04:22:15PM +0100, Matthew Wilcox wrote: > On Wed, Aug 09, 2023 at 03:05:39PM -0700, Christoph Hellwig wrote: > > + /* > > + * Udev is triggered whenever anyone closes a block device or unmounts > > + * a file systemm on a block device. > > + * The default udev rules invoke blkid to read the fs super and create > > + * symlinks to the bdev under /dev/disk. For this, it uses buffered > > + * reads through the page cache. > > + * > > + * xfs_db also uses buffered reads to examine metadata. There is no > > + * coordination between xfs_db and udev, which means that they can run > > + * concurrently. Note there is no coordination between the kernel and > > + * blkid either. > > + * > > + * On a system with 64k pages, the page cache can cache the superblock > > + * and the root inode (and hence the root directory) with the same 64k > > + * page. If udev spawns blkid after the mkfs and the system is busy > > + * enough that it is still running when xfs_db starts up, they'll both > > + * read from the same page in the pagecache. > > + * > > + * The unmount writes updated inode metadata to disk directly. The XFS > > + * buffer cache does not use the bdev pagecache, nor does it invalidate > > + * the pagecache on umount. If the above scenario occurs, the pagecache > > + * no longer reflects what's on disk, xfs_db reads the stale metadata, > > + * and fails to find /a. Most of the time this succeeds because closing > > + * a bdev invalidates the page cache, but when processes race, everyone > > + * loses. > > + */ > > if (mp->m_logdev_targp && mp->m_logdev_targp != mp->m_ddev_targp) { > > blkdev_issue_flush(mp->m_logdev_targp->bt_bdev); > > invalidate_bdev(mp->m_logdev_targp->bt_bdev); > > While I have no complaints with this as a commit message, it's just too > verbose for an inline comment, IMO. Something pithier and more generic > would seem appropriate. How about: > > /* > * Prevent userspace (eg blkid or xfs_db) from seeing stale data. > * XFS is not coherent with the bdev's page cache. "XFS' buffer cache is not coherent with the bdev's page cache." ? --D > */