ecryptfs: saner API for lock_parent()
authorAl Viro <viro@zeniv.linux.org.uk>
Fri, 29 Jan 2021 22:35:43 +0000 (17:35 -0500)
committerAl Viro <viro@zeniv.linux.org.uk>
Sat, 20 Mar 2021 21:46:37 +0000 (17:46 -0400)
commitb2648d512eb2a8188cf3cf5ac75c129be2d33121
treea59b48087a6c9e4f57fd06d5086bb0af11474657
parent4313e3523373f6b313d4218b51418f53475bcce5
ecryptfs: saner API for lock_parent()

Switch all users of lock_parent() to the approach used by ->unlink()
and ->rmdir() - instead of playing with dget_parent() of underlying
dentry of child,
* start with ecryptfs dentry of child.
* find underlying dentries for that dentry and its parent
(which is stable, since the parent directory in upper layer is
held at least shared).  No need to pin them, they are already pinned
by ecryptfs dentries.
* lock the inode of undelying directory of parent
* check if it's the parent of underlying dentry of child.
->d_parent of underlying dentry of child might be unstable.  However,
result of its comparison with underlying dentry of parent *is* stable now.

Turn that into replacement of lock_parent(), convert the existing callers
of lock_parent() to that, along with ecryptfs_unlink() and ecryptfs_rmdir().

Callers need only the underlying dentry of child and inode of underlying
dentry of parent, so lock_parent() passes those to the caller now.
Note that underlying directory is locked in any case, success or failure.

That approach does not need a primitive for unlocking - we hadn't grabbed
any dentry references, so all we need is to unlock the underlying directory
inode.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
fs/ecryptfs/inode.c