ESTALE after cwd deleted by same NFS client

[Colin Percival]

On 12/16/16 12:14, Colin Percival wrote:
> making this change in nfs_lookup
>> --- sys/fs/nfsclient/nfs_clvnops.c      (revision 310132)
>> +++ sys/fs/nfsclient/nfs_clvnops.c      (working copy)
>> @@ -1144,7 +1144,7 @@
>>                         *vpp = NULLVP;
>>                 }
>>  
>> -               if (error != ENOENT) {
>> +               if (error != ENOENT && error != ESTALE) {
>>                         if (NFS_ISV4(dvp))
>>                                 error = nfscl_maperr(td, error, (uid_t)0,
>>                                     (gid_t)0);
> 
> fixes the case I described above (for some definition of "fixes" -- I'm not
> sure if this is the correct way of handling ESTALE here?) but I'm still seeing
> ESTALEs from buildworld's cleandir so I think there must be some other place
> where something odd is happening.

Further information: In addition to the "lookup relative to a directory which
has been deleted out from underneath us" case which causes ESTALE to land in
nfs_lookup, the cleandir step of buildworld results in ESTALE being returned
by nfsrpc_getattr into nfs_getattr (landing ultimately in getcwd), and ESTALE
being returned by nfsrpc_accessrpc into nfs34_access_otw (landing ultimately
in stat and lstat).

In UFS there are checks for effnlink == 0 which result in e.g. ufs_lookup
returning ENOENT; would it make sense to add NREMOVED to struct nfsnode.n_flag
and check this in the appropriate nfs_* calls?

-- 
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid