Re: [NFS] [PATCH] kNFSD - Allowing rpc.nfsd to setting of the port,transport and version the server will use

[Peter Staubach]

J. Bruce Fields wrote:

> On Fri, Oct 07, 2005 at 12:17:43PM -0400, Steve Dickson wrote:
>  
>
> > Here is a kernel patch that will enable the setting
> > of the port knfsd will listens on, the transport knfsd
> > will support and which NFS version will be advertised.
> >
> > The nfs-utils patch, which is also attached, will added
> > the following flags to rpc.nfsd that will enable the kernel
> > functionality (Note: These patches are NOT dependent on each
> > other. Meaning rpc.nfsd and knfsd will still function correctly
> > if one or the other patch do or do not exist):
> >
> >
> >   -N  or  --no-nfs-version vers
> >        This option can be used to request that rpc.nfsd does not  offer
> >        certain  versions of NFS. The current version of rpc.nfsd can
> >        support both NFS version 2,3 and the newer version 4.
> >    
>
> So the obvious question is what will happen if someone does
>
> 	rpc.nfsd -N 3
>
> on a server supporting 2, 3, and 4.
>
> It looks like the code in svc_create() will set pg_lovers to 2 and
> pg_hivers to 4 in that case.  So if someone tries to use version 3, the
> error they get back will be a somewhat contradictory "sorry, I only
> support versions 2 through 4."
>
> It seems to me that it'd be cleaner if the kernel interface only
> accepted a range (e.g., "2--4" or "2--3").  Then if someone
> attempted the above, they'll get an error back immediately.
>
> Or svc_create could be adjusted to report a more conservative range
> ("2--2" or "4--4" instead of "2--4").
>
> But I don't have really strong feelings about it.  Maybe we shouldn't
> care enough about that case.

Well, you are right, it seems contradictory, but it is the right thing
to do in such a situation.  It follows the RPC semantics as defined.
(I suspect that Bob didn't consider something like this when he was
designing this part of RPC.)

I would suggest that doing this to an NFS server would be pretty silly,
not done very much if at all, and not something to care about.

It also isn't the first time that such a situation has occurred.  SGI
used to have a MOUNT version 99 (or some such value) and responses such
as this could be seen from their server at times.

   Thanx...

      ps
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/