fs/lock: add 2 callbacks to lock_manager_operations to resolve conflict
authorDai Ngo <dai.ngo@oracle.com>
Mon, 2 May 2022 21:19:25 +0000 (14:19 -0700)
committerChuck Lever <chuck.lever@oracle.com>
Thu, 19 May 2022 16:25:39 +0000 (12:25 -0400)
commit2443da2259e97688f93d64d17ab69b15f466078a
tree78be912ab1bfaaf8756c93c3f62942a5f8e2cb4f
parent591502c5cb325b1c6ec59ab161927d606b918aa0
fs/lock: add 2 callbacks to lock_manager_operations to resolve conflict

Add 2 new callbacks, lm_lock_expirable and lm_expire_lock, to
lock_manager_operations to allow the lock manager to take appropriate
action to resolve the lock conflict if possible.

A new field, lm_mod_owner, is also added to lock_manager_operations.
The lm_mod_owner is used by the fs/lock code to make sure the lock
manager module such as nfsd, is not freed while lock conflict is being
resolved.

lm_lock_expirable checks and returns true to indicate that the lock
conflict can be resolved else return false. This callback must be
called with the flc_lock held so it can not block.

lm_expire_lock is called to resolve the lock conflict if the returned
value from lm_lock_expirable is true. This callback is called without
the flc_lock held since it's allowed to block. Upon returning from
this callback, the lock conflict should be resolved and the caller is
expected to restart the conflict check from the beginnning of the list.

Lock manager, such as NFSv4 courteous server, uses this callback to
resolve conflict by destroying lock owner, or the NFSv4 courtesy client
(client that has expired but allowed to maintains its states) that owns
the lock.

Reviewed-by: J. Bruce Fields <bfields@fieldses.org>
Signed-off-by: Dai Ngo <dai.ngo@oracle.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Documentation/filesystems/locking.rst
fs/locks.c
include/linux/fs.h