From: Benjamin Coddington <bcodding@redhat.com>
To: Chuck Lever <chuck.lever@oracle.com>,
Jeff Layton <jlayton@kernel.org>,
Amir Goldstein <amir73il@gmail.com>, Neil Brown <neilb@suse.de>,
Trond Myklebust <trondmy@kernel.org>,
Anna Schumaker <anna@kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
Andreas Gruenbacher <agruenba@redhat.com>,
Mark Fasheh <mark@fasheh.com>, Joel Becker <jlbec@evilplan.org>,
Joseph Qi <joseph.qi@linux.alibaba.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
Alexander Ahring Oder Aring <aahringo@redhat.com>
Cc: linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
gfs2@lists.linux.dev, ocfs2-devel@lists.linux.dev
Subject: [PATCH v1 0/4] Fixup NLM and kNFSD file lock callbacks
Date: Wed, 11 Sep 2024 15:42:56 -0400 [thread overview]
Message-ID: <cover.1726083391.git.bcodding@redhat.com> (raw)
Last year both GFS2 and OCFS2 had some work done to make their locking more
robust when exported over NFS. Unfortunately, part of that work caused both
NLM (for NFS v3 exports) and kNFSD (for NFSv4.1+ exports) to no longer send
lock notifications to clients.
This in itself is not a huge problem because most NFS clients will still
poll the server in order to acquire a conflicted lock, but now that I've
noticed it I can't help but try to fix it because there are big advantages
for setups that might depend on timely lock notifications, and we've
supported that as a feature for a long time.
Its important for NLM and kNFSD that they do not block their kernel threads
inside filesystem's file_lock implementations because that can produce
deadlocks. We used to make sure of this by only trusting that
posix_lock_file() can correctly handle blocking lock calls asynchronously,
so the lock managers would only setup their file_lock requests for async
callbacks if the filesystem did not define its own lock() file operation.
However, when GFS2 and OCFS2 grew the capability to correctly
handle blocking lock requests asynchronously, they started signalling this
behavior with EXPORT_OP_ASYNC_LOCK, and the check for also trusting
posix_lock_file() was inadvertently dropped, so now most filesystems no
longer produce lock notifications when exported over NFS.
I tried to fix this by simply including the old check for lock(), but the
resulting include mess and layering violations was more than I could accept.
There's a much cleaner way presented here using an fop_flag, which while
potentially flag-greedy, greatly simplifies the problem and grooms the
way for future uses by both filesystems and lock managers alike.
Criticism welcomed,
Ben
Benjamin Coddington (4):
fs: Introduce FOP_ASYNC_LOCK
gfs2/ocfs2: set FOP_ASYNC_LOCK
NLM/NFSD: Fix lock notifications for async-capable filesystems
exportfs: Remove EXPORT_OP_ASYNC_LOCK
Documentation/filesystems/nfs/exporting.rst | 7 -------
fs/gfs2/export.c | 1 -
fs/gfs2/file.c | 2 ++
fs/lockd/svclock.c | 5 ++---
fs/nfsd/nfs4state.c | 19 ++++---------------
fs/ocfs2/export.c | 1 -
fs/ocfs2/file.c | 2 ++
include/linux/exportfs.h | 13 -------------
include/linux/filelock.h | 5 +++++
include/linux/fs.h | 2 ++
10 files changed, 17 insertions(+), 40 deletions(-)
--
2.44.0
next reply other threads:[~2024-09-11 19:43 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-11 19:42 Benjamin Coddington [this message]
2024-09-11 19:42 ` [PATCH v1 1/4] fs: Introduce FOP_ASYNC_LOCK Benjamin Coddington
2024-09-11 19:42 ` [PATCH v1 2/4] gfs2/ocfs2: set FOP_ASYNC_LOCK Benjamin Coddington
2024-09-11 19:42 ` [PATCH v1 3/4] NLM/NFSD: Fix lock notifications for async-capable filesystems Benjamin Coddington
2024-09-11 19:43 ` [PATCH v1 4/4] exportfs: Remove EXPORT_OP_ASYNC_LOCK Benjamin Coddington
2024-09-12 10:07 ` [PATCH v1 0/4] Fixup NLM and kNFSD file lock callbacks Christian Brauner
2024-09-12 11:08 ` Jeff Layton
2024-09-12 11:32 ` Christian Brauner
2024-09-12 11:51 ` Jeff Layton
2024-09-12 12:15 ` Benjamin Coddington
2024-09-12 12:40 ` Christian Brauner
2024-09-12 14:01 ` Chuck Lever III
2024-09-12 15:06 ` Benjamin Coddington
2024-09-12 18:17 ` Chuck Lever III
2024-09-12 19:11 ` Benjamin Coddington
2024-09-12 19:28 ` Chuck Lever III
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=cover.1726083391.git.bcodding@redhat.com \
--to=bcodding@redhat.com \
--cc=aahringo@redhat.com \
--cc=agruenba@redhat.com \
--cc=amir73il@gmail.com \
--cc=anna@kernel.org \
--cc=brauner@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=corbet@lwn.net \
--cc=gfs2@lists.linux.dev \
--cc=jack@suse.cz \
--cc=jlayton@kernel.org \
--cc=jlbec@evilplan.org \
--cc=joseph.qi@linux.alibaba.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=mark@fasheh.com \
--cc=neilb@suse.de \
--cc=ocfs2-devel@lists.linux.dev \
--cc=trondmy@kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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).