On Fri, Aug 10, 2018 at 09:40:35AM +1000, NeilBrown wrote: > caller_fl is first and sys_fl is second. > > if sys_fl, the second, is a read lock, and caller_fl, the first, is a > write lock, they clearly conflict but any other lock that conflict > with caller_fl (The write lock) would *not* necessarily conflict with > the read lock. So this situation is *not* FL_TRANSITIVE_CONFLICT. > > locks_conflict() only returns FL_TRANSITIVE_CONFLICT when sys_fl (the > second) is a write lock, which it isn't in this case. So I think that > this case is handled correctly. > posix_locks_conflict() will return FL_CONFLICT, but not > FL_TRANSITIVE_CONFLICT. > > Have I convinced you, or have I missed your point? Eh, I was just confused. And now I'm tempted to blame you for confusing me, but maybe that's just my ego going defensive. (My bruised ego suggests leaving locks_conflict and its callers alone, and having an entirely separate function that checks this when we need it.) --b.
