lkml.org 
[lkml]   [2006]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2006-09-14 22:07    [W:0.124 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site