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.
So we can do it either way. Taking lockd as an example:
1. Have nlmclnt_init() map AF_INET mount addresses to AF_INET6 iff
the lockd listener is AF_INET6, so nlm_cmp_addr() is always dealing
with AF_INET6 in this case, or
2. If CONFIG_IPV6 || CONFIG_IPV6_MODULE, unconditionally map AF_INET
addresses in nlmclnt_init and for incoming NLM requests (when lockd
happens to have fallen back to an AF_INET listener)
Personally I think solution 1. will be less confusing operationally
and less invasive code-wise. I suppose IPv6 purists would prefer
keeping the whole stack in AF_INET6, so they would like solution 2.
Eventually we could map incoming addresses on AF_INET listeners in the
RPC server code, but I prefer to wait until all kernel RPC services
have IPv6 support.
Since 2.6.29 has the CONFIG_SUNRPC_REGISTER_V4=N workaround, do we
need to fix 2.6.29, or can this wait until 2.6.30?
--
Chuck Lever
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
