Re: [PATCH] EXPORTFS: Don't return NULL from fh_to_dentry()/fh_to_parent()[ver #4]

From: Linus Torvalds
Date: Fri Dec 05 2008 - 14:03:27 EST

On Fri, 5 Dec 2008, David Howells wrote:
> The d_obtain_alias() function will immediately return -ESTALE if given a NULL
> inode, though, and sometimes it'll return some other error.
> It would also seem odd to sometimes return NULL to indicate an error, and
> sometimes return a -ve error code to indicate an error. Perhaps one or the
> other should be selected for consistency.

Well, the thing is, returning NULL is probably the most natural thing to
do for a filesystem that doesn't really _have_ a valid error code for the
situation. It's more of a "I can't do this" thing, than an error.

Sure, we can make all filesystems return -ESTALE, but not only is the
patch fairly big, it really doesn't look at all better or make any more
sense. ESTALE is really strictly a NFS thing - it doesn't tend to make
sense for other filesystems (well, sure, other filesystems may have inode
versions too and decide to use ESTALE for things, so I'm not claiming that
it's _purely_ a NFS thing, but I think you see my point).

So it really seems to make more sense to just make the ESTALE handling be
a NFS issue.

And notice that I'm not arguing that "fh_to_dentr/parent()" should
_always_ return NULL for errors. There may be real reasons why a
filesystem might want to return some actual error, like EIO. And maybe a
filesystem actually wants to return an explicit ESTALE when that makes
sense (ie when the filesystem _does_ find an inode that matches, but the
generation doesn't match).

But I'm just looking at your patch, and seeing things like

if (fh_len <= 2)
- return NULL;
+ return ERR_PTR(-ESTALE);

and going "That really didn't make the code any prettier or easier to

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at