On Tue, Aug 29, 2017 at 08:57:27PM +0200, Peter Zijlstra wrote: > On Sat, Aug 26, 2017 at 12:49:26AM +0900, Byungchul Park wrote: > > > However, how would it distinguish things like flushing another work > > > > I think it must be distinguished with what it actually waits for, e.i. > > completion > > variables instead of work or wq. I will make it next week and let you know. > > So no. The existing annotations are strictly better than relying on > cross-release.
Thank you for exaplanation but, as I already said, this is why I said "I don't think it's the same level currently. But, I can make it with some modification." to TJ: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1479560.html And also I mentioned we might need the current code inevitably but, the existing annotations are never good and why here: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1480173.html > As you know the problem with cross-release is that it is timing > dependent. You need to actually observe the problematic sequence before > it can warn, and only the whole instance->class mapping saves us from > actually hitting the deadlock. Of course. > The same would be true for using cross-release for workqueues as well, > something like: > > W: > mutex_lock(A) > > mutex_lock(A) > flush_work(W) > > would go unreported whereas the current workqueue annotation will > generate a splat. Of course. That's why I said we need to work on it. But it should be modified so that the wq code becomes more clear instead of abusing weird acquire()s.
