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

[Chuck Lever <chuck.lever@oracle.com>]

On 02/05/2010 04:20 PM, Jeff Layton wrote:
> 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?

Yes.  If IPv6 support is disabled, then any usage of "tcp6" or "udp6" 
with mount.nfs should cause an error.

If not, how do we resolve the case where mount.nfs uses IPv6 but the 
rest of nfs-utils doesn't have IPv6 support enabled?

> (/me struggles not to get lost in the twisty maze of options)

-- 
chuck[dot]lever[at]oracle[dot]com