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/