]> www.infradead.org Git - users/jedix/linux-maple.git/commit
fs: Introduce FOP_ASYNC_LOCK
authorBenjamin Coddington <bcodding@redhat.com>
Wed, 11 Sep 2024 19:42:57 +0000 (15:42 -0400)
committerChristian Brauner <brauner@kernel.org>
Thu, 12 Sep 2024 12:39:05 +0000 (14:39 +0200)
commit8cf9a01edc216b16b5839eb793ac544d2c97ce97
treed7cc6fea56b31a61ad8352c420624493d94a8b54
parentcef48236dfe55fa266d505e8a497963a7bc5ef2a
fs: Introduce FOP_ASYNC_LOCK

Some lock managers (NLM, kNFSD) fastidiously avoid blocking their
kernel threads while servicing blocking locks.  If a filesystem supports
asynchronous lock requests those lock managers can use notifications to
quickly inform clients they have acquired a file lock.

Historically, only posix_lock_file() was capable of supporting asynchronous
locks so the check for support was simply file_operations->lock(), but with
recent changes in DLM, both GFS2 and OCFS2 also support asynchronous locks
and have started signalling their support with EXPORT_OP_ASYNC_LOCK.

We recently noticed that those changes dropped the checks for whether a
filesystem simply defaults to posix_lock_file(), so async lock
notifications have not been attempted for NLM and NFSv4.1+ for most
filesystems.  While trying to fix this it has become clear that testing
both the export flag combined with testing ->lock() creates quite a
layering mess.  It seems appropriate to signal support with a fop_flag.

Add FOP_ASYNC_LOCK so that filesystems with ->lock() can signal their
capability to handle lock requests asynchronously.  Add a helper for
lock managers to properly test that support.

Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
Link: https://lore.kernel.org/r/3330d5a324abe2ce9c1dafe89cacdc6db41945d1.1726083391.git.bcodding@redhat.com
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Christian Brauner <brauner@kernel.org>
include/linux/filelock.h
include/linux/fs.h