Re: [PATCH 19/28] xfs_healer: use statmount to find moved filesystems even faster

["Darrick J. Wong" <djwong@kernel.org>]

On Tue, Mar 10, 2026 at 11:56:22AM -0700, Darrick J. Wong wrote:
> On Tue, Mar 10, 2026 at 02:28:43AM -0700, Christoph Hellwig wrote:
> > > 
> > > However, this is really slow if there are a lot of filesystems because
> > > we end up wading through a lot of irrelevant information.  However,
> > > statmount() can help us here because as of Linux 7.0 we can open the
> > > passed-in path at startup, call statmount() on it to retrieve the
> > > mnt_id, and then call it again later with that same mnt_id to find the
> > > mountpoint.  Luckily xfs_healthmon didn't get merged until 7.0 so it's
> > > more or less guaranteed to be there if XFS_IOC_HEALTH_MONITOR succeeds.
> > > 
> > > Obviously if this doesn't work, we can fall back to the slow walk.
> > 
> > Can we kill the fallback and instead just have a good error message
> > if someone messes up their backports?
> 
> Yes we could, though the risk with dropping the previous patch is that
> someone could introduce a third-party seccomp policy that forbids
> statmount() even on kernels that support it, and then xfs_healer would
> just fail if the mount moves.
> 
> That would be totally stupid because the only reason you'd encounter
> that is because either (a) your distro screwed up their security policy
> or (b) your paranoid IT department deploys an Enterprise Security Model
> written by a ven-duh who hasn't gotten around to evaluating the new
> syscalls and blocks anything they've not read about.
> 
> I'd rather keep the getmntent stuff around since that's the classic way
> linux programs (including xfsprogs) have handled scanning the mount
> tables.  But if you feel strongly about not having getmntent it's not
> hard to pull it out.

Actually, ignore all this, I found a much better reason for keeping both
versions:

Each bind mount gets a new mnt_id, so getmntent is the only way to find
a different vfsmount of the same filesystem.  If you do this:

mount /dev/sda /mnt
xfs_healer /mnt &
mount /mnt /opt --bind
umount /mnt

the filesystem itself never gets unmounted, but statmount() won't be
able to find /opt without scanning the mount table.  Observe that the
bind mount gets a different vfsmount object, and hence a different
mnt_id:

# mount /dev/sda /mnt
# xfs_io -c statmount /mnt | grep mnt_id:
        mnt_id: 0x80004775
# mount /mnt /opt --bind
# xfs_io -c statmount /opt | grep mnt_id:
        mnt_id: 0x8000477a

The statmount reconnection thing, however, works for mount --move
because the vfsmount object doesn't go away, it merely moves around:

# mount -t tmpfs urk /mnt
# mount --make-rprivate /mnt
# mkdir -p /mnt/a /mnt/b
# mount /dev/sda /mnt/a
# xfs_io -c statmount /mnt/a | grep mnt_id:
        mnt_id: 0x800048a9
# mount --move /mnt/a /mnt/b
# xfs_io -c statmount /mnt/b | grep mnt_id:
        mnt_id: 0x800048a9

I'm not sure when anyone would really do this, but it's certainly
possible to do this, and every other process in the same mount namespace
will see it.  I'll go write a new test to exercise this, since I forgot
to do that earlier.

--D