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 0/7] fs: nfs: async lock request changes
Date: Mon, 14 Aug 2023 17:11:09 -0400 [thread overview]
Message-ID: <20230814211116.3224759-1-aahringo@redhat.com> (raw)
Hi,
this patch series contains changes to lockd asynchronous lock request
handling over vfs_lock_file(). The only one upstream user so far I see
is DLM. The current DLM handling of asynchronous lock request is broken.
Those patches makes the asynchronous lock request handling better, there
are still issues with fencing or lock cancellation that this patch
series does not tackle.
The cifs filesystem is another user of FILE_LOCK_DEFERRED but it does
not do anything on checking lm_grant() as the asynchronous lock API is
required to check if it's set.
- Alex
changes since v2:
- add dlm fixes/changes to show how the new API should work. It's used
by gfs2/ocfs2.
- handle non-blocking request synchronously. For this reason we needed
to introduce a new per nlm_block request to fix a race between
request and lm_grant() callback handling, see b_cb_mutex
- update documentation for new FL_SLEEP handling when lm_grant() is
set and new requirement that lm_grant() need to be called from a
sleepable contex.
- clear new CALLBACK PENDING flag when nlm_block is removed from
nlm_blocked
- introduce helper export_op_support_safe_async_lock() to check if
the filesystem supports asynchronous lock request calls
- fix block variable never NULL when iterating over nlm_blocked list
Alexander Aring (7):
lockd: fix race in async lock request handling
lockd: FILE_LOCK_DEFERRED only on FL_SLEEP
lockd: introduce safe async lock op
locks: update lock callback documentation
dlm: use fl_owner from lockd
dlm: use FL_SLEEP to check if blocking request
dlm: implement EXPORT_OP_SAFE_ASYNC_LOCK
fs/dlm/plock.c | 54 +++++++-------
fs/gfs2/export.c | 1 +
fs/lockd/svclock.c | 140 ++++++++++++++++++++----------------
fs/locks.c | 28 ++++----
fs/nfsd/nfs4state.c | 13 +++-
fs/ocfs2/export.c | 1 +
include/linux/exportfs.h | 8 +++
include/linux/lockd/lockd.h | 2 +
8 files changed, 140 insertions(+), 107 deletions(-)
--
2.31.1
next reply other threads:[~2023-08-14 21:13 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-14 21:11 Alexander Aring [this message]
2023-08-14 21:11 ` [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 ` [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 ` [RFCv2 3/7] lockd: introduce safe async lock op Alexander Aring
2023-08-16 11:43 ` Jeff Layton
2023-08-14 21:11 ` [RFCv2 4/7] locks: update lock callback documentation Alexander Aring
2023-08-16 12:01 ` Jeff Layton
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-16 12:02 ` Jeff Layton
2023-08-14 21:11 ` [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 ` [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-1-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 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 NNTP newsgroup(s).