Re: [PATCH 3/3] lockdep: Remove unnecessary acquisitions wrt workqueue flush

[Byungchul Park]

On Tue, Sep 05, 2017 at 04:36:18PM +0900, ïÚïÃ/ïïïÓïïïïï/SW Platform(ïï)AOTïï(byungchul.park@xxxxxxx) wrote:
> > -----Original Message-----
> > From: Peter Zijlstra [mailto:peterz@xxxxxxxxxxxxx]
> > Sent: Tuesday, September 05, 2017 4:26 PM
> > To: Byungchul Park
> > Cc: tj@xxxxxxxxxx; johannes.berg@xxxxxxxxx; mingo@xxxxxxxxxx;
> > tglx@xxxxxxxxxxxxx; oleg@xxxxxxxxxx; david@xxxxxxxxxxxxx; linux-
> > kernel@xxxxxxxxxxxxxxx; kernel-team@xxxxxxx
> > Subject: Re: [PATCH 3/3] lockdep: Remove unnecessary acquisitions wrt
> > workqueue flush
> > 
> > On Tue, Sep 05, 2017 at 11:29:14AM +0900, Byungchul Park wrote:
> > 
> > > Also, lock_map_acquire() in process_one_work() is too strong for that
> > > purpose. lock_map_acquire_might() is enough. Replaced it.
> > 
> > NAK!! traditional annotations are superior to cross-release. They are not
> > timing dependent.
> 
> You seem to mis-understand this. This also make them timing independent.
> I also agree that we need timing independent report in workqueue code.
> That's actually why I propose this patch.
> 
> I just tried to do it in a right way.

Adding insufficient comments seems to lead to mis-understand what
lock_map_acquire_might() does. I will enhance it. (And might need to
rename it to a better one as you pointed out in another reply.)

I introduced it to give a hint to lockdep that "It's not actual
acquisition but pseudo one, informing that the context might be the
commit context" so that lockdep can report warnings at the real time
as current code does.

This hint is useful to report run time deadlocks, timing independently,
but not need to be considered on commit. And the hint should be relaxed
as far as possible. I just did that.