From patchwork Mon Aug 14 21:11:10 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexander Aring X-Patchwork-Id: 13353301 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 820ECDDBD for ; Mon, 14 Aug 2023 21:11:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1692047486; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MTB6n9Lzh+gnb3QJmth1T9LtSZXZSrD2dMC30pyrg2M=; b=PjvgE6Mmhnio0qtIYdfECkX1nTYEI/+Td39a4kQHjPafqMGMJnShYjFvIt7ZL9VHcEopMV lL+CiFipkXcYzYyhQykqcNqldqi7sMQ7HC+N9AOTUYwLyVzsu28HHHJ4SAj5fMYS4LXVQx aLXfXNrhznlz6x3K4RQGWgCm8VAy8xY= Received: from mimecast-mx02.redhat.com (66.187.233.73 [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-635-y8MG4fJXP6KTkDjUXyzaRA-1; Mon, 14 Aug 2023 17:11:23 -0400 X-MC-Unique: y8MG4fJXP6KTkDjUXyzaRA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 8ED3E3804060; Mon, 14 Aug 2023 21:11:22 +0000 (UTC) Received: from fs-i40c-03.fs.lab.eng.bos.redhat.com (fs-i40c-03.fs.lab.eng.bos.redhat.com [10.16.224.23]) by smtp.corp.redhat.com (Postfix) with ESMTP id 40DE0C15BAD; Mon, 14 Aug 2023 21:11:22 +0000 (UTC) From: Alexander Aring 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 1/7] lockd: fix race in async lock request handling Date: Mon, 14 Aug 2023 17:11:10 -0400 Message-Id: <20230814211116.3224759-2-aahringo@redhat.com> In-Reply-To: <20230814211116.3224759-1-aahringo@redhat.com> References: <20230814211116.3224759-1-aahringo@redhat.com> Precedence: bulk X-Mailing-List: ocfs2-devel@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 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 Signed-off-by: Jeff Layton --- fs/lockd/svclock.c | 100 ++++++++++++++++++++++++++---------- include/linux/lockd/lockd.h | 2 + 2 files changed, 74 insertions(+), 28 deletions(-) diff --git a/fs/lockd/svclock.c b/fs/lockd/svclock.c index c43ccdf28ed9..7d63524bdb81 100644 --- a/fs/lockd/svclock.c +++ b/fs/lockd/svclock.c @@ -133,6 +133,7 @@ nlmsvc_remove_block(struct nlm_block *block) { if (!list_empty(&block->b_list)) { spin_lock(&nlm_blocked_lock); + block->b_flags &= ~B_PENDING_CALLBACK; list_del_init(&block->b_list); spin_unlock(&nlm_blocked_lock); nlmsvc_release_block(block); @@ -232,6 +233,7 @@ nlmsvc_create_block(struct svc_rqst *rqstp, struct nlm_host *host, kref_init(&block->b_count); INIT_LIST_HEAD(&block->b_list); INIT_LIST_HEAD(&block->b_flist); + mutex_init(&block->b_cb_mutex); if (!nlmsvc_setgrantargs(call, lock)) goto failed_free; @@ -289,6 +291,8 @@ static void nlmsvc_free_block(struct kref *kref) dprintk("lockd: freeing block %p...\n", block); + WARN_ON_ONCE(block->b_flags & B_PENDING_CALLBACK); + /* Remove block from file's list of blocks */ list_del_init(&block->b_flist); mutex_unlock(&file->f_mutex); @@ -532,6 +536,13 @@ nlmsvc_lock(struct svc_rqst *rqstp, struct nlm_file *file, goto out; } + mutex_lock(&block->b_cb_mutex); + if (block->b_flags & B_PENDING_CALLBACK) + goto pending_request; + + /* Append to list of blocked */ + nlmsvc_insert_block(block, NLM_NEVER); + if (!wait) lock->fl.fl_flags &= ~FL_SLEEP; mode = lock_to_openmode(&lock->fl); @@ -541,9 +552,13 @@ 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; + goto out_cb_mutex; case -EAGAIN: + if (!wait) + nlmsvc_remove_block(block); +pending_request: /* * If this is a blocking request for an * already pending lock request then we need @@ -552,26 +567,29 @@ nlmsvc_lock(struct svc_rqst *rqstp, struct nlm_file *file, if (wait) break; ret = async_block ? nlm_lck_blocked : nlm_lck_denied; - goto out; + goto out_cb_mutex; case FILE_LOCK_DEFERRED: + block->b_flags |= B_PENDING_CALLBACK; + 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; + goto out_cb_mutex; case -EDEADLK: + nlmsvc_remove_block(block); ret = nlm_deadlock; - goto out; + goto out_cb_mutex; default: /* includes ENOLCK */ + nlmsvc_remove_block(block); ret = nlm_lck_denied_nolocks; - goto out; + goto out_cb_mutex; } ret = nlm_lck_blocked; - - /* Append to list of blocked */ - nlmsvc_insert_block(block, NLM_NEVER); +out_cb_mutex: + mutex_unlock(&block->b_cb_mutex); out: mutex_unlock(&file->f_mutex); nlmsvc_release_block(block); @@ -728,34 +746,60 @@ nlmsvc_update_deferred_block(struct nlm_block *block, int result) block->b_flags |= B_TIMED_OUT; } +static int __nlmsvc_grant_deferred(struct nlm_block *block, + struct file_lock *fl, + int result) +{ + int rc = 0; + + dprintk("lockd: nlmsvc_notify_blocked block %p flags %d\n", + block, block->b_flags); + if (block->b_flags & B_QUEUED) { + if (block->b_flags & B_TIMED_OUT) { + rc = -ENOLCK; + goto out; + } + nlmsvc_update_deferred_block(block, result); + } else if (result == 0) + block->b_granted = 1; + + nlmsvc_insert_block_locked(block, 0); + svc_wake_up(block->b_daemon); +out: + return rc; +} + static int nlmsvc_grant_deferred(struct file_lock *fl, int result) { - struct nlm_block *block; - int rc = -ENOENT; + struct nlm_block *iter, *block = NULL; + int rc; spin_lock(&nlm_blocked_lock); - list_for_each_entry(block, &nlm_blocked, b_list) { - if (nlm_compare_locks(&block->b_call->a_args.lock.fl, fl)) { - dprintk("lockd: nlmsvc_notify_blocked block %p flags %d\n", - block, block->b_flags); - if (block->b_flags & B_QUEUED) { - if (block->b_flags & B_TIMED_OUT) { - rc = -ENOLCK; - break; - } - nlmsvc_update_deferred_block(block, result); - } else if (result == 0) - block->b_granted = 1; - - nlmsvc_insert_block_locked(block, 0); - svc_wake_up(block->b_daemon); - rc = 0; + list_for_each_entry(iter, &nlm_blocked, b_list) { + if (nlm_compare_locks(&iter->b_call->a_args.lock.fl, fl)) { + kref_get(&iter->b_count); + block = iter; break; } } spin_unlock(&nlm_blocked_lock); - if (rc == -ENOENT) - printk(KERN_WARNING "lockd: grant for unknown block\n"); + + if (!block) { + pr_warn("lockd: grant for unknown pending block\n"); + return -ENOENT; + } + + /* don't interfere with nlmsvc_lock() */ + mutex_lock(&block->b_cb_mutex); + block->b_flags &= ~B_PENDING_CALLBACK; + + spin_lock(&nlm_blocked_lock); + WARN_ON_ONCE(list_empty(&block->b_list)); + rc = __nlmsvc_grant_deferred(block, fl, result); + spin_unlock(&nlm_blocked_lock); + mutex_unlock(&block->b_cb_mutex); + + nlmsvc_release_block(block); return rc; } diff --git a/include/linux/lockd/lockd.h b/include/linux/lockd/lockd.h index f42594a9efe0..91f55458f5fc 100644 --- a/include/linux/lockd/lockd.h +++ b/include/linux/lockd/lockd.h @@ -185,10 +185,12 @@ struct nlm_block { struct nlm_file * b_file; /* file in question */ struct cache_req * b_cache_req; /* deferred request handling */ struct cache_deferred_req * b_deferred_req; + struct mutex b_cb_mutex; /* callback mutex */ unsigned int b_flags; /* block flags */ #define B_QUEUED 1 /* lock queued */ #define B_GOT_CALLBACK 2 /* got lock or conflicting lock */ #define B_TIMED_OUT 4 /* filesystem too slow to respond */ +#define B_PENDING_CALLBACK 8 /* pending callback for lock request */ }; /* From patchwork Mon Aug 14 21:11:11 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexander Aring X-Patchwork-Id: 13353303 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5254DDDDA for ; Mon, 14 Aug 2023 21:11:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1692047487; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+ha7qooP5xHAJkp/n5Tt2zY2sO83T4RUyDIe+tf4ioM=; b=FLKe5d9+VXl7M+DnAYuQQjccdXxYNXbGUXDjeNmEaeAgRSzWOlUmz5jNKl7BK+27hkYGZA 4m1J7yd0nnA89aS64fj+uOVribm/0i7DEvYjcS2ps21cNNnSH9KE/DJj1iK4Xxi4nrRMLj H/608jaWEY1YjN+XxxxJAxlfw7odsew= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-632-zltn7uhJN3WG1u-waD-sIw-1; Mon, 14 Aug 2023 17:11:23 -0400 X-MC-Unique: zltn7uhJN3WG1u-waD-sIw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id E13F28007A4; Mon, 14 Aug 2023 21:11:22 +0000 (UTC) Received: from fs-i40c-03.fs.lab.eng.bos.redhat.com (fs-i40c-03.fs.lab.eng.bos.redhat.com [10.16.224.23]) by smtp.corp.redhat.com (Postfix) with ESMTP id 95902C15BAD; Mon, 14 Aug 2023 21:11:22 +0000 (UTC) From: Alexander Aring 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 Message-Id: <20230814211116.3224759-3-aahringo@redhat.com> In-Reply-To: <20230814211116.3224759-1-aahringo@redhat.com> References: <20230814211116.3224759-1-aahringo@redhat.com> Precedence: bulk X-Mailing-List: ocfs2-devel@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 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 --- 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; From patchwork Mon Aug 14 21:11:12 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexander Aring X-Patchwork-Id: 13353300 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 48A46C143 for ; Mon, 14 Aug 2023 21:11:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1692047486; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3CdvUCR67HKTzgA8ywdTr8ioyoTx7c9EJeXX3FgxDN0=; b=jKb/I9aHHy+0OSFB8mHwuvxxB4kKZXLxRA2lMz+ZUid0/Y4tdXZtzIHLqS9rTZLfzZtgum VpcS1wmz1pmP1sH23bNqR6NPvG3MkzRTQdwtN6MjlfevseQeCnjWlm2lN9RZBkWRKeGibz bFQ2BGbmc0gv4wsgnjH0M9dXiQKIC3c= Received: from mimecast-mx02.redhat.com (66.187.233.73 [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-622-IbmwCf1LOECBsoU0pJIQdw-1; Mon, 14 Aug 2023 17:11:23 -0400 X-MC-Unique: IbmwCf1LOECBsoU0pJIQdw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 41E5C1C0E0C0; Mon, 14 Aug 2023 21:11:23 +0000 (UTC) Received: from fs-i40c-03.fs.lab.eng.bos.redhat.com (fs-i40c-03.fs.lab.eng.bos.redhat.com [10.16.224.23]) by smtp.corp.redhat.com (Postfix) with ESMTP id E9DD8C15BAD; Mon, 14 Aug 2023 21:11:22 +0000 (UTC) From: Alexander Aring 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 3/7] lockd: introduce safe async lock op Date: Mon, 14 Aug 2023 17:11:12 -0400 Message-Id: <20230814211116.3224759-4-aahringo@redhat.com> In-Reply-To: <20230814211116.3224759-1-aahringo@redhat.com> References: <20230814211116.3224759-1-aahringo@redhat.com> Precedence: bulk X-Mailing-List: ocfs2-devel@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 This patch reverts mostly commit 40595cdc93ed ("nfs: block notification on fs with its own ->lock") and introduces an EXPORT_OP_SAFE_ASYNC_LOCK export flag to signal that the "own ->lock" implementation supports async lock requests. The only main user is DLM that is used by GFS2 and OCFS2 filesystem. Those implement their own lock() implementation and return FILE_LOCK_DEFERRED as return value. Since commit 40595cdc93ed ("nfs: block notification on fs with its own ->lock") the DLM implementation were never updated. This patch should prepare for DLM to set the EXPORT_OP_SAFE_ASYNC_LOCK export flag and update the DLM plock implementation regarding to it. Signed-off-by: Alexander Aring Acked-by: Jeff Layton --- fs/lockd/svclock.c | 5 ++--- fs/nfsd/nfs4state.c | 13 ++++++++++--- include/linux/exportfs.h | 8 ++++++++ 3 files changed, 20 insertions(+), 6 deletions(-) diff --git a/fs/lockd/svclock.c b/fs/lockd/svclock.c index 1e74a578d7de..b8bd2b841ee1 100644 --- a/fs/lockd/svclock.c +++ b/fs/lockd/svclock.c @@ -449,9 +449,7 @@ nlmsvc_lock(struct svc_rqst *rqstp, struct nlm_file *file, struct nlm_host *host, struct nlm_lock *lock, int wait, struct nlm_cookie *cookie, int reclaim) { -#if IS_ENABLED(CONFIG_SUNRPC_DEBUG) struct inode *inode = nlmsvc_file_inode(file); -#endif struct nlm_block *block = NULL; int error; int mode; @@ -465,7 +463,8 @@ nlmsvc_lock(struct svc_rqst *rqstp, struct nlm_file *file, (long long)lock->fl.fl_end, wait); - if (nlmsvc_file_file(file)->f_op->lock) { + if (!export_op_support_safe_async_lock(inode->i_sb->s_export_op, + nlmsvc_file_file(file)->f_op)) { async_block = wait; wait = 0; } diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c index 3aefbad4cc09..14ca06424ff1 100644 --- a/fs/nfsd/nfs4state.c +++ b/fs/nfsd/nfs4state.c @@ -7430,6 +7430,7 @@ nfsd4_lock(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate, struct nfsd4_blocked_lock *nbl = NULL; struct file_lock *file_lock = NULL; struct file_lock *conflock = NULL; + struct super_block *sb; __be32 status = 0; int lkflg; int err; @@ -7451,6 +7452,7 @@ nfsd4_lock(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate, dprintk("NFSD: nfsd4_lock: permission denied!\n"); return status; } + sb = cstate->current_fh.fh_dentry->d_sb; if (lock->lk_is_new) { if (nfsd4_has_session(cstate)) @@ -7502,7 +7504,9 @@ nfsd4_lock(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate, fp = lock_stp->st_stid.sc_file; switch (lock->lk_type) { case NFS4_READW_LT: - if (nfsd4_has_session(cstate)) + if (nfsd4_has_session(cstate) || + export_op_support_safe_async_lock(sb->s_export_op, + nf->nf_file->f_op)) fl_flags |= FL_SLEEP; fallthrough; case NFS4_READ_LT: @@ -7514,7 +7518,9 @@ nfsd4_lock(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate, fl_type = F_RDLCK; break; case NFS4_WRITEW_LT: - if (nfsd4_has_session(cstate)) + if (nfsd4_has_session(cstate) || + export_op_support_safe_async_lock(sb->s_export_op, + nf->nf_file->f_op)) fl_flags |= FL_SLEEP; fallthrough; case NFS4_WRITE_LT: @@ -7542,7 +7548,8 @@ nfsd4_lock(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate, * for file locks), so don't attempt blocking lock notifications * on those filesystems: */ - if (nf->nf_file->f_op->lock) + if (!export_op_support_safe_async_lock(sb->s_export_op, + nf->nf_file->f_op)) fl_flags &= ~FL_SLEEP; nbl = find_or_allocate_block(lock_sop, &fp->fi_fhandle, nn); diff --git a/include/linux/exportfs.h b/include/linux/exportfs.h index 11fbd0ee1370..10358a93cdc1 100644 --- a/include/linux/exportfs.h +++ b/include/linux/exportfs.h @@ -3,6 +3,7 @@ #define LINUX_EXPORTFS_H 1 #include +#include struct dentry; struct iattr; @@ -224,9 +225,16 @@ struct export_operations { atomic attribute updates */ #define EXPORT_OP_FLUSH_ON_CLOSE (0x20) /* fs flushes file data on close */ +#define EXPORT_OP_SAFE_ASYNC_LOCK (0x40) /* fs can do async lock request */ unsigned long flags; }; +static inline bool export_op_support_safe_async_lock(const struct export_operations *export_ops, + const struct file_operations *f_op) +{ + return (export_ops->flags & EXPORT_OP_SAFE_ASYNC_LOCK) || !f_op->lock; +} + extern int exportfs_encode_inode_fh(struct inode *inode, struct fid *fid, int *max_len, struct inode *parent, int flags); From patchwork Mon Aug 14 21:11:13 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexander Aring X-Patchwork-Id: 13353304 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 98FBADF4C for ; Mon, 14 Aug 2023 21:11:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1692047487; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/wqENBbj5y41JI93zB5OgbUzN7ReqPGhx+L0gn4tfM8=; b=YYMhHUPkQ1FHl+1OIjf4w480gy5YiiK3r8DRJ25PTLHslc2D5OxZUMpwJRf3W4ys+sKEpz RPGEa//R4uQUkm0vOGhH9usravC7IjNw+FSk6MWGl1P+MhrXnH9gBeKOasa/sRQK7FkIr6 4jk9lVDrU+NE34kEFPZYPfAxWHuaOs0= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-509-94EUavPJO_GClPydUkdbng-1; Mon, 14 Aug 2023 17:11:24 -0400 X-MC-Unique: 94EUavPJO_GClPydUkdbng-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 96F41185A78F; Mon, 14 Aug 2023 21:11:23 +0000 (UTC) Received: from fs-i40c-03.fs.lab.eng.bos.redhat.com (fs-i40c-03.fs.lab.eng.bos.redhat.com [10.16.224.23]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4A510C15BAD; Mon, 14 Aug 2023 21:11:23 +0000 (UTC) From: Alexander Aring 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 4/7] locks: update lock callback documentation Date: Mon, 14 Aug 2023 17:11:13 -0400 Message-Id: <20230814211116.3224759-5-aahringo@redhat.com> In-Reply-To: <20230814211116.3224759-1-aahringo@redhat.com> References: <20230814211116.3224759-1-aahringo@redhat.com> Precedence: bulk X-Mailing-List: ocfs2-devel@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 This patch updates the existing documentation regarding recent changes to vfs_lock_file() and lm_grant() is set. In case of lm_grant() is set we only handle FILE_LOCK_DEFERRED in case of FL_SLEEP in fl_flags is not set. This is the case of an blocking lock request. Non-blocking lock requests, when FL_SLEEP is not set, are handled in a synchronized way. Signed-off-by: Alexander Aring --- fs/locks.c | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/fs/locks.c b/fs/locks.c index df8b26a42524..a8e51f462b43 100644 --- a/fs/locks.c +++ b/fs/locks.c @@ -2255,21 +2255,21 @@ int fcntl_getlk(struct file *filp, unsigned int cmd, struct flock *flock) * To avoid blocking kernel daemons, such as lockd, that need to acquire POSIX * locks, the ->lock() interface may return asynchronously, before the lock has * been granted or denied by the underlying filesystem, if (and only if) - * lm_grant is set. Callers expecting ->lock() to return asynchronously - * will only use F_SETLK, not F_SETLKW; they will set FL_SLEEP if (and only if) - * the request is for a blocking lock. When ->lock() does return asynchronously, - * it must return FILE_LOCK_DEFERRED, and call ->lm_grant() when the lock - * request completes. - * If the request is for non-blocking lock the file system should return - * FILE_LOCK_DEFERRED then try to get the lock and call the callback routine - * with the result. If the request timed out the callback routine will return a + * lm_grant and FL_SLEEP in fl_flags is set. Callers expecting ->lock() to return + * asynchronously will only use F_SETLK, not F_SETLKW; When ->lock() does return + * asynchronously, it must return FILE_LOCK_DEFERRED, and call ->lm_grant() when + * the lock request completes. The lm_grant() callback must be called in a + * sleepable context. + * + * If the request timed out the ->lm_grant() callback routine will return a * nonzero return code and the file system should release the lock. The file - * system is also responsible to keep a corresponding posix lock when it - * grants a lock so the VFS can find out which locks are locally held and do - * the correct lock cleanup when required. - * The underlying filesystem must not drop the kernel lock or call - * ->lm_grant() before returning to the caller with a FILE_LOCK_DEFERRED - * return code. + * system is also responsible to keep a corresponding posix lock when it grants + * a lock so the VFS can find out which locks are locally held and do the correct + * lock cleanup when required. + * + * If the request is for non-blocking lock (when F_SETLK and FL_SLEEP in fl_flags is not set) + * the file system should return -EAGAIN if failed to acquire or zero if acquiring was + * successfully without calling the ->lm_grant() callback routine. */ int vfs_lock_file(struct file *filp, unsigned int cmd, struct file_lock *fl, struct file_lock *conf) { From patchwork Mon Aug 14 21:11:14 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexander Aring X-Patchwork-Id: 13353305 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A7427DF51 for ; Mon, 14 Aug 2023 21:11:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1692047488; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=PSSlrsFejfUvsXC9yE3hAzAsATkv/23guIVtEFIrrmY=; b=B1dtHeQ4GB+i8N+EyZlIWakGdQpwbvXZjCT+uD4sAmvRCstSpN2URiy3r2V/6iITD3CMqC XfUii++6C5Q24bzZR9P6sfJtoD9cMx9loh4oh62806H5cUt47AJKrzEF+pM0/T1tLgyl3H dpFal48Pvbi1qtFZuO1ngcmTzyPA8O4= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-624-leEMYXNCOcyXP1rcvNUETg-1; Mon, 14 Aug 2023 17:11:24 -0400 X-MC-Unique: leEMYXNCOcyXP1rcvNUETg-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id EB5D7185A78B; Mon, 14 Aug 2023 21:11:23 +0000 (UTC) Received: from fs-i40c-03.fs.lab.eng.bos.redhat.com (fs-i40c-03.fs.lab.eng.bos.redhat.com [10.16.224.23]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9FBB5C15BAE; Mon, 14 Aug 2023 21:11:23 +0000 (UTC) From: Alexander Aring 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 5/7] dlm: use fl_owner from lockd Date: Mon, 14 Aug 2023 17:11:14 -0400 Message-Id: <20230814211116.3224759-6-aahringo@redhat.com> In-Reply-To: <20230814211116.3224759-1-aahringo@redhat.com> References: <20230814211116.3224759-1-aahringo@redhat.com> Precedence: bulk X-Mailing-List: ocfs2-devel@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 This patch is changing the fl_owner value in case of an nfs lock request to not be the pid of lockd. Instead this patch changes it to be the owner value that nfs is giving us. Currently there exists proved problems with this behaviour. One nfsd server was created to export a gfs2 filesystem mount. Two nfs clients doing a nfs mount of this export. Those two clients should conflict each other operating on the same nfs file. A small test program was written: int main(int argc, const char *argv[]) { struct flock fl = { .l_type = F_WRLCK, .l_whence = SEEK_SET, .l_start = 1L, .l_len = 1L, }; int fd; fd = open("filename", O_RDWR | O_CREAT, 0700); printf("try to lock...\n"); fcntl(fd, F_SETLKW, &fl); printf("locked!\n"); getc(stdin); return 0; } Running on both clients at the same time and don't interrupting by pressing any key. It will show that both clients are able to acquire the lock which shouldn't be the case. The issue is here that the fl_owner value is the same and the lock context of both clients should be separated. This patch lets lockd define how to deal with lock contexts and chose hopefully the right fl_owner value. A test after this patch was made and the locks conflicts each other which should be the case. Signed-off-by: Alexander Aring Acked-by: Jeff Layton --- fs/dlm/plock.c | 18 ++++-------------- 1 file changed, 4 insertions(+), 14 deletions(-) diff --git a/fs/dlm/plock.c b/fs/dlm/plock.c index 00e1d802a81c..0094fa4004cc 100644 --- a/fs/dlm/plock.c +++ b/fs/dlm/plock.c @@ -145,6 +145,7 @@ int dlm_posix_lock(dlm_lockspace_t *lockspace, u64 number, struct file *file, op->info.number = number; op->info.start = fl->fl_start; op->info.end = fl->fl_end; + op->info.owner = (__u64)(long)fl->fl_owner; /* async handling */ if (fl->fl_lmops && fl->fl_lmops->lm_grant) { op_data = kzalloc(sizeof(*op_data), GFP_NOFS); @@ -154,9 +155,6 @@ int dlm_posix_lock(dlm_lockspace_t *lockspace, u64 number, struct file *file, goto out; } - /* fl_owner is lockd which doesn't distinguish - processes on the nfs client */ - op->info.owner = (__u64) fl->fl_pid; op_data->callback = fl->fl_lmops->lm_grant; locks_init_lock(&op_data->flc); locks_copy_lock(&op_data->flc, fl); @@ -168,8 +166,6 @@ int dlm_posix_lock(dlm_lockspace_t *lockspace, u64 number, struct file *file, send_op(op); rv = FILE_LOCK_DEFERRED; goto out; - } else { - op->info.owner = (__u64)(long) fl->fl_owner; } send_op(op); @@ -326,10 +322,7 @@ int dlm_posix_unlock(dlm_lockspace_t *lockspace, u64 number, struct file *file, op->info.number = number; op->info.start = fl->fl_start; op->info.end = fl->fl_end; - if (fl->fl_lmops && fl->fl_lmops->lm_grant) - op->info.owner = (__u64) fl->fl_pid; - else - op->info.owner = (__u64)(long) fl->fl_owner; + op->info.owner = (__u64)(long)fl->fl_owner; if (fl->fl_flags & FL_CLOSE) { op->info.flags |= DLM_PLOCK_FL_CLOSE; @@ -389,7 +382,7 @@ int dlm_posix_cancel(dlm_lockspace_t *lockspace, u64 number, struct file *file, info.number = number; info.start = fl->fl_start; info.end = fl->fl_end; - info.owner = (__u64)fl->fl_pid; + info.owner = (__u64)(long)fl->fl_owner; rv = do_lock_cancel(&info); switch (rv) { @@ -450,10 +443,7 @@ int dlm_posix_get(dlm_lockspace_t *lockspace, u64 number, struct file *file, op->info.number = number; op->info.start = fl->fl_start; op->info.end = fl->fl_end; - if (fl->fl_lmops && fl->fl_lmops->lm_grant) - op->info.owner = (__u64) fl->fl_pid; - else - op->info.owner = (__u64)(long) fl->fl_owner; + op->info.owner = (__u64)(long)fl->fl_owner; send_op(op); wait_event(recv_wq, (op->done != 0)); From patchwork Mon Aug 14 21:11:15 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexander Aring X-Patchwork-Id: 13353307 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B8CA7DF52 for ; Mon, 14 Aug 2023 21:11:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1692047488; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=tZEXFed81ekvMweSZpvZmhvnw/W3DW6CK17WR1HloMI=; b=P3RxCVQh+HOTTR8HxJPRMEsCh9Qla7Vyly2ISNqfVco0Nbh6RRBgf3+df1wW2kqrnCQYMa oVuq37zTiIKM0LLXH1BZg0Ce/rlO5CZnD0KclXGaU3IvaZcwdNEgolg6vVPRS1Me9c85gn fjdJ0kR0EN41p336IwwUu4wtg2B9Uhw= Received: from mimecast-mx02.redhat.com (66.187.233.73 [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-607-OwVOreIAOrWvXEOKEJzbog-1; Mon, 14 Aug 2023 17:11:24 -0400 X-MC-Unique: OwVOreIAOrWvXEOKEJzbog-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4BE3F3C0253A; Mon, 14 Aug 2023 21:11:24 +0000 (UTC) Received: from fs-i40c-03.fs.lab.eng.bos.redhat.com (fs-i40c-03.fs.lab.eng.bos.redhat.com [10.16.224.23]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0000CC15BAD; Mon, 14 Aug 2023 21:11:23 +0000 (UTC) From: Alexander Aring 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 6/7] dlm: use FL_SLEEP to check if blocking request Date: Mon, 14 Aug 2023 17:11:15 -0400 Message-Id: <20230814211116.3224759-7-aahringo@redhat.com> In-Reply-To: <20230814211116.3224759-1-aahringo@redhat.com> References: <20230814211116.3224759-1-aahringo@redhat.com> Precedence: bulk X-Mailing-List: ocfs2-devel@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 This patch uses the FL_SLEEP flag in struct file_lock to check if it's a blocking request in case if the request coming from nfs lockd process indicated by lm_grant() is set. IF FL_SLEEP is set a asynchronous blocking request is being made and it's waiting for lm_grant() callback being called to signal the lock was granted. If it's not set a synchronous non-blocking request is being made. Signed-off-by: Alexander Aring --- fs/dlm/plock.c | 38 ++++++++++++++++++++++---------------- 1 file changed, 22 insertions(+), 16 deletions(-) diff --git a/fs/dlm/plock.c b/fs/dlm/plock.c index 0094fa4004cc..524771002a2f 100644 --- a/fs/dlm/plock.c +++ b/fs/dlm/plock.c @@ -140,7 +140,6 @@ int dlm_posix_lock(dlm_lockspace_t *lockspace, u64 number, struct file *file, op->info.optype = DLM_PLOCK_OP_LOCK; op->info.pid = fl->fl_pid; op->info.ex = (fl->fl_type == F_WRLCK); - op->info.wait = IS_SETLKW(cmd); op->info.fsid = ls->ls_global_id; op->info.number = number; op->info.start = fl->fl_start; @@ -148,24 +147,31 @@ int dlm_posix_lock(dlm_lockspace_t *lockspace, u64 number, struct file *file, op->info.owner = (__u64)(long)fl->fl_owner; /* async handling */ if (fl->fl_lmops && fl->fl_lmops->lm_grant) { - op_data = kzalloc(sizeof(*op_data), GFP_NOFS); - if (!op_data) { - dlm_release_plock_op(op); - rv = -ENOMEM; - goto out; - } + if (fl->fl_flags & FL_SLEEP) { + op_data = kzalloc(sizeof(*op_data), GFP_NOFS); + if (!op_data) { + dlm_release_plock_op(op); + rv = -ENOMEM; + goto out; + } - op_data->callback = fl->fl_lmops->lm_grant; - locks_init_lock(&op_data->flc); - locks_copy_lock(&op_data->flc, fl); - op_data->fl = fl; - op_data->file = file; + op->info.wait = 1; + op_data->callback = fl->fl_lmops->lm_grant; + locks_init_lock(&op_data->flc); + locks_copy_lock(&op_data->flc, fl); + op_data->fl = fl; + op_data->file = file; - op->data = op_data; + op->data = op_data; - send_op(op); - rv = FILE_LOCK_DEFERRED; - goto out; + send_op(op); + rv = FILE_LOCK_DEFERRED; + goto out; + } else { + op->info.wait = 0; + } + } else { + op->info.wait = IS_SETLKW(cmd); } send_op(op); From patchwork Mon Aug 14 21:11:16 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexander Aring X-Patchwork-Id: 13353306 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 71E26DDBD for ; Mon, 14 Aug 2023 21:11:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1692047488; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pArjaDFSJm/PaSO+le75amYj6A0iIy9B3F5/c/CEF10=; b=NcjXE1HQ7sljtRDyyfo8/Y2h9aWNbMw2uDuMLiCIGBMqsRTqt5UnjJWOcV0QZSaBTsxlJQ jW31s4pqJXI8h38CQ7DdUT5NM0i0BHplCCyvMUW/pz0RkUdms/sFkaxPqt1VqT/C+EWmHj E0LzHRUbWiiE8u1sZrufCF4eqJKP+I4= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-629-tdHYezREPYifPbAcv_kVng-1; Mon, 14 Aug 2023 17:11:25 -0400 X-MC-Unique: tdHYezREPYifPbAcv_kVng-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A0632101A53C; Mon, 14 Aug 2023 21:11:24 +0000 (UTC) Received: from fs-i40c-03.fs.lab.eng.bos.redhat.com (fs-i40c-03.fs.lab.eng.bos.redhat.com [10.16.224.23]) by smtp.corp.redhat.com (Postfix) with ESMTP id 54666C15BAE; Mon, 14 Aug 2023 21:11:24 +0000 (UTC) From: Alexander Aring 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 7/7] dlm: implement EXPORT_OP_SAFE_ASYNC_LOCK Date: Mon, 14 Aug 2023 17:11:16 -0400 Message-Id: <20230814211116.3224759-8-aahringo@redhat.com> In-Reply-To: <20230814211116.3224759-1-aahringo@redhat.com> References: <20230814211116.3224759-1-aahringo@redhat.com> Precedence: bulk X-Mailing-List: ocfs2-devel@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 This patch is activating the EXPORT_OP_SAFE_ASYNC_LOCK export flag to signal lockd that both filesystems are able to handle async lock requests. The cluster filesystems gfs2 and ocfs2 will redirect their lock requests to DLMs plock implementation that can handle async lock requests. Signed-off-by: Alexander Aring --- fs/gfs2/export.c | 1 + fs/ocfs2/export.c | 1 + 2 files changed, 2 insertions(+) diff --git a/fs/gfs2/export.c b/fs/gfs2/export.c index cf40895233f5..36bc43b9d141 100644 --- a/fs/gfs2/export.c +++ b/fs/gfs2/export.c @@ -192,5 +192,6 @@ const struct export_operations gfs2_export_ops = { .fh_to_parent = gfs2_fh_to_parent, .get_name = gfs2_get_name, .get_parent = gfs2_get_parent, + .flags = EXPORT_OP_SAFE_ASYNC_LOCK, }; diff --git a/fs/ocfs2/export.c b/fs/ocfs2/export.c index eaa8c80ace3c..8a1169e01dd9 100644 --- a/fs/ocfs2/export.c +++ b/fs/ocfs2/export.c @@ -280,4 +280,5 @@ const struct export_operations ocfs2_export_ops = { .fh_to_dentry = ocfs2_fh_to_dentry, .fh_to_parent = ocfs2_fh_to_parent, .get_parent = ocfs2_get_parent, + .flags = EXPORT_OP_SAFE_ASYNC_LOCK, };