Chris Pascoe was seeing stale file handles on his NFS clients, and
traced it down to directories on which the client had no execute
permissions.
Long story short, NFS was trying to reconstruct a path up to / by
doing a lookup on ".." in such a directory, and failing - this
returned EBADHANDLE because there was an extra access check
in xfs_lookup if we had to unlock the directory - since perms
on this directory may have changed while it was unlocked.
NFS always expects to be able to lookup ".." and didn't deal
well with this extra check when it failed.
In general, access checks have already happened above this
point, and re-checking shouldn't be necessary.
...and that was the short story...
Date: Thu Apr 18 13:53:35 PDT 2002
Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea
The following file(s) were checked into:
bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs
Modid: 2.4.x-xfs:slinx:116778a
linux/fs/xfs/xfs_vnodeops.c - 1.523
- Remove extra access check in lookup path
|