lkml.org 
[lkml]   [2017]   [Aug]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 4/4] lockdep: Fix workqueue crossrelease annotation
    On Wed, Aug 23, 2017 at 01:58:47PM +0200, Peter Zijlstra wrote:
    > 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.

    Eventually, you pushed this patch to tip tree without any comment.

    I don't really understand you.

    How does a maintainer choose a very work-around method and avoid
    problems rather than fix a root cause? I am very disappointed.

    But, I have nothing to do against your will.

    \
     
     \ /
      Last update: 2017-08-29 08:47    [W:2.505 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site