From: Jeff Layton <jlayton@redhat.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: steved@redhat.com, linux-nfs@vger.kernel.org
Subject: Re: [PATCH] mount.nfs: set the default family for lookups based on Defaultproto= setting
Date: Fri, 5 Feb 2010 16:20:18 -0500 [thread overview]
Message-ID: <20100205162018.41ea79d8@tlielax.poochiereds.net> (raw)
In-Reply-To: <4B6C7EB4.9090307@oracle.com>
On Fri, 05 Feb 2010 15:25:24 -0500
Chuck Lever <chuck.lever@oracle.com> wrote:
> On 02/05/2010 03:05 PM, Jeff Layton wrote:
> > On Fri, 05 Feb 2010 14:59:30 -0500
> > Chuck Lever<chuck.lever@oracle.com> wrote:
> >
> >> On 02/05/2010 02:55 PM, Jeff Layton wrote:
> >>> On Fri, 5 Feb 2010 13:17:57 -0500
> >>> Jeff Layton<jlayton@redhat.com> wrote:
> >>>
> >>>>>> I can sort of buy the argument for leaving out the earlier #ifdef
> >>>>>> around the default_value() function.
> >>>>>>
> >>>>>> If you change this one though, then lookups will still return IPv6
> >>>>>> addresses by default even when IPV6_SUPPORTED isn't set. IOW, in the
> >>>>>> absence of a proto= option, you'll pass AF_UNSPEC to getaddrinfo and
> >>>>>> get IPv6 addresses. I don't think that's what we want here for a
> >>>>>> non-ipv6 enabled nfs-utils.
> >>>>>
> >>>>> OK, agreed. This setting is actually not determining the meaning of any
> >>>>> of the netids, but rather it is determining the default address family
> >>>>> if _no_ netid is specified.
> >>>>>
> >>>>
> >>>> Correct. Ok, I'll respin and repost with the ifdef's in default_value()
> >>>> removed.
> >>>
> >>> New patch sent. Just for giggles, I tested this by building a
> >>> tirpc-enabled/ipv6-disabled nfs-utils and setting Defaultproto=tcp6. It
> >>> does indeed set the address family to IPv6:
> >>>
> >>> # mount -v opensolaris:/export/public /mnt/test
> >>> mount: no type was given - I'll assume nfs because of the colon
> >>> mount.nfs: timeout set for Fri Feb 5 14:51:01 2010
> >>> mount.nfs: trying text-based options 'vers=4,addr=feed::23,clientaddr=feed::22'
> >>>
> >>> ...and the mount succeeds.
> >>>
> >>> So in that situation and also when proto=tcp6 is specified, someone can
> >>> mount an IPv6-capable server even with a nfs-utils that isn't built for
> >>> IPv6 as long as it has tirpc support.
> >>>
> >>> Is that a good thing? I'm not sure -- statd won't work over IPv6 in
> >>> that case, for instance. Would it be better to have mount.nfs fail to
> >>> use IPv6 addrs at all when not built with IPv6 support?
> >>
> >> If IPv6 support is disabled at build time, mount.nfs shouldn't allow a
> >> mount over IPv6, even if the kernel supports it.
> >>
> >> Is that with, or without, my additional protocol family negotiation patches?
> >>
> >
> > With those patches. I haven't tested this without them.
>
> Ah, I see... you are not talking about by default.
>
> In that case, you probably want nfs_{nfs,mount}_proto_family to return
> FALSE if nfs_get_proto returns AF_INET6 and IPV6_SUPPORTED is not defined.
>
> /me winces
>
> That would be a separate fix from your config file patch.
>
If we do that, then in the hypothetical scenario above (someone
specifies Defaultproto=tcp6 in the config file and has a
tirpc-enabled/ipv6-disabled nfs-utils), then their mounts will always
fail unless they override that setting with a proto= option.
Is that the behavior we want here?
(/me struggles not to get lost in the twisty maze of options)
--
Jeff Layton <jlayton@redhat.com>
next prev parent reply other threads:[~2010-02-05 21:20 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-05 14:27 [PATCH] mount.nfs: set the default family for lookups based on Defaultproto= setting Jeff Layton
2010-02-05 15:31 ` Chuck Lever
2010-02-05 16:30 ` Jeff Layton
[not found] ` <20100205113052.333f0c05-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2010-02-05 17:13 ` Chuck Lever
2010-02-05 17:43 ` Jeff Layton
[not found] ` <20100205124340.6b77902c-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2010-02-05 18:11 ` Chuck Lever
2010-02-05 18:17 ` Jeff Layton
[not found] ` <20100205131757.6fd224d0-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2010-02-05 19:55 ` Jeff Layton
[not found] ` <20100205145530.61634593-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2010-02-05 19:59 ` Chuck Lever
2010-02-05 20:05 ` Jeff Layton
[not found] ` <20100205150511.5e18538f-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2010-02-05 20:25 ` Chuck Lever
2010-02-05 21:20 ` Jeff Layton [this message]
[not found] ` <20100205162018.41ea79d8-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2010-02-05 21:28 ` Chuck Lever
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=20100205162018.41ea79d8@tlielax.poochiereds.net \
--to=jlayton@redhat.com \
--cc=chuck.lever@oracle.com \
--cc=linux-nfs@vger.kernel.org \
--cc=steved@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox