Re: [PATCH 6/6] nfs: Fix misparsing of nfsv4 fs_locations attribute

["J. Bruce Fields" <bfields@fieldses.org>]

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?

--b.

>
> (I would have mentioned it yesterday but I thought I had dropped the  
> patch from my "for 2.6.27" series).