Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5;
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
From:   "NeilBrown" <neilb@suse.de>
To:     Trond Myklebust <trondmy@hammerspace.com>,
        Steve Dickson <steved@redhat.com>
Cc:     linux-nfs@vger.kernel.org
Subject: help with understanding match_fsid() errors in nfs-utils
Date:   Wed, 27 Sep 2023 12:10:11 +1000
Message-id: <169578061136.5939.6687963921006986794@noble.neil.brown.name>
Precedence: bulk


hi Trond,
 I'm trying to understand

 Commit 76c21e3f70a8 ("mountd: Check the stat() return values in match_fsid()=
")

 in nfs-utils.

 The effect of this patch is that if a 'stat' of any path in
 /etc/exports or any mountpoint below any path marked crossmnt fails
 with an error other than one of a small set, then the fsid to path
 lookup aborts without reporting anything to the kernel, so the kernel
 doesn't reply to the client and the mount attempt blocks indefinitely.

 I have seen this happen when "/" is exported crossmnt, and when a stat
 of /run/user/1000/doc returns EACCES.  This is a "fuse" mount for user
 1000, and presumably it rejects any access from any other user.

 Could you please help me understand what this patch was trying to
 achieve?  What sorts of errors were you expecting this to catch?
 Would it make sense to silently ignore the stat failure for paths that
 were found when scanning the mount table, and only take the more
 drastic action for paths explicitly listed in /etc/exports ??

Thanks,
NeilBrown