On Thu, 2009-02-12 at 15:11 -0500, Chuck Lever wrote: > On Feb 12, 2009, at 2:43 PM, Trond Myklebust wrote: > > On Thu, 2009-02-12 at 14:35 -0500, Chuck Lever wrote: > >> I wasn't sure exactly where the compared addresses came from. I had > >> assumed that they all came through the listener, so we wouldn't need > >> this kind of translation. It shouldn't be difficult to map addresses > >> passed in via nlmclnt_init() to AF_INET6. > >> > >> But this is the kind of thing that makes "falling back" to an AF_INET > >> listener a little challenging. We will have to record what flavor > >> the > >> listener is and do a translation depending on what listener family > >> was > >> actually created. > > > > Why? Should we care whether we're receiving IPv4 addresses or IPv6 > > v4-mapped addresses? They're the same thing... > > The problem is the listener family is now decided at run-time. If an > AF_INET6 listener can't be created, an AF_INET listener is created > instead, even if CONFIG_IPV6 || CONFIG_IPV6_MODULE is enabled. If an > AF_INET listener is created, we get only IPv4 addresses in svc_rqst- > >rq_addr. You're missing my point. Why should we care if it's one or the other? In the NFSv4 case, we v4map all IPv4 addresses _unconditionally_ if it turns out that CONFIG_IPV6 is enabled. IOW: we always compare IPv6 addresses. 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
