linux-kernel - Re: Deadlock scenario in regulator core

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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 23 Mar 2011 00:11:28 +0000
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	David Collins <collinsd@...eaurora.org>,
	Liam Girdwood <lrg@...mlogic.co.uk>,
	linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: Deadlock scenario in regulator core

On Tue, Mar 22, 2011 at 08:07:36PM -0400, Steven Rostedt wrote:

> Note, I do not know this code well enough to say. I'm assuming that an
> rdevA on a rdevB->supply_list never has rdevB on its own
> rdevA->supply_list.

Correct.

> If this is the case, and that you only ever have a lock nesting of one,
> then sure, use the SINGLE_DEPTH_NESTING.

It'd be good if someone could update the documentation in the mutex code
so the usage were clear here - I don't want to see the locking become
any more complicated, especially not for relatively infrequently used
things like supplies.

Though we may be able to deal with this by simplifying the
implementation of supplies anyway.
--
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/