Re: [RFC PATCH 1/5] sunrpc: don't wait for write before allowing reads from use-gss-proxy file

[NeilBrown <neilb@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 3044 bytes --]

On Sun, 5 Jan 2014 17:54:21 -0500 "J. Bruce Fields" <bfields@fieldses.org>
wrote:

> On Mon, Jan 06, 2014 at 09:37:44AM +1100, NeilBrown wrote:
> > On Thu, 2 Jan 2014 16:21:50 -0500 "J. Bruce Fields" <bfields@fieldses.org>
> > wrote:
> > 
> > > On Wed, Jan 01, 2014 at 07:28:30AM -0500, Jeff Layton wrote:
> > > > It doesn't make much sense to make reads from this procfile hang. As
> > > > far as I can tell, only gssproxy itself will open this file and it
> > > > never reads from it. Change it to just give the present setting of
> > > > sn->use_gss_proxy without waiting for anything.
> > > 
> > > I think my *only* reason for doing this was to give a simple way to wait
> > > for gss-proxy to start (just wait for a read to return).
> > > 
> > > As long as gss-proxy has some way to say "I'm up and running", and as
> > > long as that comes after writing to use-gss-proxy, we're fine.
> > > 
> > 
> > 
> > Only tangentially related to the above email .....
> > 
> > I had a look at this new-fangled gssproxy thing and while it mostly seems
> > like a good idea, I find the hard-coding of "/var/run/gssproxy.sock" in the
> > kernel source .... disturbing.
> > You never know when some user-space might want to change that - maybe to
> > "/run/gssproxy.sock" (unlikely I know - but possible).
> > 
> > Probably the easiest would be to hand the path to the kernel.
> > 
> > e.g. instead  of writing '1' to "use-gss-proxy", we could 
> >   echo /my/path/gss-proxy-sock > /proc/net/rpc/use-gss-proxy
> > 
> > Then you could even use an 'abstract' socket name if you wanted. i.e. one
> > starting with a nul and which doesn't exist anywhere in the filesystem.
> > I would feel a lot more comfortable with that than with the current
> > hard-coding.
> 
> See also RPCBIND_SOCK_PATHNAME.  (I *think* that's completely hardcoded,
> not just a default.)

Arrgghhh!! (Hi Chuck.  Yes, I agree it is "undesirable in the long term").

> 
> I get the general principle.  I have a hard time seeing how it would be
> a problem in practice.

One day some distro will decide that it is time to get rid of the legacy
symlink (or bind mount) of /var/run -> /run.  And they will test it out and
everything will work fine.  So they will commit to it.
And then when they release it, their customers will discover that NFS doesn't
work properly with gss (because the distro forgot to test that).

> 
> If we wanted to do as you suggest, I suppose we could even special-case
> the string "1" (at least for a while) to make the change
> backwards-compatible.

I like the idea.

> 
> I'd like to see the same argument made for the rpcbind case.

I hereby make said argument.  Hardcoding path names in the kernel is
Just-Wrong(TM).  Even /sbin/init is configurable.

NeilBrown


> 
> --b.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]