All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Collins <collinsd@codeaurora.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Liam Girdwood <lrg@slimlogic.co.uk>,
	Mark Brown <broonie@opensource.wolfsonmicro.com>,
	linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: Deadlock scenario in regulator core
Date: Tue, 22 Mar 2011 16:08:58 -0700	[thread overview]
Message-ID: <4D892C0A.1090606@codeaurora.org> (raw)
In-Reply-To: <20110322223702.GO14675@home.goodmis.org>

On 03/22/2011 03:37 PM, Steven Rostedt wrote:
> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

I have tried running with lockdep enabled.  It does not produce a warning
about possible deadlock from locks being taken in opposite orders in two
threads.  I assume that this is because it can only keep track of locks
taken in the current stack backtrace.

It does produce a warning for regulator_disable by itself though on a
regulator with a non-empty supply_list:

 =============================================
 [ INFO: possible recursive locking detected ]
 2.6.38-rc7+ #231
 ---------------------------------------------
 sh/25 is trying to acquire lock:
  (&rdev->mutex){+.+...}, at: [<c0137ae4>] _notifier_call_chain+0x28/0x6c

 but task is already holding lock:
  (&rdev->mutex){+.+...}, at: [<c0138410>] regulator_disable+0x24/0x74

The locks that it is noting are different; one is for the parent regulator
and the other is for the child regulator. Any thoughts?

Thanks,
David

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

  reply	other threads:[~2011-03-22 23:08 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-22 22:02 Deadlock scenario in regulator core David Collins
2011-03-22 22:31 ` Mark Brown
2011-03-22 23:30   ` David Collins
2011-03-22 23:45     ` Mark Brown
2011-03-22 22:37 ` Steven Rostedt
2011-03-22 23:08   ` David Collins [this message]
2011-03-22 23:19     ` Steven Rostedt
2011-03-22 23:41       ` David Collins
2011-03-23  0:07         ` Steven Rostedt
2011-03-23  0:11           ` Mark Brown
2011-03-25 10:55           ` Peter Zijlstra
2011-03-23  0:01       ` Mark Brown
2011-03-23  0:38         ` Steven Rostedt
2011-03-23 10:42           ` Mark Brown
2011-03-25 10:59             ` Peter Zijlstra
2011-03-22 22:43 ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D892C0A.1090606@codeaurora.org \
    --to=collinsd@codeaurora.org \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lrg@slimlogic.co.uk \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.