From: "J. Bruce Fields" <bfields@fieldses.org>
To: NeilBrown <neilb@suse.com>
Cc: Steve Dickson <SteveD@redhat.com>,
Linux NFS Mailing list <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH 7/7] mountd: fail nfsd.export lookup for path to unmounted exportpoint
Date: Fri, 29 Jul 2016 15:04:36 -0400 [thread overview]
Message-ID: <20160729190436.GB7964@fieldses.org> (raw)
In-Reply-To: <146976861683.20186.1810009593325251793.stgit@noble>
On Fri, Jul 29, 2016 at 03:03:36PM +1000, NeilBrown wrote:
> If an export point should be mounted ("mountpoint" option set) but
> isn't, then an attempt to mount using the MOUNT protocol for NFSv3
> will fail and an attempt to access the filesystem using a pre-existing
> filehandle will block because nfsd_fh wont tell the kernel about it.
>
> However a lookup from the parent, as happens with an NFSv4 mount
> request, will pass the name to nfsd_export(), and it doesn't check the
> mointpoint option, and so exports the underlying (typically "/")
> filesystem.
>
> So change nfsd_export() to refused to export that exportpoint, but
> instead to explictly say that it isn't exported.
> This will cause an 'ls' in the parent pseudo-root directory to not show
> the name and will cause a "mount" attempt which walks down through the
> pseudo root to fail in the same way that it does with NFSv3.
>
> An access from a pre-existing NFSv4 mount will still hang until the
> filesystem is mounted, just like it does with NFSv3.
>
> In order to be a bit more responsive to the filesystem getting mounted,
> just a short timeout (1 minutes) on exports of missing "mountpoint"
> exportpoints.
OK, I'm still haven't learned to love "mountpoint", but, I agree, it
looks like this fixes the complaint about the v4 case with minimal risk
of disruption to existing users.
ACK.--b.
>
> Signed-off-by: NeilBrown <neilb@suse.com>
> ---
> utils/mountd/cache.c | 18 +++++++++++++++++-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/utils/mountd/cache.c b/utils/mountd/cache.c
> index 9cc270690d90..ca6c84f4d93d 100644
> --- a/utils/mountd/cache.c
> +++ b/utils/mountd/cache.c
> @@ -1334,7 +1334,23 @@ static void nfsd_export(int f)
> found = lookup_export(dom, path, ai);
>
> if (found) {
> - if (dump_to_cache(f, buf, sizeof(buf), dom, path, &found->m_export, 0) < 0) {
> + char *mp = found->m_export.e_mountpoint;
> +
> + if (mp && !*mp)
> + mp = found->m_export.e_path;
> + if (mp && !is_mountpoint(mp))
> + /* Exportpoint is not mounted, so tell kernel it is
> + * not available.
> + * This will cause it not to appear in the V4 Pseudo-root
> + * and so a "mount" of this path will fail, just like with
> + * V3.
> + * And filehandle for this mountpoint from an earlier
> + * mount will block in nfsd.fh lookup.
> + */
> + dump_to_cache(f, buf, sizeof(buf), dom, path,
> + NULL, 60);
> + else if (dump_to_cache(f, buf, sizeof(buf), dom, path,
> + &found->m_export, 0) < 0) {
> xlog(L_WARNING,
> "Cannot export %s, possibly unsupported filesystem"
> " or fsid= required", path);
>
next prev parent reply other threads:[~2016-07-29 19:04 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-29 5:03 [PATCH 0/7] Assorted mount/mountd nfs-utils patches - V2 NeilBrown
2016-07-29 5:03 ` [PATCH 1/7] nfs.man: clarify effect of 'retry' option NeilBrown
2016-07-29 5:03 ` [PATCH 2/7] mountd: remove the --exports-file option NeilBrown
2016-07-29 5:03 ` [PATCH 7/7] mountd: fail nfsd.export lookup for path to unmounted exportpoint NeilBrown
2016-07-29 19:04 ` J. Bruce Fields [this message]
2016-07-29 5:03 ` [PATCH 3/7] mount: don't treat temporary name resolution failure as permanent NeilBrown
2016-07-29 5:03 ` [PATCH 4/7] mount: use a public address for IPv6 callback NeilBrown
2016-07-29 5:03 ` [PATCH 6/7] mountd: allow alternate ttl to be specified for dump_to_cache NeilBrown
2016-08-03 17:31 ` Steve Dickson
2016-08-03 17:59 ` Steve Dickson
2016-07-29 5:03 ` [PATCH 5/7] mount: fix memory leak in v4root_add_parents NeilBrown
2016-07-29 19:05 ` [PATCH 0/7] Assorted mount/mountd nfs-utils patches - V2 J. Bruce Fields
2016-08-04 11:50 ` Steve Dickson
2016-08-04 12:06 ` NeilBrown
2016-08-04 17:29 ` Steve Dickson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160729190436.GB7964@fieldses.org \
--to=bfields@fieldses.org \
--cc=SteveD@redhat.com \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.