Re: [PROBLEM] [2.6.0-test6] Stale NFS file handle

[Neil Brown]

On Sunday September 28, mau@xxxxxxxxxxxxx wrote:
> 
> I stumbled over the following lines of code in fs/nfsd/nfsfh.c:
> 
> int nfsd_acceptable(void *expv, struct dentry *dentry)
> {
>         struct svc_export *exp = expv;
>         int rv;
>         struct dentry *tdentry;
>         struct dentry *parent;
> 
>         if (exp->ex_flags & NFSEXP_NOSUBTREECHECK)
>                 return 1;
> 
>         tdentry = dget(dentry);
>         while (tdentry != exp->ex_dentry && ! IS_ROOT(tdentry)) {
>                 /* make sure parents give x permission to user */
>                 int err;
>                 parent = dget_parent(tdentry);
>                 err = permission(parent->d_inode, S_IXOTH, NULL);
>                                                   ^^^^^^^ <- !!!!
>                 if (err < 0) {
>                         dput(parent);
>                         break;
>                 }
> 
> First, nfsd_acceptable always returns success if subtree_checks are
> diabled. Second, I think, the line marked above is not correct.
> 
> The comment says "give x permission to user", but the call looks
> suspiciously wrong.

I think it is correct, though arguably it should be "MAY_EXEC" rather
than "S_IXOTH" (both of which are '1').
The permission call checks if the current user (which is computed from
the rpc credentials) has eXecute access to the directories.

> 
> You can also make the error disappear by allowing setting all x bits
> for "other" from your mount-point down to the directory where the error
> appears.

Have you actually tried this or are you just assuming?

> 
> Echoing "32767" to /proc/sys/sunrpx/nfs_debug helped me a great deal
> to find that error.

Presumably you got lots of "nfsd_acceptable failed at ....".  Is that
correct? 

I guess I need to do some testing with "subtree_check" set and see if
I can reproduce it.

NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/