On Wed, Aug 23, 2017 at 12:26:52PM +0200, Peter Zijlstra wrote: > 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.
I want to try it.
