• Peter Zijlstra's avatar
    locking/lockdep: Fix workqueue crossrelease annotation · e6f3faa7
    Peter Zijlstra authored
    
    
    The new completion/crossrelease annotations interact unfavourable with
    the extant flush_work()/flush_workqueue() annotations.
    
    The problem is that when a single work class does:
    
      wait_for_completion(&C)
    
    and
    
      complete(&C)
    
    in different executions, we'll build dependencies like:
    
      lock_map_acquire(W)
      complete_acquire(C)
    
    and
    
      lock_map_acquire(W)
      complete_release(C)
    
    which results in the dependency chain: W->C->W, which lockdep thinks
    spells deadlock, even though there is no deadlock potential since
    works are ran concurrently.
    
    One possibility would be to change the work 'lock' to recursive-read,
    but that would mean hitting a lockdep limitation on recursive locks.
    Also, unconditinoally switching to recursive-read here would fail to
    detect the actual deadlock on single-threaded workqueues, which do
    have a problem with this.
    
    For now, forcefully disregard these locks for crossrelease.
    Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
    Acked-by: default avatarTejun Heo <tj@kernel.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: boqun.feng@gmail.com
    Cc: byungchul.park@lge.com
    Cc: david@fromorbit.com
    Cc: johannes@sipsolutions.net
    Cc: oleg@redhat.com
    Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
    e6f3faa7
workqueue.c 157 KB