From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Rostedt Subject: Re: Deadlock scenario in regulator core Date: Tue, 22 Mar 2011 18:37:02 -0400 Message-ID: <20110322223702.GO14675@home.goodmis.org> References: <4D891C59.1030009@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from hrndva-omtalb.mail.rr.com ([71.74.56.125]:52415 "EHLO hrndva-omtalb.mail.rr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751939Ab1CVWhF (ORCPT ); Tue, 22 Mar 2011 18:37:05 -0400 Content-Disposition: inline In-Reply-To: <4D891C59.1030009@codeaurora.org> Sender: linux-arm-msm-owner@vger.kernel.org List-Id: linux-arm-msm@vger.kernel.org To: David Collins Cc: Liam Girdwood , Mark Brown , linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org 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