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: [PATCH 3/7] lockd: fix race in async lock request handling Date: Wed, 23 Aug 2023 17:33:48 -0400 [thread overview] Message-ID: <20230823213352.1971009-4-aahringo@redhat.com> (raw) In-Reply-To: <20230823213352.1971009-1-aahringo@redhat.com> This patch fixes a race in async lock request handling between adding the relevant struct nlm_block to nlm_blocked list after the request was sent by vfs_lock_file() and nlmsvc_grant_deferred() does a lookup of the nlm_block in the nlm_blocked list. It could be that the async request is completed before the nlm_block was added to the list. This would end in a -ENOENT and a kernel log message of "lockd: grant for unknown block". To solve this issue we add the nlm_block before the vfs_lock_file() call to be sure it has been added when a possible nlmsvc_grant_deferred() is called. If the vfs_lock_file() results in an case when it wouldn't be added to nlm_blocked list, the nlm_block struct will be removed from this list again. The introducing of the new B_PENDING_CALLBACK nlm_block flag will handle async lock requests on a pending lock requests as a retry on the caller level to hit the -EAGAIN case. Signed-off-by: Alexander Aring <aahringo@redhat.com> --- fs/lockd/svclock.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/fs/lockd/svclock.c b/fs/lockd/svclock.c index aa4174fbaf5b..3b158446203b 100644 --- a/fs/lockd/svclock.c +++ b/fs/lockd/svclock.c @@ -546,6 +546,9 @@ nlmsvc_lock(struct svc_rqst *rqstp, struct nlm_file *file, ret = nlm_lck_blocked; goto out; } + + /* Append to list of blocked */ + nlmsvc_insert_block_locked(block, NLM_NEVER); spin_unlock(&nlm_blocked_lock); if (!wait) @@ -557,9 +560,12 @@ nlmsvc_lock(struct svc_rqst *rqstp, struct nlm_file *file, dprintk("lockd: vfs_lock_file returned %d\n", error); switch (error) { case 0: + nlmsvc_remove_block(block); ret = nlm_granted; goto out; case -EAGAIN: + if (!wait) + nlmsvc_remove_block(block); ret = async_block ? nlm_lck_blocked : nlm_lck_denied; goto out; case FILE_LOCK_DEFERRED: @@ -570,17 +576,16 @@ nlmsvc_lock(struct svc_rqst *rqstp, struct nlm_file *file, ret = nlmsvc_defer_lock_rqst(rqstp, block); goto out; case -EDEADLK: + nlmsvc_remove_block(block); ret = nlm_deadlock; goto out; default: /* includes ENOLCK */ + nlmsvc_remove_block(block); ret = nlm_lck_denied_nolocks; goto out; } ret = nlm_lck_blocked; - - /* Append to list of blocked */ - nlmsvc_insert_block(block, NLM_NEVER); out: mutex_unlock(&file->f_mutex); nlmsvc_release_block(block); -- 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] [PATCH 3/7] lockd: fix race in async lock request handling Date: Wed, 23 Aug 2023 17:33:48 -0400 [thread overview] Message-ID: <20230823213352.1971009-4-aahringo@redhat.com> (raw) In-Reply-To: <20230823213352.1971009-1-aahringo@redhat.com> This patch fixes a race in async lock request handling between adding the relevant struct nlm_block to nlm_blocked list after the request was sent by vfs_lock_file() and nlmsvc_grant_deferred() does a lookup of the nlm_block in the nlm_blocked list. It could be that the async request is completed before the nlm_block was added to the list. This would end in a -ENOENT and a kernel log message of "lockd: grant for unknown block". To solve this issue we add the nlm_block before the vfs_lock_file() call to be sure it has been added when a possible nlmsvc_grant_deferred() is called. If the vfs_lock_file() results in an case when it wouldn't be added to nlm_blocked list, the nlm_block struct will be removed from this list again. The introducing of the new B_PENDING_CALLBACK nlm_block flag will handle async lock requests on a pending lock requests as a retry on the caller level to hit the -EAGAIN case. Signed-off-by: Alexander Aring <aahringo@redhat.com> --- fs/lockd/svclock.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/fs/lockd/svclock.c b/fs/lockd/svclock.c index aa4174fbaf5b..3b158446203b 100644 --- a/fs/lockd/svclock.c +++ b/fs/lockd/svclock.c @@ -546,6 +546,9 @@ nlmsvc_lock(struct svc_rqst *rqstp, struct nlm_file *file, ret = nlm_lck_blocked; goto out; } + + /* Append to list of blocked */ + nlmsvc_insert_block_locked(block, NLM_NEVER); spin_unlock(&nlm_blocked_lock); if (!wait) @@ -557,9 +560,12 @@ nlmsvc_lock(struct svc_rqst *rqstp, struct nlm_file *file, dprintk("lockd: vfs_lock_file returned %d\n", error); switch (error) { case 0: + nlmsvc_remove_block(block); ret = nlm_granted; goto out; case -EAGAIN: + if (!wait) + nlmsvc_remove_block(block); ret = async_block ? nlm_lck_blocked : nlm_lck_denied; goto out; case FILE_LOCK_DEFERRED: @@ -570,17 +576,16 @@ nlmsvc_lock(struct svc_rqst *rqstp, struct nlm_file *file, ret = nlmsvc_defer_lock_rqst(rqstp, block); goto out; case -EDEADLK: + nlmsvc_remove_block(block); ret = nlm_deadlock; goto out; default: /* includes ENOLCK */ + nlmsvc_remove_block(block); ret = nlm_lck_denied_nolocks; goto out; } ret = nlm_lck_blocked; - - /* Append to list of blocked */ - nlmsvc_insert_block(block, NLM_NEVER); out: mutex_unlock(&file->f_mutex); nlmsvc_release_block(block); -- 2.31.1
next prev parent reply other threads:[~2023-08-23 21:35 UTC|newest] Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-08-23 21:33 [PATCH 0/7] lockd: dlm: async lock request changes Alexander Aring 2023-08-23 21:33 ` [Cluster-devel] " Alexander Aring 2023-08-23 21:33 ` [PATCH 1/7] lockd: introduce safe async lock op Alexander Aring 2023-08-23 21:33 ` [Cluster-devel] " Alexander Aring 2023-08-25 17:21 ` Chuck Lever 2023-08-25 17:21 ` [Cluster-devel] " Chuck Lever 2023-08-30 12:32 ` Alexander Aring 2023-08-30 12:32 ` [Cluster-devel] " Alexander Aring 2023-08-30 13:45 ` Chuck Lever 2023-08-30 13:45 ` [Cluster-devel] " Chuck Lever 2023-08-25 18:14 ` Jeff Layton 2023-08-25 18:14 ` [Cluster-devel] " Jeff Layton 2023-08-23 21:33 ` [PATCH 2/7] lockd: don't call vfs_lock_file() for pending requests Alexander Aring 2023-08-23 21:33 ` [Cluster-devel] " Alexander Aring 2023-08-25 18:10 ` Jeff Layton 2023-08-25 18:10 ` [Cluster-devel] " Jeff Layton 2023-08-30 12:15 ` Alexander Aring 2023-08-30 12:15 ` [Cluster-devel] " Alexander Aring 2023-08-23 21:33 ` Alexander Aring [this message] 2023-08-23 21:33 ` [Cluster-devel] [PATCH 3/7] lockd: fix race in async lock request handling Alexander Aring 2023-08-25 17:35 ` Chuck Lever 2023-08-25 17:35 ` [Cluster-devel] " Chuck Lever 2023-08-25 18:16 ` Jeff Layton 2023-08-25 18:16 ` Jeff Layton 2023-08-23 21:33 ` [Cluster-devel] [PATCH 4/7] lockd: add doc to enable EXPORT_OP_SAFE_ASYNC_LOCK Alexander Aring 2023-08-23 21:33 ` Alexander Aring 2023-08-25 18:17 ` Jeff Layton 2023-08-25 18:17 ` [Cluster-devel] " Jeff Layton 2023-08-23 21:33 ` [Cluster-devel] [PATCH 5/7] dlm: use fl_owner from lockd Alexander Aring 2023-08-23 21:33 ` Alexander Aring 2023-08-23 21:33 ` [Cluster-devel] [PATCH 6/7] dlm: use FL_SLEEP to determine blocking vs non-blocking Alexander Aring 2023-08-23 21:33 ` Alexander Aring 2023-08-25 18:18 ` [Cluster-devel] " Jeff Layton 2023-08-25 18:18 ` Jeff Layton 2023-08-30 12:38 ` Alexander Aring 2023-08-30 12:38 ` [Cluster-devel] " Alexander Aring 2023-08-30 13:46 ` Jeff Layton 2023-08-30 13:46 ` [Cluster-devel] " Jeff Layton 2023-08-23 21:33 ` [Cluster-devel] [PATCH 7/7] dlm: implement EXPORT_OP_SAFE_ASYNC_LOCK Alexander Aring 2023-08-23 21:33 ` 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=20230823213352.1971009-4-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: linkBe 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.