On Fri, 2009-01-30 at 16:30 -0500, Chuck Lever wrote: > > Yes and no. I thought the motivation for doing what you currently > do > > was > > to avoid mixing AF_INET and AF_INET6 sockets, since the latter > > listen on > > both IPv4 (via the IPv4 mapping) and IPv6? > > 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. Also, having a separate IPv6-only listener means > that someone can come along and hijack the IPv4 packets on that port. > > It's just less of a headache with one listener. The ipv6 manpage says that the port spaces are shared. If so, I don't see how you can have both an AF_INET socket and an AF_INET6 socket bound to the same port. > > 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. I'd rather advocate that we try to use AF_INET6 at service set up time, then fall back on AF_INET only if the former isn't available. I'm not sure that we should allow the user to change the service once it has been set up, since it would appear that would force you to close the current socket, and then reopen a new one of a different type. That's both racy and constitutes an interruption of service. Cheers Trond -- 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
