Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
From:   "NeilBrown" <neilb@suse.de>
To:     "Al Viro" <viro@zeniv.linux.org.uk>
Cc:     "Christoph Hellwig" <hch@infradead.org>,
        "Josef Bacik" <josef@toxicpanda.com>,
        "J. Bruce Fields" <bfields@fieldses.org>,
        "Chuck Lever" <chuck.lever@oracle.com>, "Chris Mason" <clm@fb.com>,
        "David Sterba" <dsterba@suse.com>, linux-fsdevel@vger.kernel.org,
        linux-nfs@vger.kernel.org, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 01/11] VFS: show correct dev num in mountinfo
In-reply-to: <YQNG+ivSssWNmY9O@zeniv-ca.linux.org.uk>
References: <162742539595.32498.13687924366155737575.stgit@noble.brown>,
 <162742546548.32498.10889023150565429936.stgit@noble.brown>,
 <YQNG+ivSssWNmY9O@zeniv-ca.linux.org.uk>
Date:   Fri, 30 Jul 2021 15:28:20 +1000
Message-id: <162762290067.21659.4783063641244045179@noble.neil.brown.name>
Precedence: bulk

On Fri, 30 Jul 2021, Al Viro wrote:
> On Wed, Jul 28, 2021 at 08:37:45AM +1000, NeilBrown wrote:
> > /proc/$PID/mountinfo contains a field for the device number of the
> > filesystem at each mount.
> > 
> > This is taken from the superblock ->s_dev field, which is correct for
> > every filesystem except btrfs.  A btrfs filesystem can contain multiple
> > subvols which each have a different device number.  If (a directory
> > within) one of these subvols is mounted, the device number reported in
> > mountinfo will be different from the device number reported by stat().
> > 
> > This confuses some libraries and tools such as, historically, findmnt.
> > Current findmnt seems to cope with the strangeness.
> > 
> > So instead of using ->s_dev, call vfs_getattr_nosec() and use the ->dev
> > provided.  As there is no STATX flag to ask for the device number, we
> > pass a request mask for zero, and also ask the filesystem to avoid
> > syncing with any remote service.
> 
> Hard NAK.  You are putting IO (potentially - network IO, with no upper
> limit on the completion time) under namespace_sem.

Why would IO be generated? The inode must already be in cache because it
is mounted, and STATX_DONT_SYNC is passed.  If a filesystem did IO in
those circumstances, it would be broken.

Thanks for the review,
NeilBrown