[PATCH] ksmbd: force "fail immediately" flag on fs with its own ->lock

[PATCH] ksmbd: force "fail immediately" flag on fs with its own ->lock

[Vasily Averin]

Like nfsd and lockd, ksmbd can cause deadlock if the exported
file system does not support asynchronous processing of blocking locks:
if all ksmbd worker threads handles such requests,
they can never finish and the server will not be able to handle
any other incoming requests.

Any filesystem that leaves ->lock NULL will use posix_lock_file(), which
does the right thing. Simplest is just to assume that any filesystem
that defines its own ->lock is not safe to request a blocking lock from.

To work around the problem we need to drop fl->fl_flag FL_SLEEP before
vfs_lock_file() execution, it forces affected functions to avoid blocking.

Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
---
 fs/ksmbd/smb2pdu.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/fs/ksmbd/smb2pdu.c b/fs/ksmbd/smb2pdu.c
index 121f8e8c70ac..f2225491af02 100644
--- a/fs/ksmbd/smb2pdu.c
+++ b/fs/ksmbd/smb2pdu.c
@@ -6634,6 +6634,12 @@ static int smb2_set_flock_flags(struct file_lock *flock, int flags)
 {
 	int cmd = -EINVAL;
 
+	if ((flock->fl_file->f_op->lock) &&
+	    ((flags == SMB2_LOCKFLAG_SHARED) ||
+	     (flags == SMB2_LOCKFLAG_EXCLUSIVE))) {
+		ksmbd_debug(SMB, "force fail immediately request\n");
+		flags |= SMB2_LOCKFLAG_FAIL_IMMEDIATELY;
+	}
 	/* Checking for wrong flag combination during lock request*/
 	switch (flags) {
 	case SMB2_LOCKFLAG_SHARED:
-- 
2.25.1

Re: [PATCH] ksmbd: force "fail immediately" flag on fs with its own ->lock

[Namjae Jeon]

2021-12-17 20:23 GMT+09:00, Vasily Averin <vvs@virtuozzo.com>:
> Like nfsd and lockd, ksmbd can cause deadlock if the exported
> file system does not support asynchronous processing of blocking locks:
> if all ksmbd worker threads handles such requests,
> they can never finish and the server will not be able to handle
> any other incoming requests.
>
> Any filesystem that leaves ->lock NULL will use posix_lock_file(), which
> does the right thing. Simplest is just to assume that any filesystem
> that defines its own ->lock is not safe to request a blocking lock from.
>
> To work around the problem we need to drop fl->fl_flag FL_SLEEP before
> vfs_lock_file() execution, it forces affected functions to avoid blocking.
>
> Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
Acked-by: Namjae Jeon <linkinjeon@kernel.org>

Thanks!
> ---
>  fs/ksmbd/smb2pdu.c | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/fs/ksmbd/smb2pdu.c b/fs/ksmbd/smb2pdu.c
> index 121f8e8c70ac..f2225491af02 100644
> --- a/fs/ksmbd/smb2pdu.c
> +++ b/fs/ksmbd/smb2pdu.c
> @@ -6634,6 +6634,12 @@ static int smb2_set_flock_flags(struct file_lock
> *flock, int flags)
>  {
>  	int cmd = -EINVAL;
>
> +	if ((flock->fl_file->f_op->lock) &&
> +	    ((flags == SMB2_LOCKFLAG_SHARED) ||
> +	     (flags == SMB2_LOCKFLAG_EXCLUSIVE))) {
> +		ksmbd_debug(SMB, "force fail immediately request\n");
> +		flags |= SMB2_LOCKFLAG_FAIL_IMMEDIATELY;
> +	}
>  	/* Checking for wrong flag combination during lock request*/
>  	switch (flags) {
>  	case SMB2_LOCKFLAG_SHARED:
> --
> 2.25.1
>
>