Re: [PATCH 0/3] Synaptics - fix lockdep warnings

[Ingo Molnar <mingo@elte.hu>]

* Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:

> I think it is - as far as I understand the reason for not tracking 
> every lock individually is just that it is too expensive to do by 
> default.

that is not at all the reason! The reason is that we want to find 
deadlocks _as early as mathematically possible_ (in a running system, 
where locking patterns are observed). That is we want to gather the 
_most generic_ locking rules.

For example, if there are lock_1A, lock_1B of the same lock class, and 
lock_2A and lock_2B of another lock class. If we observed the following 
usage patterns:

	acquire(lock_1A);
	acquire(lock_2A);
	release(lock_2A);
	release(lock_1A);

and another piece of kernel code did:

	acquire(lock_2B);
	acquire(lock_1B);
	release(lock_1B);
	release(lock_1B);

with per-lock rules there's no problem detected, because the 4 locks are 
independent and we only observed a 1A->2A and a 2B->1B dependency.

But with per-class rule gather we'd observe the 1->2 and the 2->1 
dependency, and we'd warn that there's a deadlock.

So we want to create as broad, as generic rules as possible, to catch 
deadlocks as soon as it's _provable_ that they could occur. In that 
sense lockdep wants to have a '100% proof' of correctness: the first 
time a bad even happens we flag it.

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/