On Wed, 2011-09-21 at 11:58 -0400, Jeff Layton wrote:
> We had a regression reported against RHEL concerning the opening of
> directories and it looks like that same problem is in current mainline
> code too. If you do the following on a directory that is not yet in the
> dcache you get an EISDIR error:
>
> open("/mnt/nfs/dir1", O_RDONLY) = -1 EISDIR (Is a directory)
>
> If however, you stat the directory first, the open works. The
> difference seems to be that in the first case we're going through the
> lookup codepath, and in the second we go through d_revalidate.
>
> In the first case, we send an OPEN call to the server and it responds
> with NFS4ERR_ISDIR. That gets translated to -EISDIR, and returned to
> userspace. It wasn't always this way though, and I think the regression
> was introduced in commit d953126a2.
>
> That patch was added to fix an oops due to a buggy server, and I'm
> unclear on how best to fix this. It seems like we need to allow the
> server to fall back to doing a normal lookup when we get -EISDIR on the
> OPEN call, but how do we ensure that we don't end up with the same oops
> from that server bug?
How about returning an error if we get to the file->f_ops->open on a
regular file in NFSv4?
In NFSv4.1 we could theoretically issue an OPEN will CLAIM_FH (assuming
there are servers out there that support it), but for NFSv4 as far as I
can see, there will always be a potential for races.
Cheers
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
