[LWN Logo]

Date:   Thu, 8 Jul 1999 23:40:27 -0400
From:   Michael Kaminsky <kaminsky@lcs.mit.edu>
To:     linux-kernel@vger.rutgers.edu
Subject: NFSv3 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/