All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Aring <aahringo@redhat.com>
To: linux-nfs@vger.kernel.org
Cc: cluster-devel@redhat.com, ocfs2-devel@lists.linux.dev,
	linux-fsdevel@vger.kernel.org, teigland@redhat.com,
	rpeterso@redhat.com, agruenba@redhat.com,
	trond.myklebust@hammerspace.com, anna@kernel.org,
	chuck.lever@oracle.com, jlayton@kernel.org
Subject: [RFCv2 2/7] lockd: FILE_LOCK_DEFERRED only on FL_SLEEP
Date: Mon, 14 Aug 2023 17:11:11 -0400	[thread overview]
Message-ID: <20230814211116.3224759-3-aahringo@redhat.com> (raw)
In-Reply-To: <20230814211116.3224759-1-aahringo@redhat.com>

This patch removes to handle non-blocking lock requests as asynchronous
lock request returning FILE_LOCK_DEFERRED. When fl_lmops and lm_grant()
is set and a non-blocking lock request returns FILE_LOCK_DEFERRED will
end in an WARNING to signal the user the misusage of the API.

The reason why we moving to make non-blocking lock request as
synchronized call is that we already doing this behaviour for unlock or
cancellation as well. Those are POSIX lock operations which are handled
in an synchronized way and waiting for an answer. For non-blocking lock
requests the answer will probably arrive in the same time as unlock or
cancellation operations as those are trylock operations only.

In case of a blocking lock request we need to have it asynchronously
because the time when the lock request getting granted is unknown.

Signed-off-by: Alexander Aring <aahringo@redhat.com>
---
 fs/lockd/svclock.c | 39 +++++++--------------------------------
 1 file changed, 7 insertions(+), 32 deletions(-)

diff --git a/fs/lockd/svclock.c b/fs/lockd/svclock.c
index 7d63524bdb81..1e74a578d7de 100644
--- a/fs/lockd/svclock.c
+++ b/fs/lockd/svclock.c
@@ -440,31 +440,6 @@ static void nlmsvc_freegrantargs(struct nlm_rqst *call)
 	locks_release_private(&call->a_args.lock.fl);
 }
 
-/*
- * Deferred lock request handling for non-blocking lock
- */
-static __be32
-nlmsvc_defer_lock_rqst(struct svc_rqst *rqstp, struct nlm_block *block)
-{
-	__be32 status = nlm_lck_denied_nolocks;
-
-	block->b_flags |= B_QUEUED;
-
-	nlmsvc_insert_block(block, NLM_TIMEOUT);
-
-	block->b_cache_req = &rqstp->rq_chandle;
-	if (rqstp->rq_chandle.defer) {
-		block->b_deferred_req =
-			rqstp->rq_chandle.defer(block->b_cache_req);
-		if (block->b_deferred_req != NULL)
-			status = nlm_drop_reply;
-	}
-	dprintk("lockd: nlmsvc_defer_lock_rqst block %p flags %d status %d\n",
-		block, block->b_flags, ntohl(status));
-
-	return status;
-}
-
 /*
  * Attempt to establish a lock, and if it can't be granted, block it
  * if required.
@@ -569,14 +544,14 @@ nlmsvc_lock(struct svc_rqst *rqstp, struct nlm_file *file,
 			ret = async_block ? nlm_lck_blocked : nlm_lck_denied;
 			goto out_cb_mutex;
 		case FILE_LOCK_DEFERRED:
-			block->b_flags |= B_PENDING_CALLBACK;
+			/* lock requests without waiters are handled in
+			 * a non async way. Let assert this to inform
+			 * the user about a API violation.
+			 */
+			WARN_ON_ONCE(!wait);
 
-			if (wait)
-				break;
-			/* Filesystem lock operation is in progress
-			   Add it to the queue waiting for callback */
-			ret = nlmsvc_defer_lock_rqst(rqstp, block);
-			goto out_cb_mutex;
+			block->b_flags |= B_PENDING_CALLBACK;
+			break;
 		case -EDEADLK:
 			nlmsvc_remove_block(block);
 			ret = nlm_deadlock;
