mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Vasily Averin <vvs@virtuozzo.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Bruce Fields <bfields@redhat.com>,
	Jeff Layton <jlayton@kernel.org>,
	kernel@openvz.org, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org
Subject: [PATCH] fuse: drop obsoleted lockd restriction in fuse_setlk
Date: Fri, 17 Dec 2021 14:59:44 +0300	[thread overview]
Message-ID: <b18d7be1-393a-1fce-685f-9ede560f70d1@virtuozzo.com> (raw)

kernel export threads like nfsd, lockd and ksmbd can deadlock if
exported file system does not support asynchronous processing of
blocking locks.

Some time ago this problem was work arounded in fuse by commit
48e90761b570 ("fuse: lockd support"), however it was not fully
correct because of all locking requests was disables including
non-blocking (i.e. w/o FL_SLEEP in fl_flags) locks.

Now this check is incomplete: nfs v4 does not use lockd and handles
locking request via nfsd directly, recently added ksmbd uses
vfs_lock_file() too. However both these servers does not have
fl->fl_lmops->lm_grant defined.

Original problem was noticed again, and now it will be fixed on the
server side: all affected kernel threads will not use FL_SLEEP if
exported file system does not support asynchronous processing of
blocking locks.

According patches was submitted but not merged yet
[PATCH] nfs: block notification on fs with its own ->lock
[PATCH] ksmbd: force "fail immediately" flag on fs with its own ->lock

Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
---
 fs/fuse/file.c | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/fs/fuse/file.c b/fs/fuse/file.c
index 9d6c5f6361f7..06e0d7fa86f3 100644
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -2509,11 +2509,6 @@ static int fuse_setlk(struct file *file, struct file_lock *fl, int flock)
 	pid_t pid_nr = pid_nr_ns(pid, fm->fc->pid_ns);
 	int err;
 
-	if (fl->fl_lmops && fl->fl_lmops->lm_grant) {
-		/* NLM needs asynchronous locks, which we don't support yet */
-		return -ENOLCK;
-	}
-
 	/* Unlock on close is handled by the flush method */
 	if ((fl->fl_flags & FL_CLOSE_POSIX) == FL_CLOSE_POSIX)
 		return 0;
-- 
2.25.1


                 reply	other threads:[~2021-12-17 11:59 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b18d7be1-393a-1fce-685f-9ede560f70d1@virtuozzo.com \
    --to=vvs@virtuozzo.com \
    --cc=bfields@redhat.com \
    --cc=jlayton@kernel.org \
    --cc=kernel@openvz.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®