Quoting Daniel Vetter (2020-06-04 10:21:46)
On Thu, Jun 4, 2020 at 10:57 AM Thomas Hellström (Intel) thomas_os@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