public inbox for linux-nfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@redhat.com>
To: Trond Myklebust <trondmy@hammerspace.com>,
	Anna Schumaker <schumakeranna@gmail.com>
Cc: daire@dneg.com, linux-nfs@vger.kernel.org,
	"J. Bruce Fields" <bfields@redhat.com>
Subject: [PATCH 7/8] lockd: don't attempt blocking locks on nfs reexports
Date: Mon, 16 Aug 2021 09:59:26 -0400	[thread overview]
Message-ID: <1629122367-18541-8-git-send-email-bfields@redhat.com> (raw)
In-Reply-To: <1629122367-18541-1-git-send-email-bfields@redhat.com>

From: "J. Bruce Fields" <bfields@redhat.com>

As in the v4 case, it doesn't work well to block waiting for a lock on
an nfs filesystem.

As in the v4 case, that means we're depending on the client to poll.
It's probably incorrect to depend on that, but I *think* clients do poll
in practice.  In any case, it's an improvement over hanging the lockd
thread indefinitely as we currently are.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
---
 fs/lockd/svclock.c | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/fs/lockd/svclock.c b/fs/lockd/svclock.c
index d60e6eea2d57..c99acefb9ec9 100644
--- a/fs/lockd/svclock.c
+++ b/fs/lockd/svclock.c
@@ -31,6 +31,7 @@
 #include <linux/lockd/nlm.h>
 #include <linux/lockd/lockd.h>
 #include <linux/kthread.h>
+#include <linux/exportfs.h>
 
 #define NLMDBG_FACILITY		NLMDBG_SVCLOCK
 
@@ -470,18 +471,24 @@ nlmsvc_lock(struct svc_rqst *rqstp, struct nlm_file *file,
 	    struct nlm_cookie *cookie, int reclaim)
 {
 	struct nlm_block	*block = NULL;
+	struct inode		*inode = nlmsvc_file_inode(file);
 	int			error;
 	int			mode;
+	int			async_block = 0;
 	__be32			ret;
 
 	dprintk("lockd: nlmsvc_lock(%s/%ld, ty=%d, pi=%d, %Ld-%Ld, bl=%d)\n",
-				nlmsvc_file_inode(file)->i_sb->s_id,
-				nlmsvc_file_inode(file)->i_ino,
+				inode->i_sb->s_id, inode->i_ino,
 				lock->fl.fl_type, lock->fl.fl_pid,
 				(long long)lock->fl.fl_start,
 				(long long)lock->fl.fl_end,
 				wait);
 
+	if (inode->i_sb->s_export_op->flags & EXPORT_OP_SYNC_LOCKS) {
+		async_block = wait;
+		wait = 0;
+	}
+
 	/* Lock file against concurrent access */
 	mutex_lock(&file->f_mutex);
 	/* Get existing block (in case client is busy-waiting)
@@ -542,7 +549,7 @@ nlmsvc_lock(struct svc_rqst *rqstp, struct nlm_file *file,
 			 */
 			if (wait)
 				break;
-			ret = nlm_lck_denied;
+			ret = async_block ? nlm_lck_blocked : nlm_lck_denied;
 			goto out;
 		case FILE_LOCK_DEFERRED:
 			if (wait)
-- 
2.31.1


  parent reply	other threads:[~2021-08-16 14:00 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-16 13:59 [PATCH 0/8] reexport lock fixes v2 J. Bruce Fields
2021-08-16 13:59 ` [PATCH 1/8] lockd: lockd server-side shouldn't set fl_ops J. Bruce Fields
2021-08-16 13:59 ` [PATCH 2/8] nlm: minor nlm_lookup_file argument change J. Bruce Fields
2021-08-16 13:59 ` [PATCH 3/8] nlm: minor refactoring J. Bruce Fields
2021-08-16 13:59 ` [PATCH 4/8] lockd: update nlm_lookup_file reexport comment J. Bruce Fields
2021-08-16 13:59 ` [PATCH 5/8] Keep read and write fds with each nlm_file J. Bruce Fields
2021-08-16 17:52   ` kernel test robot
2021-08-16 17:56   ` kernel test robot
2021-08-16 13:59 ` [PATCH 6/8] nfs: don't atempt blocking locks on nfs reexports J. Bruce Fields
2021-08-16 13:59 ` J. Bruce Fields [this message]
2021-08-16 19:28   ` [PATCH 7/8] lockd: don't attempt " kernel test robot
2021-08-16 13:59 ` [PATCH 8/8] nfs: don't allow reexport reclaims J. Bruce Fields
  -- strict thread matches above, loose matches on Subject: below --
2021-08-20 21:01 [PATCH 0/8] reexport lock fixes v3 J. Bruce Fields
2021-08-20 21:02 ` [PATCH 7/8] lockd: don't attempt blocking locks on nfs reexports J. Bruce Fields

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=1629122367-18541-8-git-send-email-bfields@redhat.com \
    --to=bfields@redhat.com \
    --cc=daire@dneg.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=schumakeranna@gmail.com \
    --cc=trondmy@hammerspace.com \
    /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