public inbox for linux-nfs@vger.kernel.org
 help / color / mirror / Atom feed
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>

  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