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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]