Quoting Daniel Vetter (2020-06-04 10:21:46) > On Thu, Jun 4, 2020 at 10:57 AM Thomas Hellström (Intel) > <thomas...@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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel