Johannes Berg wrote: >> And as for how to solve it: I think alias analysis might work. > > How would I do that? Real compilers have alias analysis code, which builds up information on which variables and expressions may/must alias each other. I think that that alias information might prove sufficient to compare contexts: if two contexts alias each other then they represent the same context. Basic type-based alias analysis should prove sufficient to handle cases like: spinlock_t s; struct something_with_a_spinlock st; spin_lock(&st.s); spin_unlock(&st.s); /* contexts match */ spin_lock(&st.s); spin_unlock(&s); /* warn */ Flow-based alias analysis may also handle cases like you mentioned, where you assign a lock to a variable and then use it through that variable. Alternatively, some simple dataflow analysis and symbolic execution might let you figure out the lock a variable points to in most cases. As a simpler solution, you could just do what lockdep does: make assumptions that handle the common cases, and allow explicit overrides for the uncommon cases. I suspect that most code does not assign a lock to a variable and use the lock through that variable. In particular, you could perhaps make the assumption that any expression which resolves to the "foo" field of a "struct bar" represents the same context, rather than attempting to distinguish between them. - Josh Triplett
Attachment:
signature.asc
Description: OpenPGP digital signature
