linux-kernel - Re: [PATCH 0/3] Synaptics

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20060914195641.GA5812@elte.hu>
Date:	Thu, 14 Sep 2006 21:56:41 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Jiri Kosina <jikos@...os.cz>, lkml <linux-kernel@...r.kernel.org>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [PATCH 0/3] Synaptics - fix lockdep warnings

* Dmitry Torokhov <dmitry.torokhov@...il.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/