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.
