lkml.org 
[lkml]   [1999]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectNFSv3 support (bugs, some fixes, and more)
Recently, while trying to get NFSv3 support working on Linux, I've
noticed two problems with the NFS code in the kernel and one with the
in-kernel nfsd. I describe each below. Patches plus instructions
for getting NFSv3 working on Linux can be found out a web page I put
together:
http://www.pdos.lcs.mit.edu/~kaminsky/nfs3-linux/
The page is intended to bring together the several necessary patches
in a convenient way with some brief instructions.

Comments? Suggestions?

Michael
---

1. The NFSv3 client seems to assume that remote NFS servers always
include the optional return values. Particularly, if a remote
server does not return object attributes for a LOOKUP RPC, the
Linux kernel proceeds to use uninitialized data. My solution was
to simply check the valid field of the attributes (which the XDR
routines already set) and issue a GETATTR right after the LOOKUP
because so much of the code seems to assume they exist. A more
efficient solution would be to restructure the code at a higher
level to avoid unnecessary RPCs. The same problem also exists for
other optional return values (directory attributes, etc.).

2. The NFS client uses iget to keep track of outstanding inodes which
keys its hash table on superblock and fileid as returned from the
NFS server. This fileid really should be opaque to the kernel,
and the table should be indexed by NFS filehandles which are
guaranteed to be unique. Otherwise, a server can't export a
volume on a subdirectory of itself without confusing the Linux
kernel completely. User-space programs will then make use of the
fileid (inode number) to avoid disasters like copying a file onto
itself.

My quick temporary solution here was to add a new version of iget
that indexed the hash table based on a combination of the
superblock, fileid, and filehandle. In this way, two files with
the same fileid and different filehandles would hash to different
locations. Of course, we could still have hash collisions, so a
better solution is to have iget take as arguments an arbitrary
length FS-defined key (instead of inode) and a hash function for
iget to call on the key.

3. There is also a small marshalling problem in the knfsd code.
nfsd3_fsinfores.f_maxfilesize is __u64 but is marshalled as a
32-bit value.

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

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.072 / U:0.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site