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?
--
chuck[dot]lever[at]oracle[dot]com
--
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
