Messages in this thread | ![/](/images/icornerl.gif) | | Date | Thu, 14 Sep 2006 21:56:41 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH 0/3] Synaptics - fix lockdep warnings |
| |
* 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/
| ![\](/images/icornerr.gif) |