smb/server: add ksmbd_vfs_kern_path()
The function ksmbd_vfs_kern_path_locked() seems to serve two functions
and as a result has an odd interface.
On success it returns with the parent directory locked and with write
access on that filesystem requested, but it may have crossed over a
mount point to return the path, which makes the lock and the write
access irrelevant.
This patches separates the functionality into two functions:
- ksmbd_vfs_kern_path() does not lock the parent, does not request
write access, but does cross mount points
- ksmbd_vfs_kern_path_locked() does not cross mount points but
does lock the parent and request write access.
The parent_path parameter is no longer needed. For the _locked case
the final path is sufficient to drop write access and to unlock the
parent (using path->dentry->d_parent which is safe while the lock is
held).
There were 3 caller of ksmbd_vfs_kern_path_locked().
- smb2_create_link() needs to remove the target if it existed and
needs the lock and the write-access, so it continues to use
ksmbd_vfs_kern_path_locked(). It would not make sense to
cross mount points in this case.
- smb2_open() is the only user that needs to cross mount points
and it has no need for the lock or write access, so it now uses
ksmbd_vfs_kern_path()
- smb2_creat() does not need to cross mountpoints as it is accessing
a file that it has just created on *this* filesystem. But also it
does not need the lock or write access because by the time
ksmbd_vfs_kern_path_locked() was called it has already created the
file. So it could use either interface. It is simplest to use
ksmbd_vfs_kern_path().
ksmbd_vfs_kern_path_unlock() is still needed after
ksmbd_vfs_kern_path_locked() but it doesn't require the parent_path any
more. After a successful call to ksmbd_vfs_kern_path(), only path_put()
is needed to release the path.
Signed-off-by: NeilBrown <neil@brown.name>
Acked-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Steve French <stfrench@microsoft.com>