linux-kernel - Re: lockdep problem conversion semaphore->mutex (dev->sem)

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] [day] [month] [year] [list]

Message-ID: <475B2169.6030709@gmail.com>
Date:	Sat, 08 Dec 2007 23:57:45 +0100
From:	Jarek Poplawski <jarkao2@...il.com>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	Remy Bohmer <linux@...mer.net>, Daniel Walker <dwalker@...sta.com>,
	Ingo Molnar <mingo@...e.hu>,
	Steven Rostedt <rostedt@...dmis.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Dave Chinner <dgc@....com>
Subject: Re: lockdep problem conversion semaphore->mutex (dev->sem)

Peter Zijlstra wrote, On 12/08/2007 09:50 PM:

> On Sat, 2007-12-08 at 21:33 +0100, Remy Bohmer wrote:
> 
>> Which problems? I did not see any special things, it looked rather
>> straight forward. What have I overlooked?
> 
> On suspend it locks the whole device tree, this means it has 'unbounded'
> nesting and holds an 'unbounded' number of locks. Neither things are
> easy to annotate (remember that mutex_lock_nested can handle up to 8
> nestings and current->held_locks has a max of 30).
> 
> In fact, converting this will be the hardest part, it would require
> reworking the locking and introduction of a hard limit on the device
> tree depth - this might upset some people, but I suspect that 16 or 24
> should be deep enough for pretty much anything. Of course, if people
> prove me wrong, I'll have to reconsider. The up-side of the locking
> scheme I'm thinking of will be that locking the whole tree will only
> take 'depth' number of opterations vs the total number of tree elements.

Of course, I don't know the problem enough, and would be glad if somebody
give me a hint, but I wonder why so deep nesting with lockdep's modification
is necessary here? Does buses have parent buses and so on x8? Why isn't
here considered creating of different lockdep classes according to types
of buses and devices "the usual way"? This way seems to be quite easy in
later debugging.

Regards,
Jarek P.
--
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/