On Fri, 2012-04-20 at 20:51 +0000, Adamson, Dros wrote:
> On Apr 20, 2012, at 4:13 PM, Myklebust, Trond wrote:
>
> > On Fri, 2012-04-20 at 19:57 +0000, Adamson, Dros wrote:
> >> On Apr 20, 2012, at 3:45 PM, Jim Rees wrote:
> >>
> >>> Weston Andros Adamson wrote:
> >>>
> >>> nfs4_path() was parsing the path component by splitting on the first colon.
> >>> This is wrong when an IPv6 address is used to mount a server.
> >>>
> >>> For example, having mounted 'fc00::10:/export', nfs4_path() returned
> >>> ':10:/export'. This causes referrals (using IPv4 or IPv6 addresses) to fail
> >>> in nfs4_validate_fspath().
> >>>
> >>> Parsing the path component by using the *last* colon works with
> >>> IPv6 as well as IPv4 addrs.
> >>>
> >>> What if your mount is:
> >>>
> >>> server.edu:/export/:I-like-colons:
> >>>
> >>> It seems to me something has to give. Either we require v6 addresses be
> >>> enclosed in [], export dirs start with "/", or exports have no ":".
> >>
> >>
> >> Yeah, you're right.
> >>
> >> Although IPv6 addrs must be enclosed in [] to work with mount, it's always displayed in the kernel without the [].
> >>
> >> I suppose the correct fix is to always display IPv6 addresses enclosed in [], which might touch a *lot* of places.
> >>
> >> Thoughts? I'll wait for others to chime in before I go fixing this. I have a set of nfsd and mountd patches that deal with similar issues on the server side. I'll clean those up and submit them before getting back to this.
> >
> > We do know which part is the hostname, and which is the pathname. If you
> > look at "try_location()", you'll see that the hostname is stored in
> > location->servers, and is then copied into this empty buffer.
> >
> > If you want to test if that is an IPv6 address so that you can enclose
> > it in [], then that should be fairly easy to do right there…
>
> Right, we have separate hostname and pathname for each fs_location4, but I'm talking about the return value of nfs_path() which is used to determine the server-side path on an arbitrary dentry on the *current* mountpoint (not the referral server).
> The path part of nfs_path() is then compared against the fs_path of the nfs4_fs_locations struct (this is all in nfs4_validate_fspath).
>
> Having nfs_path return [] wrapped IPv6 addresses basically means changing the devname to that format (d_fsdata is used by nfs_path()). I'm concerned about changing the format of devname - its used all over the place.
>
> So the options are:
> 1) change the format of devname
> 2) change how nfs4_validate_fspath gets the server-side path component of the current mount (don't use nfs_path())
>
> I'll try option 1 and see what breaks.
That really should not be necessary.
If you are using an IPv6 address, you are supposed to mount using the []
format. If not, then expect things to break.
The real bug here is in nfs4_path: it tries to parse the ':' that are
part of the IPv6 address even if we use the square bracket delimiters.
Instead, we should be following the example of nfs_parse_devname.
I suggest breaking out the first half of nfs_parse_devname into a
function that returns the host name part of a mount path, and that can
be called by nfs4_path too.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
