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 4/7] locks: update lock callback documentation
Date: Mon, 14 Aug 2023 17:11:13 -0400 [thread overview]
Message-ID: <20230814211116.3224759-5-aahringo@redhat.com> (raw)
In-Reply-To: <20230814211116.3224759-1-aahringo@redhat.com>
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 <aahringo@redhat.com>
---
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)
{
--
2.31.1
next prev parent reply other threads:[~2023-08-14 21:11 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-14 21:11 [Cluster-devel] [RFCv2 0/7] fs: nfs: async lock request changes Alexander Aring
2023-08-14 21:11 ` [Cluster-devel] [RFCv2 1/7] lockd: fix race in async lock request handling Alexander Aring
2023-08-15 17:49 ` Jeff Layton
2023-08-15 18:21 ` Jeff Layton
2023-08-17 18:39 ` Alexander Aring
2023-08-17 18:36 ` Alexander Aring
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-17 1:40 ` Alexander Aring
2023-08-14 21:11 ` [Cluster-devel] [RFCv2 3/7] lockd: introduce safe async lock op Alexander Aring
2023-08-16 11:43 ` Jeff Layton
2023-08-14 21:11 ` Alexander Aring [this message]
2023-08-16 12:01 ` [Cluster-devel] [RFCv2 4/7] locks: update lock callback documentation Jeff Layton
2023-08-17 1:23 ` Alexander Aring
2023-08-14 21:11 ` [Cluster-devel] [RFCv2 5/7] dlm: use fl_owner from lockd Alexander Aring
2023-08-16 12:02 ` Jeff Layton
2023-08-14 21:11 ` [Cluster-devel] [RFCv2 6/7] dlm: use FL_SLEEP to check if blocking request Alexander Aring
2023-08-16 13:07 ` Jeff Layton
2023-08-17 1:19 ` Alexander Aring
2023-08-17 11:27 ` Jeff Layton
2023-08-17 13:02 ` Alexander Aring
2023-08-14 21:11 ` [Cluster-devel] [RFCv2 7/7] dlm: implement EXPORT_OP_SAFE_ASYNC_LOCK 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-5-aahringo@redhat.com \
--to=aahringo@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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).