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: <Pine.LNX.4.64.0609142037110.2721@twin.jikos.cz>
Date:	Thu, 14 Sep 2006 20:48:16 +0200 (CEST)
From:	Jiri Kosina <jikos@...os.cz>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
cc:	lkml <linux-kernel@...r.kernel.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH 0/3] Synaptics - fix lockdep warnings

On Thu, 14 Sep 2006, Dmitry Torokhov wrote:

> Well, we do not really care about nestiness do we? What we trying to 
> achieve is to teach lockdep that 2 locks while appear as the lame lock 
> in fact are different and protect 2 different structures. Ideally 
> lockdep should track every lock individually (based for example on its 
> address) but that would be too taxing so we need to help it. In your 
> implementation you embed this data into structure/code using lock, but 
> this information could be instilled into the lock itself upon 
> initialization and spin_[un]lock() implementation could be taught to use 
> this data thus making specialized spin_[un]lock*_nested() functions 
> unnecessary.

Hi Dmitry,

IMHO this is exactly what the nested locking primitives were introduced in 
lockdep for (we even have natural hierarchy here), so I am not sure if 
this is compliant with lockdep design. I definitely could do a patch that 
would introduce {spin,mutex..}_lock_init_subclass(), which would 
initialize the lock together with defining it's 'class', so that it could 
be distinguishable from any other lock of the same type during proving of 
correctness ... but this is a step towards distinguishing every single 
lock from all others (even of a same type), which I am not sure is the 
right direction.

I added Ingo to CC.

Thanks,

-- 
JiKos.
-
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/