Hi Chuck, Bruce
This series of patches implement the NFSv4 Courteous Server.
A server which does not immediately expunge the state on lease expiration
is known as a Courteous Server. A Courteous Server continues to recognize
previously generated state tokens as valid until conflict arises between
the expired state and the requests from another client, or the server
reboots.
v2 patch includes:
. add new callback, lm_expire_lock, to lock_manager_operations to
allow the lock manager to take appropriate action with conflict lock.
. handle conflicts of NFSv4 locks with NFSv3/NLM and local locks.
. expire courtesy client after 24hr if client has not reconnected.
. do not allow expired client to become courtesy client if there are
waiters for client's locks.
. modify client_info_show to show courtesy client and seconds from
last renew.
. fix a problem with NFSv4.1 server where the it keeps returning
SEQ4_STATUS_CB_PATH_DOWN in the successful SEQUENCE reply, after
the courtesy client reconnects, causing the client to keep sending
BCTS requests to server.
v3 patch includes:
. modified posix_test_lock to check and resolve conflict locks
to handle NLM TEST and NFSv4 LOCKT requests.
. separate out fix for back channel stuck in SEQ4_STATUS_CB_PATH_DOWN.
v4 patch includes:
. rework nfsd_check_courtesy to avoid dead lock of fl_lock and client_lock
by asking the laudromat thread to destroy the courtesy client.
. handle NFSv4 share reservation conflicts with courtesy client. This
includes conflicts between access mode and deny mode and vice versa.
. drop the patch for back channel stuck in SEQ4_STATUS_CB_PATH_DOWN.
v5 patch includes:
. fix recursive locking of file_rwsem from posix_lock_file.
. retest with LOCKDEP enabled.
v6 patch includes:
. merge witn 5.15-rc7
. fix a bug in nfs4_check_deny_bmap that did not check for matched
nfs4_file before checking for access/deny conflict. This bug causes
pynfs OPEN18 to fail since the server taking too long to release
lots of un-conflict clients' state.
. enhance share reservation conflict handler to handle case where
a large number of conflict courtesy clients need to be expired.
The 1st 100 clients are expired synchronously and the rest are
expired in the background by the laundromat and NFS4ERR_DELAY
is returned to the NFS client. This is needed to prevent the
NFS client from timing out waiting got the reply.
v7 patch includes:
. Fix race condition in posix_test_lock and posix_lock_inode after
dropping spinlock.
. Enhance nfsd4_fl_expire_lock to work with with new lm_expire_lock
callback
. Always resolve share reservation conflicts asynchrously.
. Fix bug in nfs4_laundromat where spinlock is not used when
scanning cl_ownerstr_hashtbl.
. Fix bug in nfs4_laundromat where idr_get_next was called
with incorrect 'id'.
. Merge nfs4_destroy_courtesy_client into nfsd4_fl_expire_lock.
v8 patch includes:
. Fix warning in nfsd4_fl_expire_lock reported by test robot.
v9 patch includes:
. Simplify lm_expire_lock API by (1) remove the 'testonly' flag
and (2) specifying return value as true/false to indicate
whether conflict was succesfully resolved.
. Rework nfsd4_fl_expire_lock to mark client with
NFSD4_DESTROY_COURTESY_CLIENT then tell the laundromat to expire
the client in the background.
. Add a spinlock in nfs4_client to synchronize access to the
NFSD4_COURTESY_CLIENT and NFSD4_DESTROY_COURTESY_CLIENT flag to
handle race conditions when resolving lock and share reservation
conflict.
. Courtesy client that was marked as NFSD4_DESTROY_COURTESY_CLIENT
are now consisdered 'dead', waiting for the laundromat to expire
it. This client is no longer allowed to use its states if it
reconnects before the laundromat finishes expiring the client.
For v4.1 client, the detection is done in the processing of the
SEQUENCE op and returns NFS4ERR_BAD_SESSION to force the client
to re-establish new clientid and session.
For v4.0 client, the detection is done in the processing of the
RENEW and state-related ops and return NFS4ERR_EXPIRE to force
the client to re-establish new clientid.
v10 patch includes:
Resolve deadlock in v9 by avoiding getting cl_client and
cl_cs_lock together. The laundromat needs to determine whether
the expired client has any state and also has no blockers on
its locks. Both of these conditions are allowed to change after
the laundromat transits an expired client to courtesy client.
When this happens, the laundromat will detect it on the next
run and and expire the courtesy client.
Remove client persistent record before marking it as COURTESY_CLIENT
and add client persistent record before clearing the COURTESY_CLIENT
flag to allow the courtesy client to transist to normal client to
continue to use its state.
Lock/delegation/share reversation conflict with courtesy client is
resolved by marking the courtesy client as DESTROY_COURTESY_CLIENT,
effectively disable it, then allow the current request to proceed
immediately.
Courtesy client marked as DESTROY_COURTESY_CLIENT is not allowed
to reconnect to reuse itsstate. It is expired by the laundromat
asynchronously in the background.
Move processing of expired clients from nfs4_laudromat to a
separate function, nfs4_get_client_reaplist, that creates the
reaplist and also to process courtesy clients.
Update Documentation/filesystems/locking.rst to include new
lm_lock_conflict call.
Modify leases_conflict to call lm_breaker_owns_lease only if
there is real conflict. This is to allow the lock manager to
resolve the delegation conflict if possible.
v11 patch includes:
Add comment for lm_lock_conflict callback.
Replace static const courtesy_client_expiry with macro.
Remove courtesy_clnt argument from find_in_sessionid_hashtbl.
Callers use nfs4_client->cl_cs_client boolean to determined if
it's the courtesy client and take appropriate actions.
Rename NFSD4_COURTESY_CLIENT and NFSD4_DESTROY_COURTESY_CLIENT
with NFSD4_CLIENT_COURTESY and NFSD4_CLIENT_DESTROY_COURTESY.
v12 patch includes:
Remove unnecessary comment in nfs4_get_client_reaplist.
Replace nfs4_client->cl_cs_client boolean with
NFSD4_CLIENT_COURTESY_CLNT flag.
Remove courtesy_clnt argument from find_client_in_id_table and
find_clp_in_name_tree. Callers use NFSD4_CLIENT_COURTESY_CLNT to
determined if it's the courtesy client and take appropriate actions.
Add new callback, lm_lock_conflict, to lock_manager_operations to allow
the lock manager to take appropriate action to resolve the lock conflict
if possible. The callback takes 1 argument, the file_lock of the blocker
and returns true if the conflict was resolved else returns false. Note
that the lock manager has to be able to resolve the conflict while
the spinlock flc_lock is held.
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.
Signed-off-by: Dai Ngo <[email protected]>
---
Documentation/filesystems/locking.rst | 2 ++
fs/locks.c | 14 ++++++++++----
include/linux/fs.h | 8 ++++++++
3 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst
index d36fe79167b3..57ce0fbc8ab1 100644
--- a/Documentation/filesystems/locking.rst
+++ b/Documentation/filesystems/locking.rst
@@ -439,6 +439,7 @@ prototypes::
void (*lm_break)(struct file_lock *); /* break_lease callback */
int (*lm_change)(struct file_lock **, int);
bool (*lm_breaker_owns_lease)(struct file_lock *);
+ bool (*lm_lock_conflict)(struct file_lock *);
locking rules:
@@ -450,6 +451,7 @@ lm_grant: no no no
lm_break: yes no no
lm_change yes no no
lm_breaker_owns_lease: no no no
+lm_lock_conflict: no no no
====================== ============= ================= =========
buffer_head
diff --git a/fs/locks.c b/fs/locks.c
index 0fca9d680978..052b42cc7f25 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -853,10 +853,13 @@ posix_test_lock(struct file *filp, struct file_lock *fl)
spin_lock(&ctx->flc_lock);
list_for_each_entry(cfl, &ctx->flc_posix, fl_list) {
- if (posix_locks_conflict(fl, cfl)) {
- locks_copy_conflock(fl, cfl);
- goto out;
- }
+ if (!posix_locks_conflict(fl, cfl))
+ continue;
+ if (cfl->fl_lmops && cfl->fl_lmops->lm_lock_conflict &&
+ !cfl->fl_lmops->lm_lock_conflict(cfl))
+ continue;
+ locks_copy_conflock(fl, cfl);
+ goto out;
}
fl->fl_type = F_UNLCK;
out:
@@ -1059,6 +1062,9 @@ static int posix_lock_inode(struct inode *inode, struct file_lock *request,
list_for_each_entry(fl, &ctx->flc_posix, fl_list) {
if (!posix_locks_conflict(request, fl))
continue;
+ if (fl->fl_lmops && fl->fl_lmops->lm_lock_conflict &&
+ !fl->fl_lmops->lm_lock_conflict(fl))
+ continue;
if (conflock)
locks_copy_conflock(conflock, fl);
error = -EAGAIN;
diff --git a/include/linux/fs.h b/include/linux/fs.h
index bbf812ce89a8..726d0005e32f 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1068,6 +1068,14 @@ struct lock_manager_operations {
int (*lm_change)(struct file_lock *, int, struct list_head *);
void (*lm_setup)(struct file_lock *, void **);
bool (*lm_breaker_owns_lease)(struct file_lock *);
+ /*
+ * This callback function is called after a lock conflict is
+ * detected. This allows the lock manager of the lock that
+ * causes the conflict to see if the conflict can be resolved
+ * somehow. If it can then this callback returns false; the
+ * conflict was resolved, else returns true.
+ */
+ bool (*lm_lock_conflict)(struct file_lock *cfl);
};
struct lock_manager {
--
2.9.5
On Thu, 2022-02-10 at 09:21 -0500, J. Bruce Fields wrote:
> Jeff, this table of locking rules seems out of date since 6109c85037e5
> "locks: add a dedicated spinlock to protect i_flctx lists". Are any of
> those callbacks still called with the i_lock? Should that column be
> labeled "flc_lock" instead? Or is that even still useful information?
>
> --b.
Yeah, that should probably be the flc_lock. I don't think we protect
anything in the file locking code with the i_lock anymore.
>
> On Wed, Feb 09, 2022 at 08:52:07PM -0800, Dai Ngo wrote:
> > diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst
> > index d36fe79167b3..57ce0fbc8ab1 100644
> > --- a/Documentation/filesystems/locking.rst
> > +++ b/Documentation/filesystems/locking.rst
> > @@ -439,6 +439,7 @@ prototypes::
> > void (*lm_break)(struct file_lock *); /* break_lease callback */
> > int (*lm_change)(struct file_lock **, int);
> > bool (*lm_breaker_owns_lease)(struct file_lock *);
> > + bool (*lm_lock_conflict)(struct file_lock *);
> >
> > locking rules:
> >
> > @@ -450,6 +451,7 @@ lm_grant: no no no
> > lm_break: yes no no
> > lm_change yes no no
> > lm_breaker_owns_lease: no no no
> > +lm_lock_conflict: no no no
> > ====================== ============= ================= =========
>
--
Jeff Layton <[email protected]>
> On Feb 10, 2022, at 9:28 AM, J. Bruce Fields <[email protected]> wrote:
>
> On Wed, Feb 09, 2022 at 08:52:07PM -0800, Dai Ngo wrote:
>> diff --git a/include/linux/fs.h b/include/linux/fs.h
>> index bbf812ce89a8..726d0005e32f 100644
>> --- a/include/linux/fs.h
>> +++ b/include/linux/fs.h
>> @@ -1068,6 +1068,14 @@ struct lock_manager_operations {
>> int (*lm_change)(struct file_lock *, int, struct list_head *);
>> void (*lm_setup)(struct file_lock *, void **);
>> bool (*lm_breaker_owns_lease)(struct file_lock *);
>> + /*
>> + * This callback function is called after a lock conflict is
>> + * detected. This allows the lock manager of the lock that
>> + * causes the conflict to see if the conflict can be resolved
>> + * somehow. If it can then this callback returns false; the
>> + * conflict was resolved, else returns true.
>> + */
>> + bool (*lm_lock_conflict)(struct file_lock *cfl);
>> };
>
> I don't love that name. The function isn't checking for a lock
> conflict--it'd have to know *what* the lock is conflicting with. It's
> being told whether the lock is still valid.
>
> I'd prefer lm_lock_expired(), with the opposite return values.
Or even lm_lock_is_expired(). I agree that the sense of the
return values should be reversed.
The block comment does not belong in struct lock_manager_operations,
IMO.
Jeff's previous review comment was:
>> @@ -1059,6 +1062,9 @@ static int posix_lock_inode(struct inode *inode, struct file_lock *request,
>> list_for_each_entry(fl, &ctx->flc_posix, fl_list) {
>> if (!posix_locks_conflict(request, fl))
>> continue;
>> + if (fl->fl_lmops && fl->fl_lmops->lm_lock_conflict &&
>> + !fl->fl_lmops->lm_lock_conflict(fl))
>> + continue;
>
> The naming of this op is a little misleading. We already know that there
> is a lock confict in this case. The question is whether it's resolvable
> by expiring a tardy client. That said, I don't have a better name to
> suggest at the moment.
>
> A comment about what this function actually tells us would be nice here.
I agree that a comment that spells out the API contract would be
useful. But it doesn't belong in the middle of struct
lock_manager_operations, IMO.
I usually put such information in the block comment that precedes
the individual functions (nfsd4_fl_lock_conflict in this case).
Even so, the patch description has this information already.
Jeff, I think the patch description is adequate for this
purpose -- more information appears later in 3/3. What do you
think?
--
Chuck Lever
On 2/10/22 11:44 AM, Chuck Lever III wrote:
>
>> On Feb 10, 2022, at 2:41 PM, Dai Ngo <[email protected]> wrote:
>>
>>
>> On 2/10/22 6:29 AM, Jeff Layton wrote:
>>> On Thu, 2022-02-10 at 09:21 -0500, J. Bruce Fields wrote:
>>>> Jeff, this table of locking rules seems out of date since 6109c85037e5
>>>> "locks: add a dedicated spinlock to protect i_flctx lists". Are any of
>>>> those callbacks still called with the i_lock? Should that column be
>>>> labeled "flc_lock" instead? Or is that even still useful information?
>>>>
>>>> --b.
>>> Yeah, that should probably be the flc_lock. I don't think we protect
>>> anything in the file locking code with the i_lock anymore.
>> Will replace inode->i_lock with flc_lock in v13.
> To be clear, if you're fixing the documentation, that would need
> to be a clean-up patch before your 1/3. Thanks!
Got it Chuck,
Thanks,
-Dai
>
>
>> -Dai
>>
>>>> On Wed, Feb 09, 2022 at 08:52:07PM -0800, Dai Ngo wrote:
>>>>> diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst
>>>>> index d36fe79167b3..57ce0fbc8ab1 100644
>>>>> --- a/Documentation/filesystems/locking.rst
>>>>> +++ b/Documentation/filesystems/locking.rst
>>>>> @@ -439,6 +439,7 @@ prototypes::
>>>>> void (*lm_break)(struct file_lock *); /* break_lease callback */
>>>>> int (*lm_change)(struct file_lock **, int);
>>>>> bool (*lm_breaker_owns_lease)(struct file_lock *);
>>>>> + bool (*lm_lock_conflict)(struct file_lock *);
>>>>> locking rules:
>>>>> @@ -450,6 +451,7 @@ lm_grant: no no no
>>>>> lm_break: yes no no
>>>>> lm_change yes no no
>>>>> lm_breaker_owns_lease: no no no
>>>>> +lm_lock_conflict: no no no
>>>>> ====================== ============= ================= =========
> --
> Chuck Lever
>
>
>
> On Feb 10, 2022, at 2:41 PM, Dai Ngo <[email protected]> wrote:
>
>
> On 2/10/22 6:29 AM, Jeff Layton wrote:
>> On Thu, 2022-02-10 at 09:21 -0500, J. Bruce Fields wrote:
>>> Jeff, this table of locking rules seems out of date since 6109c85037e5
>>> "locks: add a dedicated spinlock to protect i_flctx lists". Are any of
>>> those callbacks still called with the i_lock? Should that column be
>>> labeled "flc_lock" instead? Or is that even still useful information?
>>>
>>> --b.
>>
>> Yeah, that should probably be the flc_lock. I don't think we protect
>> anything in the file locking code with the i_lock anymore.
>
> Will replace inode->i_lock with flc_lock in v13.
To be clear, if you're fixing the documentation, that would need
to be a clean-up patch before your 1/3. Thanks!
> -Dai
>
>>
>>> On Wed, Feb 09, 2022 at 08:52:07PM -0800, Dai Ngo wrote:
>>>> diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst
>>>> index d36fe79167b3..57ce0fbc8ab1 100644
>>>> --- a/Documentation/filesystems/locking.rst
>>>> +++ b/Documentation/filesystems/locking.rst
>>>> @@ -439,6 +439,7 @@ prototypes::
>>>> void (*lm_break)(struct file_lock *); /* break_lease callback */
>>>> int (*lm_change)(struct file_lock **, int);
>>>> bool (*lm_breaker_owns_lease)(struct file_lock *);
>>>> + bool (*lm_lock_conflict)(struct file_lock *);
>>>> locking rules:
>>>> @@ -450,6 +451,7 @@ lm_grant: no no no
>>>> lm_break: yes no no
>>>> lm_change yes no no
>>>> lm_breaker_owns_lease: no no no
>>>> +lm_lock_conflict: no no no
>>>> ====================== ============= ================= =========
--
Chuck Lever
On 2/10/22 6:28 AM, J. Bruce Fields wrote:
> On Wed, Feb 09, 2022 at 08:52:07PM -0800, Dai Ngo wrote:
>> diff --git a/include/linux/fs.h b/include/linux/fs.h
>> index bbf812ce89a8..726d0005e32f 100644
>> --- a/include/linux/fs.h
>> +++ b/include/linux/fs.h
>> @@ -1068,6 +1068,14 @@ struct lock_manager_operations {
>> int (*lm_change)(struct file_lock *, int, struct list_head *);
>> void (*lm_setup)(struct file_lock *, void **);
>> bool (*lm_breaker_owns_lease)(struct file_lock *);
>> + /*
>> + * This callback function is called after a lock conflict is
>> + * detected. This allows the lock manager of the lock that
>> + * causes the conflict to see if the conflict can be resolved
>> + * somehow. If it can then this callback returns false; the
>> + * conflict was resolved, else returns true.
>> + */
>> + bool (*lm_lock_conflict)(struct file_lock *cfl);
>> };
> I don't love that name. The function isn't checking for a lock
> conflict--it'd have to know *what* the lock is conflicting with. It's
> being told whether the lock is still valid.
>
> I'd prefer lm_lock_expired(), with the opposite return values.
Will replace lm_lock_conflict with lm_lock_expired with the opposite
return values: return true if lock was expired (conflict resolved)
else return false.
>
> (Apologies if this has already been woodshedded to death, I haven't been
> following.)
Yes, the name has been changed couples of times :-) hopefully
lm_lock_expired will stick this time.
-Dai
>
> --b.
On Thu, 2022-02-10 at 16:50 +0000, Chuck Lever III wrote:
>
> > On Feb 10, 2022, at 9:28 AM, J. Bruce Fields <[email protected]> wrote:
> >
> > On Wed, Feb 09, 2022 at 08:52:07PM -0800, Dai Ngo wrote:
> > > diff --git a/include/linux/fs.h b/include/linux/fs.h
> > > index bbf812ce89a8..726d0005e32f 100644
> > > --- a/include/linux/fs.h
> > > +++ b/include/linux/fs.h
> > > @@ -1068,6 +1068,14 @@ struct lock_manager_operations {
> > > int (*lm_change)(struct file_lock *, int, struct list_head *);
> > > void (*lm_setup)(struct file_lock *, void **);
> > > bool (*lm_breaker_owns_lease)(struct file_lock *);
> > > + /*
> > > + * This callback function is called after a lock conflict is
> > > + * detected. This allows the lock manager of the lock that
> > > + * causes the conflict to see if the conflict can be resolved
> > > + * somehow. If it can then this callback returns false; the
> > > + * conflict was resolved, else returns true.
> > > + */
> > > + bool (*lm_lock_conflict)(struct file_lock *cfl);
> > > };
> >
> > I don't love that name. The function isn't checking for a lock
> > conflict--it'd have to know *what* the lock is conflicting with. It's
> > being told whether the lock is still valid.
> >
> > I'd prefer lm_lock_expired(), with the opposite return values.
>
> Or even lm_lock_is_expired(). I agree that the sense of the
> return values should be reversed.
>
>
> The block comment does not belong in struct lock_manager_operations,
> IMO.
>
> Jeff's previous review comment was:
>
> > > @@ -1059,6 +1062,9 @@ static int posix_lock_inode(struct inode *inode, struct file_lock *request,
> > > list_for_each_entry(fl, &ctx->flc_posix, fl_list) {
> > > if (!posix_locks_conflict(request, fl))
> > > continue;
> > > + if (fl->fl_lmops && fl->fl_lmops->lm_lock_conflict &&
> > > + !fl->fl_lmops->lm_lock_conflict(fl))
> > > + continue;
> >
> > The naming of this op is a little misleading. We already know that there
> > is a lock confict in this case. The question is whether it's resolvable
> > by expiring a tardy client. That said, I don't have a better name to
> > suggest at the moment.
> >
> > A comment about what this function actually tells us would be nice here.
>
>
> I agree that a comment that spells out the API contract would be
> useful. But it doesn't belong in the middle of struct
> lock_manager_operations, IMO.
>
> I usually put such information in the block comment that precedes
> the individual functions (nfsd4_fl_lock_conflict in this case).
>
> Even so, the patch description has this information already.
> Jeff, I think the patch description is adequate for this
> purpose -- more information appears later in 3/3. What do you
> think?
>
I'd be fine with that.
--
Jeff Layton <[email protected]>
Jeff, this table of locking rules seems out of date since 6109c85037e5
"locks: add a dedicated spinlock to protect i_flctx lists". Are any of
those callbacks still called with the i_lock? Should that column be
labeled "flc_lock" instead? Or is that even still useful information?
--b.
On Wed, Feb 09, 2022 at 08:52:07PM -0800, Dai Ngo wrote:
> diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst
> index d36fe79167b3..57ce0fbc8ab1 100644
> --- a/Documentation/filesystems/locking.rst
> +++ b/Documentation/filesystems/locking.rst
> @@ -439,6 +439,7 @@ prototypes::
> void (*lm_break)(struct file_lock *); /* break_lease callback */
> int (*lm_change)(struct file_lock **, int);
> bool (*lm_breaker_owns_lease)(struct file_lock *);
> + bool (*lm_lock_conflict)(struct file_lock *);
>
> locking rules:
>
> @@ -450,6 +451,7 @@ lm_grant: no no no
> lm_break: yes no no
> lm_change yes no no
> lm_breaker_owns_lease: no no no
> +lm_lock_conflict: no no no
> ====================== ============= ================= =========
On Wed, Feb 09, 2022 at 08:52:07PM -0800, Dai Ngo wrote:
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index bbf812ce89a8..726d0005e32f 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -1068,6 +1068,14 @@ struct lock_manager_operations {
> int (*lm_change)(struct file_lock *, int, struct list_head *);
> void (*lm_setup)(struct file_lock *, void **);
> bool (*lm_breaker_owns_lease)(struct file_lock *);
> + /*
> + * This callback function is called after a lock conflict is
> + * detected. This allows the lock manager of the lock that
> + * causes the conflict to see if the conflict can be resolved
> + * somehow. If it can then this callback returns false; the
> + * conflict was resolved, else returns true.
> + */
> + bool (*lm_lock_conflict)(struct file_lock *cfl);
> };
I don't love that name. The function isn't checking for a lock
conflict--it'd have to know *what* the lock is conflicting with. It's
being told whether the lock is still valid.
I'd prefer lm_lock_expired(), with the opposite return values.
(Apologies if this has already been woodshedded to death, I haven't been
following.)
--b.
On 2/10/22 6:29 AM, Jeff Layton wrote:
> On Thu, 2022-02-10 at 09:21 -0500, J. Bruce Fields wrote:
>> Jeff, this table of locking rules seems out of date since 6109c85037e5
>> "locks: add a dedicated spinlock to protect i_flctx lists". Are any of
>> those callbacks still called with the i_lock? Should that column be
>> labeled "flc_lock" instead? Or is that even still useful information?
>>
>> --b.
>
> Yeah, that should probably be the flc_lock. I don't think we protect
> anything in the file locking code with the i_lock anymore.
Will replace inode->i_lock with flc_lock in v13.
-Dai
>
>> On Wed, Feb 09, 2022 at 08:52:07PM -0800, Dai Ngo wrote:
>>> diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst
>>> index d36fe79167b3..57ce0fbc8ab1 100644
>>> --- a/Documentation/filesystems/locking.rst
>>> +++ b/Documentation/filesystems/locking.rst
>>> @@ -439,6 +439,7 @@ prototypes::
>>> void (*lm_break)(struct file_lock *); /* break_lease callback */
>>> int (*lm_change)(struct file_lock **, int);
>>> bool (*lm_breaker_owns_lease)(struct file_lock *);
>>> + bool (*lm_lock_conflict)(struct file_lock *);
>>>
>>> locking rules:
>>>
>>> @@ -450,6 +451,7 @@ lm_grant: no no no
>>> lm_break: yes no no
>>> lm_change yes no no
>>> lm_breaker_owns_lease: no no no
>>> +lm_lock_conflict: no no no
>>> ====================== ============= ================= =========