What is NFSv4 READDIR doesn't return a filehandle....

[NeilBrown <neilb@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 1489 bytes --]


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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]