-- 
2.31.1


WARNING: multiple messages have this Message-ID (diff)
From: Alexander Aring <aahringo@redhat.com>
To: linux-nfs@vger.kernel.org
Cc: jlayton@kernel.org, cluster-devel@redhat.com,
	ocfs2-devel@lists.linux.dev, chuck.lever@oracle.com,
	anna@kernel.org, linux-fsdevel@vger.kernel.org,
	trond.myklebust@hammerspace.com
Subject: [Cluster-devel] [RFCv2 2/7] lockd: FILE_LOCK_DEFERRED only on FL_SLEEP
Date: Mon, 14 Aug 2023 17:11:11 -0400	[thread overview]
Message-ID: <20230814211116.3224759-3-aahringo@redhat.com> (raw)
In-Reply-To: <20230814211116.3224759-1-aahringo@redhat.com>

This patch removes to handle non-blocking lock requests as asynchronous
lock request returning FILE_LOCK_DEFERRED. When fl_lmops and lm_grant()
is set and a non-blocking lock request returns FILE_LOCK_DEFERRED will
end in an WARNING to signal the user the misusage of the API.

The reason why we moving to make non-blocking lock request as
synchronized call is that we already doing this behaviour for unlock or
cancellation as well. Those are POSIX lock operations which are handled
in an synchronized way and waiting for an answer. For non-blocking lock
requests the answer will probably arrive in the same time as unlock or
cancellation operations as those are trylock operations only.

In case of a blocking lock request we need to have it asynchronously
because the time when the lock request getting granted is unknown.

Signed-off-by: Alexander Aring <aahringo@redhat.com>
---
 fs/lockd/svclock.c | 39 +++++++--------------------------------
 1 file changed, 7 insertions(+), 32 deletions(-)

diff --git a/fs/lockd/svclock.c b/fs/lockd/svclock.c
index 7d63524bdb81..1e74a578d7de 100644
--- a/fs/lockd/svclock.c
+++ b/fs/lockd/svclock.c
@@ -440,31 +440,6 @@ static void nlmsvc_freegrantargs(struct nlm_rqst *call)
 	locks_release_private(&call->a_args.lock.fl);
 }
 
-/*
- * Deferred lock request handling for non-blocking lock
- */
-static __be32
-nlmsvc_defer_lock_rqst(struct svc_rqst *rqstp, struct nlm_block *block)
-{
-	__be32 status = nlm_lck_denied_nolocks;
-
-	block->b_flags |= B_QUEUED;
-
-	nlmsvc_insert_block(block, NLM_TIMEOUT);
-
-	block->b_cache_req = &rqstp->rq_chandle;
-	if (rqstp->rq_chandle.defer) {
-		block->b_deferred_req =
-			rqstp->rq_chandle.defer(block->b_cache_req);
-		if (block->b_deferred_req != NULL)
-			status = nlm_drop_reply;
-	}
-	dprintk("lockd: nlmsvc_defer_lock_rqst block %p flags %d status %d\n",
-		block, block->b_flags, ntohl(status));
-
-	return status;
-}
-
 /*
  * Attempt to establish a lock, and if it can't be granted, block it
  * if required.
@@ -569,14 +544,14 @@ nlmsvc_lock(struct svc_rqst *rqstp, struct nlm_file *file,
 			ret = async_block ? nlm_lck_blocked : nlm_lck_denied;
 			goto out_cb_mutex;
 		case FILE_LOCK_DEFERRED:
-			block->b_flags |= B_PENDING_CALLBACK;
+			/* lock requests without waiters are handled in
+			 * a non async way. Let assert this to inform
+			 * the user about a API violation.
+			 */
+			WARN_ON_ONCE(!wait);
 
-			if (wait)
-				break;
-			/* Filesystem lock operation is in progress
-			   Add it to the queue waiting for callback */
-			ret = nlmsvc_defer_lock_rqst(rqstp, block);
-			goto out_cb_mutex;
+			block->b_flags |= B_PENDING_CALLBACK;
+			break;
 		case -EDEADLK:
 			nlmsvc_remove_block(block);
 			ret = nlm_deadlock;
