On Feb 12, 2009, at 3:27 PM, Trond Myklebust wrote:
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.
The reason we might care in this case is nlm_cmp_addr() is executed
more frequently than nfs_sockaddr_match_ipaddr().
Mapping the server address in nlmclnt_init() means we translate the
server address once and are done with it. We never have to map
incoming AF_INET addresses in NLM requests, and we don't have the
extra conditionals every time we go through nlm_cmp_addr().
This keeps nlm_cmp_addr() as simple as it can be: it compares only two
AF_INET addresses or two AF_INET6 addresses.
--
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
