Messages in this thread | | | Date | Wed, 15 Feb 2023 11:45:03 +0100 | From | Peter Zijlstra <> | Subject | Re: [PATCH RFC] drivers/core: Replace lockdep_set_novalidate_class() with unique class keys |
| |
On Tue, Feb 14, 2023 at 08:22:28AM -0800, Boqun Feng wrote:
> Ah, right, I was missing the fact that it works with 2 classes... > > But I think with only one class, the nest_lock() still works, right? > In other words, if P and Cn are the same lock class in your example.
I don't think so, but I don't think I've carefully considered that case.
> Also seems I gave a wrong answer to Alan, just to clarify, the following > is not a deadlock to lockdep: > > T1: > mutex_lock(P) > mutex_lock_next_lock(C1, P) > mutex_lock_next_lock(C2, P) > mutex_lock(B) > > T2: > mutex_lock(P) > mutex_lock(B) > mutex_lock_next_lock(C1, P) > mutex_lock_next_lock(C2, P) >
This should in fact complain about a CB-BC deadlock, (but I've not tested it, just going on memories of how I implemented it).
> Because of any pair of > > mutex_lock(L); > ... // other locks maybe > mutex_lock_nest_lock(M, L); > > lockdep will not add M into the dependency graph, since it's nested and > should be serialized by L.
We do enter M into the dependency graph, but instead ignore M-M recursion. Specifically so that we might catch the above deadlock vs B.
| |