Re: [PATCH] mount.nfs: set the default family for lookups based on Defaultproto= setting

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 05 Feb 2010 15:25:24 -0500
Chuck Lever <chuck.lever@xxxxxxxxxx> wrote:

> On 02/05/2010 03:05 PM, Jeff Layton wrote:
> > On Fri, 05 Feb 2010 14:59:30 -0500
> > Chuck Lever<chuck.lever@xxxxxxxxxx>  wrote:
> >
> >> On 02/05/2010 02:55 PM, Jeff Layton wrote:
> >>> On Fri, 5 Feb 2010 13:17:57 -0500
> >>> Jeff Layton<jlayton@xxxxxxxxxx>   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@xxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux