On Wed, Aug 23, 2017 at 01:58:47PM +0200, Peter Zijlstra wrote: > The new completion/crossrelease annotations interact unfavourable with > the extant flush_work()/flush_workqueue() annotations. > > The problem is that when a single work class does: > > wait_for_completion(&C) > > and > > complete(&C) > > in different executions, we'll build dependencies like: > > lock_map_acquire(W) > complete_acquire(C) > > and > > lock_map_acquire(W) > complete_release(C) > > which results in the dependency chain: W->C->W, which lockdep thinks > spells deadlock, even though there is no deadlock potential since > works are ran concurrently. > > One possibility would be to change the work 'lock' to recursive-read, > but that would mean hitting a lockdep limitation on recursive locks. > Also, unconditinoally switching to recursive-read here would fail to > detect the actual deadlock on single-threaded workqueues, which do > have a problem with this. > > For now, forcefully disregard these locks for crossrelease.
Eventually, you pushed this patch to tip tree without any comment. I don't really understand you. How does a maintainer choose a very work-around method and avoid problems rather than fix a root cause? I am very disappointed. But, I have nothing to do against your will.
