On 3/18/20 1:49 PM, Darrick J. Wong wrote: >>> I think that when we query writelocked lock for being shared having >>> 'no' for an answer may not be expected...or at least this is how I >>> read the code. >> This might be ok, because >> a) it is technically correct (is it shared? /no/ it is exclusive), and >> b) in the XFS code today we never call: >> >> xfs_isilocked(ip, XFS_ILOCK_SHARED); >> >> it's always: >> >> xfs_isilocked(ip, XFS_ILOCK_SHARED | XFS_ILOCK_EXCL); >> >> So I think that if we document the behavior clearly, the truth table above >> would be ok. >> >> Thoughts? > No, Pavel's right, I got the pseudocode wrong, because holding a write > lock means you also hold the read lock. > > if !debug_locks: > return rwsem_is_locked(rwsem) > > if shared: > r = -1 > else: > r = 0 > return lockdep_is_held_type(rwsem, r) I think it comes down to semantics, and either way is fine as long as we don't change the behavior of existing callers, and document exactly what the islocked function does now. -Eric
