Re: [PATCH 11/11] lockd: Allow mount option to specify caller_name

[Trond Myklebust <trond.myklebust@fys.uio.no>]

On Thu, 2010-04-01 at 15:45 -0400, Trond Myklebust wrote: 
> On Thu, 2010-04-01 at 15:04 -0400, Chuck Lever wrote: 
> > NLMPROC_LOCK requests have a "caller_name" argument which is supposed
> > to contain the hostname the server uses to call the client back.
> > Linux simply stuffs the system's utsname in this field, but this is
> > not always the correct choice.  For example:
> > 
> >   o  If an unqualified hostname is used for the client's utsname,
> >      it could be ambiguous when the server tries to resolve it
> >   o  If the client's actual hostname is determined by DHCP, it may
> >      not match its utsname
> >   o  If the NFS mount was done in a network namespace, the namespace
> >      name won't match the client's utsname
> >   o  If the client has multiple network interfaces, it should provide
> >      a hostname that matches the source address used to contact the
> >      server
> > 
> > In all of these cases, user space can determine the correct value of
> > the caller_name argument at mount time.
> > 
> > So, add a mount option that allows user space to specify the value of
> > the caller_name argument of NLMPROC_LOCK requests.  If not specified,
> > the kernel continues to use the init utsname, as before.
> 
> This argument makes no sense. Mount points do _not_ follow network
> namespace boundaries, so making this hostname of yours a mount option
> will make matters worse, not better.
> 
> Furthermore, even if we were to accept your argument, you are not
> matching nfs_clients to your "namespace name", so if you do have more
> than 1 mount to the same server but from different namespaces, then the
> namespace name of the first to mount will automatically become the
> default for the second mount too.

Basically, it boils down to: what does all this extra stuff give me that
the current (per-thread) utsname group namespace does not allow?

   Trond