On Fri, Jan 30, 2009 at 04:30:10PM -0500, Chuck Lever wrote: > On Jan 30, 2009, at Jan 30, 2009, 4:18 PM, Trond Myklebust wrote: >> If so, it sounds to me as if >> we _must_ have lockd and the callback server set up IPv6 sockets >> whenever they are available. > > That's what the code does now. The problem is exactly what does > "whenever they are available" mean? > > Are you suggesting we shouldn't ever fall back to AF_INET? (I'm OK with > that answer, but would like a discussion). This means that if I try an > IPv4 mount on a system built with an IPv6 module, but the module is > unloadable, all mounts (even IPv4) fail outright. Apparently a lot of > folks blacklist their IPv6 modules. It sounds reasonable to me for now to take "whenever they are available" to mean "whenever ipv6 can be loaded", and to fall back on ipv4 only in that case. I guess the sort of case that would handle badly would be: do an ipv4 mount - try to find ipv6, fail, start lockd up ipv4-only do an ipv6 mount - no ipv6 support, so mount fails. insmod ipv6 retry the ipv6 mount - oops, too late to make lockd listen on ipv6. Fail this too. But it'd still be an improvement. For the future: > AF_INET6 listeners can receive AF_INET packets too, but don't have to. > My motivation was to use a single listener so we don't have to support > multiple family listeners for each transport protocol in the server-side > code. How hard would that be exactly? > Also, having a separate IPv6-only listener means that someone can > come along and hijack the IPv4 packets on that port. Starting listeners on both as early as possible reduces but doesn't eliminate the chance of that happening. Don't we just have to assume users of low port numbers are well-behaved to some degree? --b. -- 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
