On Jun 10, 2008, at 3:17 PM, J. Bruce Fields wrote:
On Tue, Jun 10, 2008 at 11:34:14AM -0400, Chuck Lever wrote:
On Jun 9, 2008, at 5:22 PM, J. Bruce Fields wrote:
On Mon, Jun 09, 2008 at 05:08:16PM -0400, Trond Myklebust wrote:
What if it is an IPv6 address? As I've said before, could we please
just
adapt nfs_parse_server_address to deal with all these cases?
I haven't had the time to do that, so I thought we'd rather have a
fix
for the immediate bug now, then add ipv6 support later. For all I
know
the final patches might end up factoring reasonable cleanly that way
anyway.
I have a patch (upcoming for 2.6.27) that fixes
nfs_parse_server_address
to be careful about '\0'-termination. It changes the function to
take a
char * and a length. All you will need to do is make it non-static.
OK, good. That patch and my patch will apply together in either
order;
mine ditches the unnecessary valid_ipadd4() and relies on in4_pton()
instead. Yours makes nfs_parse_server_address more-or-less a drop-in
replacement for in4_pton there. And it should be easy to switch it
over
either in whichever patch comes second or in a small third patch.
So, I was right, this is the natural way to factor out the change
anyway.
The one remaining thing missing for that to work, I think, is to fix
the
struct sockaddr *addr;
field in nfs_clone_mount?
"struct sockaddr *" is what we want. Only the current logic in
nfs_follow_referral() is AF_INET-specific.
--
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
