On Tue, Mar 22, 2011 at 03:02:01PM -0700, David Collins wrote: > 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? I'm curious, if you had enabled lockdep, do you get a warning? If not, why not? Thanks, -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
