kernel/linux.git/fs/smb/server/vfs.h, branch linux-7.0.y

smb/server: use end_removing_noperm for for target of smb2_create_link()

2025-11-14T12:15:56+00:00

Sometimes smb2_create_link() needs to remove the target before creating the link. It uses ksmbd_vfs_kern_locked(), and is the only user of that interface. To match the new naming, that function is changed to ksmbd_vfs_kern_start_removing(), and related functions or flags are also renamed. The lock actually happens in ksmbd_vfs_path_lookup() and that is changed to use start_removing_noperm() - permission to perform lookup in the parent was already checked in vfs_path_parent_lookup(). Signed-off-by: NeilBrown Link: https://patch.msgid.link/20251113002050.676694-8-neilb@ownmail.net Signed-off-by: Christian Brauner

ksmbd_vfs_set_init_posix_acl(): constify path argument

2025-09-16T01:17:09+00:00

Acked-by: Namjae Jeon Reviewed-by: Christian Brauner Signed-off-by: Al Viro

ksmbd_vfs_inherit_posix_acl(): constify path argument

2025-09-16T01:17:09+00:00

Acked-by: Namjae Jeon Reviewed-by: Christian Brauner Signed-off-by: Al Viro

ksmbd_vfs_kern_path_unlock(): constify path argument

2025-09-16T01:17:09+00:00

Acked-by: Namjae Jeon Reviewed-by: Christian Brauner Signed-off-by: Al Viro

smb/server: add ksmbd_vfs_kern_path()

2025-07-24T15:59:18+00:00

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 Acked-by: Namjae Jeon Signed-off-by: Steve French

ksmbd: Remove unused functions

2025-01-16T05:24:51+00:00

ksmbd_rpc_rap() was added in 2021 as part of commit 0626e6641f6b ("cifsd: add server handler for central processing and tranport layers") ksmbd_vfs_posix_lock_wait_timeout() was added in 2021 as part of commit f44158485826 ("cifsd: add file operations") both have remained unused. Remove them. Signed-off-by: Dr. David Alan Gilbert Acked-by: Namjae Jeon Signed-off-by: Steve French

ksmbd: retry iterate_dir in smb2_query_dir

2024-12-10T23:48:06+00:00

Some file systems do not ensure that the single call of iterate_dir reaches the end of the directory. For example, FUSE fetches entries from a daemon using 4KB buffer and stops fetching if entries exceed the buffer. And then an actor of caller, KSMBD, is used to fill the entries from the buffer. Thus, pattern searching on FUSE, files located after the 4KB could not be found and STATUS_NO_SUCH_FILE was returned. Signed-off-by: Hobin Woo Reviewed-by: Sungjong Seo Reviewed-by: Namjae Jeon Tested-by: Yoonho Shin Acked-by: Namjae Jeon Signed-off-by: Steve French

ksmbd: fix missing use of get_write in in smb2_set_ea()

2024-06-12T04:43:09+00:00

Fix an issue where get_write is not used in smb2_set_ea(). Fixes: 6fc0a265e1b9 ("ksmbd: fix potential circular locking issue in smb2_set_ea()") Cc: stable@vger.kernel.org Reported-by: Wang Zhaolong Signed-off-by: Namjae Jeon Signed-off-by: Steve French

ksmbd: fix possible deadlock in smb2_open

2023-11-24T02:50:45+00:00

[ 8743.393379] ====================================================== [ 8743.393385] WARNING: possible circular locking dependency detected [ 8743.393391] 6.4.0-rc1+ #11 Tainted: G OE [ 8743.393397] ------------------------------------------------------ [ 8743.393402] kworker/0:2/12921 is trying to acquire lock: [ 8743.393408] ffff888127a14460 (sb_writers#8){.+.+}-{0:0}, at: ksmbd_vfs_setxattr+0x3d/0xd0 [ksmbd] [ 8743.393510] but task is already holding lock: [ 8743.393515] ffff8880360d97f0 (&type->i_mutex_dir_key#6/1){+.+.}-{3:3}, at: ksmbd_vfs_kern_path_locked+0x181/0x670 [ksmbd] [ 8743.393618] which lock already depends on the new lock. [ 8743.393623] the existing dependency chain (in reverse order) is: [ 8743.393628] -> #1 (&type->i_mutex_dir_key#6/1){+.+.}-{3:3}: [ 8743.393648] down_write_nested+0x9a/0x1b0 [ 8743.393660] filename_create+0x128/0x270 [ 8743.393670] do_mkdirat+0xab/0x1f0 [ 8743.393680] __x64_sys_mkdir+0x47/0x60 [ 8743.393690] do_syscall_64+0x5d/0x90 [ 8743.393701] entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 8743.393711] -> #0 (sb_writers#8){.+.+}-{0:0}: [ 8743.393728] __lock_acquire+0x2201/0x3b80 [ 8743.393737] lock_acquire+0x18f/0x440 [ 8743.393746] mnt_want_write+0x5f/0x240 [ 8743.393755] ksmbd_vfs_setxattr+0x3d/0xd0 [ksmbd] [ 8743.393839] ksmbd_vfs_set_dos_attrib_xattr+0xcc/0x110 [ksmbd] [ 8743.393924] compat_ksmbd_vfs_set_dos_attrib_xattr+0x39/0x50 [ksmbd] [ 8743.394010] smb2_open+0x3432/0x3cc0 [ksmbd] [ 8743.394099] handle_ksmbd_work+0x2c9/0x7b0 [ksmbd] [ 8743.394187] process_one_work+0x65a/0xb30 [ 8743.394198] worker_thread+0x2cf/0x700 [ 8743.394209] kthread+0x1ad/0x1f0 [ 8743.394218] ret_from_fork+0x29/0x50 This patch add mnt_want_write() above parent inode lock and remove nested mnt_want_write calls in smb2_open(). Fixes: 40b268d384a2 ("ksmbd: add mnt_want_write to ksmbd vfs functions") Cc: stable@vger.kernel.org Reported-by: Marios Makassikis Signed-off-by: Namjae Jeon Signed-off-by: Steve French

ksmbd: add support for read compound

2023-08-29T17:30:19+00:00

MacOS sends a compound request including read to the server (e.g. open-read-close). So far, ksmbd has not handled read as a compound request. For compatibility between ksmbd and an OS that supports SMB, This patch provides compound support for read requests. Signed-off-by: Namjae Jeon Signed-off-by: Steve French