On Wed, Aug 23, 2017 at 11:43:23AM +0900, Byungchul Park wrote: > On Tue, Aug 22, 2017 at 03:49:22PM +0200, Peter Zijlstra wrote:
> > So I think we'll end up hitting a lockdep deficiency and not trigger the > > splat on flush_work(), see also: > > > > https://lwn.net/Articles/332801/ > > > > lock_map_acquire_read() is a read-recursive and will not in fact create > > any dependencies because of this issue. > > > > In specific, check_prev_add() has: > > > > if (next->read == 2 || prev->read == 2) > > return 1; > > > > This means that for: > > > > lock_map_acquire_read(W)(2) > > down_write(A) (0) > > > > down_write(A) (0) > > wait_for_completion(C) (0) > > > > lock_map_acquire_read(W)(2) > > complete(C) (0) > > > > All the (2) effectively go away and 'solve' our current issue, but: > > > > lock_map_acquire_read(W)(2) > > mutex_lock(A) (0) > > > > mutex_lock(A) (0) > > lock_map_acquire(W) (0) > > > > as per flush_work() will not in fact trigger anymore either. > > It should be triggered. Lockdep code should be fixed so that it does. Yeah, its just something we never got around to. Once every so often I get reminded of it, like now. But then it sits on the todo list and never quite happens.
