On Thu, Aug 17, 2017 at 05:46:12PM +0800, Boqun Feng wrote: > With CROSSRELEASE feature introduced, such a potential deadlock is > reported: > > > Worker A : acquired of wfc.work -> wait for cpu_hotplug_lock to be released > > Task B : acquired of cpu_hotplug_lock -> wait for lock#3 to be released > > Task C : acquired of lock#3 -> wait for completion of barr->done > > (Task C is in lru_add_drain_all_cpuslocked()) > > Worker D : wait for wfc.work to be released -> will complete barr->done > > However, given this very case, such a dead lock could not happen because > Task C's barr->done and Worker D's barr->done can not be the same > instance. So this is a false positive. > > The reason of this false positive is we initialize all wq_barrier::done > at insert_wq_barrier() via init_completion(), which makes them belong to > the same lock class, therefore, impossible circles are reported. > > To fix this, explicitly initialize the lockdep map for wq_barrier::done > in insert_wq_barrier(), so that the lock class key of wq_barrier::done > is a subkey of the corresponding work_struct, as a result we won't build > a dependency between a wq_barrier with a unrelated work, and we can > differ wq barriers based on the related works, so the false positive > above is avoided. > > Also define the empty lockdep_init_map_crosslock() for !CROSSRELEASE > to make the code simple and away from unnecessary #ifdefs. > > Reported-by: Ingo Molnar <[email protected]> > Signed-off-by: Boqun Feng <[email protected]> > Cc: Byungchul Park <[email protected]>
Acked-by: Tejun Heo <[email protected]> Thanks. -- tejun
