On Tue, Sep 05, 2017 at 11:29:13AM +0900, Byungchul Park wrote: > From the point of view of crossrelease, we can never be aware of the > release context in advance, until we get to the lock_release(). > However, this way we cannot report deadlocks occured at the time. > > Sometimes, we want to report that kind of problems, taking a risk > generating false dependencies e.g. lock_acquire()s in workqueue code, > which inevitably generate false ones with all acquisitions in works. > > It would be better to provide another primitive, lock_acquire_might() > for that purpose so that lockdep internal can be aware of what users > expect and get chances to enhance to avoid false ones. > > The primitive should: > > 1. work as if it's trylock, since links between lock_acquire_might() > and later ones are only meaningful. Remind this should be used to > do what crossrelease commit does, in advance. > > 2. make acquisitions by lock_acquire_might() ignored on the commit. >
Shees, talk about ugly... Also might-lock has a different meaning.
