[Intel-gfx] [PATCH 03/18] dma-fence: basic lockdep annotations

[Chris Wilson]

Quoting Daniel Vetter (2020-06-04 10:21:46)
> On Thu, Jun 4, 2020 at 10:57 AM Thomas Hellström (Intel)
> <thomas_os at shipmail.org> wrote:
> >
> >
> > On 6/4/20 10:12 AM, Daniel Vetter wrote:
> > ...
> > > Thread A:
> > >
> > >       mutex_lock(A);
> > >       mutex_unlock(A);
> > >
> > >       dma_fence_signal();
> > >
> > > Thread B:
> > >
> > >       mutex_lock(A);
> > >       dma_fence_wait();
> > >       mutex_unlock(A);
> > >
> > > Thread B is blocked on A signalling the fence, but A never gets around
> > > to that because it cannot acquire the lock A.
> > >
> > > Note that dma_fence_wait() is allowed to be nested within
> > > dma_fence_begin/end_signalling sections. To allow this to happen the
> > > read lock needs to be upgraded to a write lock, which means that any
> > > other lock is acquired between the dma_fence_begin_signalling() call and
> > > the call to dma_fence_wait(), and still held, this will result in an
> > > immediate lockdep complaint. The only other option would be to not
> > > annotate such calls, defeating the point. Therefore these annotations
> > > cannot be sprinkled over the code entirely mindless to avoid false
> > > positives.
> >
> > Just realized, isn't that example actually a true positive, or at least
> > a great candidate for a true positive, since if another thread reenters
> > that signaling path, it will block on that mutex, and the fence would
> > never be signaled unless there is another signaling path?
> 
> Not sure I understand fully, but I think the answer is "it's complicated".

See cd8084f91c02 ("locking/lockdep: Apply crossrelease to completions")

dma_fence usage here is nothing but another name for a completion.
-Chris