linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* What is NFSv4 READDIR doesn't return a filehandle....
@ 2012-09-16 23:05 NeilBrown
  2012-09-17 12:51 ` Myklebust, Trond
  0 siblings, 1 reply; 11+ messages in thread
From: NeilBrown @ 2012-09-16 23:05 UTC (permalink / raw)
  To: linux-nfs

[-- 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 --]

^ permalink raw reply related	[flat|nested] 11+ messages in thread
* Re: What is NFSv4 READDIR doesn't return a filehandle....
@ 2013-03-20 22:40 Christopher T Vogan
  2013-03-20 23:48 ` Myklebust, Trond
                   ` (2 more replies)
  0 siblings, 3 replies; 11+ messages in thread
From: Christopher T Vogan @ 2013-03-20 22:40 UTC (permalink / raw)
  To: linux-nfs

All,

Sorry for this late posting, a coworker was made aware of this thread 
recently and
has these replies to make.  Our server implementation is the one being
complained about in this thread.


Quoted text is from various entries in this forum.


Neil Brown:
===========
> Just a thought: while coping with broken servers would not be a good 
path to
> follow, detecting protocol violations and reporting an error might be...
> should the NFS client treat a missing filehandle and a malformed reply?

The server is allowed to remove an attribute bit from an entry in the 
readdir
reply, this is not "broken" nor is the reply "malformed".  The lack of a 
filehandle in the reply is deterministic.



Trond Myklebust:
================
> > A customer has come across a server which does not return the 
filehandle
> > information (is that allowed?).
> 
> The filehandle attribute is a mandatory attribute according to RFC3530, 
so I believe that the answer is "no".

Mandatory is described in RFS 3530 as that the server must return the 
attribute
on a GETATTR.  (Section 5, page 36).  There is nothing saying that it is
mandatory to return on a READDIR.  Our server will return the filehandle
on a LOOKUP/GETATTR every time.


Trond Myklebust:
================
> My concern is that the client can't objectively judge what constitutes a
> valid filehandle and what does not until it tries to use it in an RPC
> call.

Sure it can.  In the context of this discussion, if the readdir entry
has the filehandle attribute bit off in the reply, there is no filehandle.

I would note in the scenario we sent a trace for, the Linux client had 
a filehandle for the node in question, and "misplaced" it after a 
readdir to the directory containing that node did not return the 
filehandle
for that entry.  So calling the server "broken" is objectively inaccurate.

I would also note that this problem occurred after we upgraded to RHEL 
6.3;
the prior version did not have this issue, and our server did not change 
its
behavior.  My conclusion is that the means to obtain the filehandle was 
either broken by the client adding logic to assume a filehandle and 
obliterate 
the prior value after a readdir reply chose not to return it, or 
previously 
had a code path to lookup the node and obtain the filehandle, and removed 
that code path for some reason.  So again, pointing to server "breakage" 
is objectively inaccurate.

There are many references to "brokenness" or "server bugs" in this 
thread, and I take exception to it from a design and protocol conformance 
point of view.

This condition is easily recoverable, as ANY missing attribute on a 
readdir
is with a lookup/readdir.  Our decision to not return the FH on a readdir 
reply under certain narrow conditions is not one of convenience but of 
limitations of some underlying filesystem types, and if "convenience" is
to be used as an accusative, it can easily be returned to the client's 
refusal to deal with the legal withholding of an attribute on a readdir
reply.


Signed,
Steve Huntington
IBM z/OS NFS


Christopher Vogan
Dept. W98 NFS Development & Test


^ permalink raw reply	[flat|nested] 11+ messages in thread
end of thread, other threads:[~2013-03-21 13:47 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-09-16 23:05 What is NFSv4 READDIR doesn't return a filehandle NeilBrown
2012-09-17 12:51 ` Myklebust, Trond
2012-09-18  2:04   ` NeilBrown
2012-09-21  2:44     ` Myklebust, Trond
2012-09-24  0:41       ` Jeff Layton
2012-09-24  1:53         ` Myklebust, Trond
  -- strict thread matches above, loose matches on Subject: below --
2013-03-20 22:40 Christopher T Vogan
2013-03-20 23:48 ` Myklebust, Trond
2013-03-20 23:53 ` Haynes, Tom
2013-03-21  0:33   ` Myklebust, Trond
2013-03-21 13:47 ` J. Bruce Fields

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).