Messages in this thread | | | Date | Tue, 22 Mar 2011 15:02:01 -0700 | From | David Collins <> | Subject | Deadlock scenario in regulator core |
| |
Hi Liam and Mark,
I was analyzing the mutex lock usage in drivers/regulator/core.c and found at least one way to reach deadlock: regulator_enable is called for a regulator at the same time that regulator_disable is called for that regulator's supply. Consider this simple example. There are two regulators: S1 and L2, as well as two consumers: A and B. They are connected as follows:
S1 --> L2 --> B | |--> A
Assume that A has already called regulator_enable for S1 some time in the past.
Consumer A thread execution: regulator_disable(S1) mutex_lock(S1) _regulator_disable(S1) _notifier_call_chain(S1) mutex_lock(L2)
Consumer B thread execution: regulator_enable(L2) mutex_lock(L2) _regulator_enable(L2) mutex_lock(S1)
The locks for S1 and L2 are taken in opposite orders in the two threads; therefore, it is possible to achieve deadlock. I am not sure about the best way to resolve this situation. Is there a correctness requirement that regulator_enable holds the child regulator's lock when it attempts to enable the parent regulator? Likewise, is the lock around _notifier_call_chain required?
Thanks, David Collins
-- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
| |