Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1722966

Re: [RFC] workqueue: remove manual lockdep uses to detect deadlocks

From Byungchul Park <byungchul.park@lge.com>
Newsgroups linux.kernel
Subject Re: [RFC] workqueue: remove manual lockdep uses to detect deadlocks
Date 2017-08-30 04:00 +0200
Message-ID <uk0sp-1Us-3@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> <ujTTY-6ib-23@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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.

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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