Messages in this thread | | | Date | Wed, 30 Aug 2017 10:53:39 +0900 | From | Byungchul Park <> | Subject | Re: [RFC] workqueue: remove manual lockdep uses to detect deadlocks |
| |
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.
| |