Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1722698
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC] workqueue: remove manual lockdep uses to detect deadlocks |
| Date | 2017-08-29 21:00 +0200 |
| Message-ID | <ujTTY-6ib-23@gated-at.bofh.it> (permalink) |
| References | <uiits-1L5-25@gated-at.bofh.it> <uin06-4CU-9@gated-at.bofh.it> <uip1T-5RV-1@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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. 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. Cross-release can result in deadlocks without warnings. If you were to run: mutex_lock(A); mutex_lock(A); complete(C); wait_for_completion(C); You'd deadlock without issue. Only if we observe this: mutex_lock(A); wait_for_completion(C); mutex_lock(A); complete(C); Where we acquire A after wait_for_completion() but before complete() will we observe the deadlock. 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. This does not mean cross-release isn't worth it, its better than nothing, but its strictly weaker than traditional annotations. So where a traditional annotation is possible, we should use them.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [RFC] workqueue: remove manual lockdep uses to detect deadlocks Tejun Heo <tj@kernel.org> - 2017-08-25 15:40 +0200
Re: [RFC] workqueue: remove manual lockdep uses to detect deadlocks Byungchul Park <max.byungchul.park@gmail.com> - 2017-08-25 17:50 +0200
Re: [RFC] workqueue: remove manual lockdep uses to detect deadlocks Peter Zijlstra <peterz@infradead.org> - 2017-08-29 21:00 +0200
Re: [RFC] workqueue: remove manual lockdep uses to detect deadlocks Byungchul Park <byungchul.park@lge.com> - 2017-08-30 04:00 +0200
Re: [RFC] workqueue: remove manual lockdep uses to detect deadlocks Peter Zijlstra <peterz@infradead.org> - 2017-08-30 08:30 +0200
Re: [RFC] workqueue: remove manual lockdep uses to detect deadlocks Byungchul Park <byungchul.park@lge.com> - 2017-08-29 02:30 +0200
csiph-web