In NFSv4, the server can report which attributes it chose to return in a READDIR reply. A customer has come across a server which does not return the filehandle information (is that allowed?). A consequence of this is that Linux/NFS gets confused. nfs_readdir_page_filler calls nfs_prime_dcache() (because it was a readdir plus request that was sent) and nfs_prime_dcache goes ahead and creates an inode based on the filehandle that it has. However decode_attr_filehandle() had happily decoded nothing as the FATTR4_WORD0_FILEHANDLE bit wasn't set. So the inode gets created with a zero-length filehandle and when this gets sent back to the server to act on the inode, it gets NFS4ERR_BADHANDLE to the PUTFH op. So should nfs_prime_dcache() abort if the filehandle doesn't exist (patch below) or should nfs_fhget() return an error if the filehandle is empty? Or maybe this behaviour should be detected and readdir should be disabled for that server? Suggestions? Thanks, NeilBrown diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c index 627f108..148d09c 100644 --- a/fs/nfs/dir.c +++ b/fs/nfs/dir.c @@ -442,6 +442,10 @@ void nfs_prime_dcache(struct dentry *parent, struct nfs_entry *entry) if (filename.len == 2 && filename.name[1] == '.') return; } + if (entry->fh.size == 0) + /* Server didn't return a filehandle */ + return; + filename.hash = full_name_hash(filename.name, filename.len); dentry = d_lookup(parent, &filename);
Attachment:
signature.asc
Description: PGP signature
