ESTALE after cwd deleted by same NFS client

[Colin Percival]

On 12/19/16 13:59, Rick Macklem wrote:
> Colin Percival wrote:
>> 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?
> To be honest, I can't think of a reason why userland would ever want to see ESTALE?
> The function you see above "nfscl_maperr()" could easily map all ESTALEs to ENOENTs?

I was wondering about that.  I hesitated to suggest it since it seemed like
doing this could mask bugs and/or throw away useful information -- I mean, I
assume there was a reason ESTALE existed in the first place...

> - The question is: "Would returning ENOENT for stat(2) and access(2) actually make the
>    buildworld happy?

I think buildworld would need s/ESTALE/ENOENT/ in access, lstat, rmdir, stat,
and unlink.  But with those I'm 99% confident that buildworld will complete.

> --> The cheat for regular files is "sillyrename". This could be done for directories,
>       but there are multiple comments in the code (not put there by me) that say
>       "no sillyrename for directories".
>      #1 Does this imply something breaks when you do sillyrename for dirs?

Yes.  You'd run into this scenario:

$ mkdir /nfs/foo
$ cd /nfs/foo
$ rmdir /nfs/foo	# still in use, sillyrename happens
$ touch bar		# creates /nfs/foo.sillyname/bar
$ cd /			# directory no longer in use, time to delete it...

Whereas keeping track of "this nfsnode refers to a directory which has been
deleted" would allow us to return ENOENT to file-creation attempt, just like
UFS does if you try to create a file inside a removed directory.

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