From: "Aurélien Charbon" <aurelien.charbon@ext.bull.net>
To: chuck.lever@oracle.com
Cc: Mailing list NFSv4 <nfsv4@linux-nfs.org>,
netdev ML <netdev@vger.kernel.org>, Neil Brown <neilb@suse.de>
Subject: Re: [PATCH 1/1] NFS: change the ip_map cache code to handle IPv6 addresses
Date: Thu, 09 Aug 2007 17:08:49 +0200 [thread overview]
Message-ID: <46BB2E01.2010406@ext.bull.net> (raw)
In-Reply-To: <46BB05B6.5080301@oracle.com>
Thanks for these comments.
Chuck Lever wrote:
> Some naive questions:
>
> 1. If IPv6 support is not configured into the kernel, how does an
> IPv6-only cache work?
Yes it should work.
The INET6 structures are only used as containers for both type of address.
I have tested by unabling IPv6 options in the .config file.
>
> 2. I seem to recall (only quite vaguely) that at some point the
> server might need to use one of the stored addresses to, say, open a
> socket to the client? In that case, on a system with NICs configured
> only with IPv4, is the cached IPv6 address properly converted back to
> IPv4 somehow?
Yes. we can do that by testing the format of the address, as we know
that an IPv4 address is mapped like that:
[00000000] [00000000] [0000FFFF] <32 bits of IPv4 addr>
> Can the cache code tell the difference between a cached IPv6 address
> that was converted from IPv4 and one that was added to the cache as
> IPv6? Sorry I can't remember more clearly.
Yes. If the address starts with ::FFFF, we can infer that is a mapped
IPv4 address.
>
> 3. Would it be better to make the m_addr field a struct sockaddr,
> store a whole address (with address family), and switch on the
> sa_family field?
That is possible but we're able to retrieve the family of the address by
testing its format (IPv4 mapped or not).
But I don't know if it is a better solution.
>
>
>> diff -u -r -N linux-2.6.23-rc1/fs/nfsd/export.c
>> linux-2.6.23-rc1-IPv6-ip_map/fs/nfsd/export.c
>> --- linux-2.6.23-rc1/fs/nfsd/export.c 2007-08-08
>> 17:52:58.000000000 +0200
>> +++ linux-2.6.23-rc1-IPv6-ip_map/fs/nfsd/export.c 2007-08-08
>> 17:49:09.000000000 +0200
>> @@ -1558,6 +1558,7 @@
>> {
>> struct auth_domain *dom;
>> int i, err;
>> + struct in6_addr addr6;
>>
>> /* First, consistency check. */
>> err = -EINVAL;
>> @@ -1576,9 +1577,14 @@
>> goto out_unlock;
>>
>> /* Insert client into hashtable. */
>> - for (i = 0; i < ncp->cl_naddr; i++)
>> - auth_unix_add_addr(ncp->cl_addrlist[i], dom);
>> -
>> + for (i = 0; i < ncp->cl_naddr; i++) {
>> + /* Mapping address */
>> + addr6.s6_addr32[0] = 0;
>> + addr6.s6_addr32[1] = 0;
>> + addr6.s6_addr32[2] = htonl(0xffff);
>> + addr6.s6_addr32[3] = (uint32_t)ncp->cl_addrlist[i].s_addr;
>> + auth_unix_add_addr(addr6, dom);
>> + }
>> auth_unix_forget_old(dom);
>> auth_domain_put(dom);
>
>
> This converts IPv4 addresses to canonical IPv6 as it stores them.
> What happens if a full-blown IPv6 address is encountered? Likewise,
> in nfsctl.c?
I have done this kind of convertion only for compilation an testing with
only IPv4... For the moment.
>
>> @@ -112,12 +112,16 @@
>> return (hash ^ (hash>>8)) & 0xff;
>> }
>> #endif
>> +static inline int hash_ip6(struct in6_addr ip)
>> +{
>> + return (hash_ip(ip.s6_addr32[0]) ^ hash_ip(ip.s6_addr32[1])
>> ^ hash_ip(ip.s6_addr32[2]) ^ hash_ip(ip.s6_addr32[3])) ;
>> +}
>
>
> How have you tested the effectiveness of the new hash function?
I have not tested that point but I can easily imagine there are better
solutions.
Perhaps we can keep the same function for an IPv4 address (only taking
the 32 bits of IPv4 addr), and then design one for IPv6 addresses.
Do you have any suggestion on that ?
>> - seq_printf(m, "%s %d.%d.%d.%d %s\n",
>> + seq_printf(m, "%s %04x.%04x.%04x.%04x.%04x.%04x.%04x.%04x %s\n",
>> im->m_class,
>> - ntohl(addr.s_addr) >> 24 & 0xff,
>> - ntohl(addr.s_addr) >> 16 & 0xff,
>> - ntohl(addr.s_addr) >> 8 & 0xff,
>> - ntohl(addr.s_addr) >> 0 & 0xff,
>> + ntohl(addr.s6_addr32[3]) >> 16 & 0xffff,
>> + ntohl(addr.s6_addr32[3]) & 0xffff,
>> + ntohl(addr.s6_addr32[2]) >> 16 & 0xffff,
>> + ntohl(addr.s6_addr32[2]) & 0xffff,
>> + ntohl(addr.s6_addr32[1]) >> 16 & 0xffff,
>> + ntohl(addr.s6_addr32[1]) & 0xffff,
>> + ntohl(addr.s6_addr32[0]) >> 16 & 0xffff,
>> + ntohl(addr.s6_addr32[0]) & 0xffff,
>> dom
>> );
>> return 0;
>
>
> And I think here NIP6_FMT should be used, but you're not using colons
> between the hex digits. Was that intentional
> ?
No that's a mistake. Colons have to be used here.
Aurélien
--
********************************
Aurelien Charbon
Linux NFSv4 team
Bull SAS
Echirolles - France
http://nfsv4.bullopensource.org/
********************************
next prev parent reply other threads:[~2007-08-09 15:07 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-09 7:22 [PATCH 1/1] NFS: change the ip_map cache code to handle IPv6 addresses Aurélien Charbon
2007-08-09 12:16 ` Chuck Lever
2007-08-09 15:08 ` Aurélien Charbon [this message]
2007-08-09 15:14 ` Chuck Lever
2007-08-10 1:11 ` Neil Brown
2007-08-10 1:06 ` Neil Brown
-- strict thread matches above, loose matches on Subject: below --
2007-08-23 13:18 Aurélien Charbon
2007-08-23 15:32 ` Brian Haley
2007-09-06 11:30 ` Aurélien Charbon
2007-09-06 16:16 ` Brian Haley
2007-08-23 15:39 ` Chuck Lever
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46BB2E01.2010406@ext.bull.net \
--to=aurelien.charbon@ext.bull.net \
--cc=chuck.lever@oracle.com \
--cc=neilb@suse.de \
--cc=netdev@vger.kernel.org \
--cc=nfsv4@linux-nfs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.