-- 
2.31.1


  parent reply	other threads:[~2023-08-14 21:13 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-14 21:11 [RFCv2 0/7] fs: nfs: async lock request changes Alexander Aring
2023-08-14 21:11 ` [Cluster-devel] " Alexander Aring
2023-08-14 21:11 ` [RFCv2 1/7] lockd: fix race in async lock request handling Alexander Aring
2023-08-14 21:11   ` [Cluster-devel] " Alexander Aring
2023-08-15 17:49   ` Jeff Layton
2023-08-15 17:49     ` [Cluster-devel] " Jeff Layton
2023-08-15 18:21     ` Jeff Layton
2023-08-15 18:21       ` [Cluster-devel] " Jeff Layton
2023-08-17 18:39       ` Alexander Aring
2023-08-17 18:39         ` [Cluster-devel] " Alexander Aring
2023-08-17 18:36     ` Alexander Aring
2023-08-17 18:36       ` [Cluster-devel] " Alexander Aring
2023-08-14 21:11 ` Alexander Aring [this message]
2023-08-14 21:11   ` [Cluster-devel] [RFCv2 2/7] lockd: FILE_LOCK_DEFERRED only on FL_SLEEP Alexander Aring
2023-08-16 11:37   ` Jeff Layton
2023-08-16 11:37     ` [Cluster-devel] " Jeff Layton
2023-08-17  1:40     ` Alexander Aring
2023-08-17  1:40       ` Alexander Aring
2023-08-14 21:11 ` [RFCv2 3/7] lockd: introduce safe async lock op Alexander Aring
2023-08-14 21:11   ` [Cluster-devel] " Alexander Aring
2023-08-16 11:43   ` Jeff Layton
2023-08-16 11:43     ` [Cluster-devel] " Jeff Layton
2023-08-14 21:11 ` [RFCv2 4/7] locks: update lock callback documentation Alexander Aring
2023-08-14 21:11   ` [Cluster-devel] " Alexander Aring
2023-08-16 12:01   ` Jeff Layton
2023-08-16 12:01     ` [Cluster-devel] " Jeff Layton
2023-08-17  1:23     ` Alexander Aring
2023-08-17  1:23       ` Alexander Aring
2023-08-14 21:11 ` [RFCv2 5/7] dlm: use fl_owner from lockd Alexander Aring
2023-08-14 21:11   ` [Cluster-devel] " Alexander Aring
2023-08-16 12:02   ` Jeff Layton
2023-08-16 12:02     ` [Cluster-devel] " Jeff Layton
2023-08-14 21:11 ` [RFCv2 6/7] dlm: use FL_SLEEP to check if blocking request Alexander Aring
2023-08-14 21:11   ` [Cluster-devel] " Alexander Aring
2023-08-16 13:07   ` Jeff Layton
2023-08-16 13:07     ` [Cluster-devel] " Jeff Layton
2023-08-17  1:19     ` Alexander Aring
2023-08-17  1:19       ` Alexander Aring
2023-08-17 11:27       ` [Cluster-devel] " Jeff Layton
2023-08-17 11:27         ` Jeff Layton
2023-08-17 13:02         ` Alexander Aring
2023-08-17 13:02           ` [Cluster-devel] " Alexander Aring
2023-08-14 21:11 ` [RFCv2 7/7] dlm: implement EXPORT_OP_SAFE_ASYNC_LOCK Alexander Aring
2023-08-14 21:11   ` [Cluster-devel] " Alexander Aring

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=20230814211116.3224759-3-aahringo@redhat.com \
    --to=aahringo@redhat.com \
    --cc=agruenba@redhat.com \
    --cc=anna@kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=cluster-devel@redhat.com \
    --cc=jlayton@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=ocfs2-devel@lists.linux.dev \
    --cc=rpeterso@redhat.com \
    --cc=teigland@redhat.com \
    --cc=trond.myklebust@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.