[PATCH v2 0/2] afs: avoid unhash/rehash

cifs (like nfs and afs) needs to block "open" requests while
processing an unlink or rename because if the target is to be unlinked
on the server, then the open must fail or create a new file, which needs
to wait for the unlink to complete.

It does this by unhashing the dentry and later rehashing it.  This will
cause problems for proposed changes to locking which will lock the
dentry rather than the parent directory.  Unhashing will effectively
unlock the name.

The second patch here addresses this by using ->d_fsdata to mark a
dentry as being busy in unlink/rename and waiting in d_revalidate for
that mark to be removed.  This is the same approach that NFS has used
for a while.

Note that I think there are still possible races which I haven't tried
to fix.  Because cifs_open() constructs a full path name to send to the
server, it could construct and use that name *after* the rename has
happened on the server, but *before* d_move() has recorded the new name
in the dcache.  Then it would try to open a name that no longer exists.
I think that could be fixed by locking the file inode in cifs_open()
before calling build_path_from_dentry(), and holding the lock until the
last usage of full_path.  This would ensure no unlink or rename were
happening at the same time.

The first patch frees up ->d_fsdata which is currently otherwise used.
It is being used for a purpose that ->d_time is more suitable for, so
the first patch switches to use d_time.

10 years ago cifs *did* use ->d_time but was changed to use ->d_fsdata
by Miklos with no justification (a00be0e31f8d).  Miklos: do you have any
memory of why that was done?

Thanks,
NeilBrown

 [PATCH v2 1/2] smb/client: use d_time to store a timestamp in dentry,
 [PATCH v2 2/2] smb/client: don't unhashed and rehash to prevent new