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.0609141754480.2721@twin.jikos.cz>
Date:	Thu, 14 Sep 2006 18:00:21 +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>
Subject: Re: [PATCH 0/3] Synaptics - fix lockdep warnings

On Thu, 14 Sep 2006, Dmitry Torokhov wrote:

> Not yet ;) Is there a way to hide the depth in the spinlock/mutex 
> structure itself so that initialization code could do 
> spin_lock_init_nested() and spare the rest of the code from that 
> knowledge?

(shortened CC list a bit)

In fact I am not sure what you mean. On every lock and unlock operation, 
in case of recursive locking (which our case is), you have to provide 
class identifier, which is used to distinguish if the lock is of the same 
instance, or a different one (deeper or higher in the locking hierarchy). 
There is no way how spin_lock() or mutex_lock() can know this 
"automatically", you always have to provide the nesting level from 
outside, as it depends on the ordering hierarchy, which locking primitives 
are totally unaware of.

Or did I misunderstand you?

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/