diff options
author | Benjamin Coddington <bcodding@redhat.com> | 2024-09-11 15:42:57 -0400 |
---|---|---|
committer | Christian Brauner <brauner@kernel.org> | 2024-09-12 14:39:05 +0200 |
commit | 8cf9a01edc216b16b5839eb793ac544d2c97ce97 (patch) | |
tree | d7cc6fea56b31a61ad8352c420624493d94a8b54 /tools/perf/scripts/python/export-to-postgresql.py | |
parent | cef48236dfe55fa266d505e8a497963a7bc5ef2a (diff) |
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>
Diffstat (limited to 'tools/perf/scripts/python/export-to-postgresql.py')
0 files changed, 0 insertions, 0 deletions