linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Antti Palosaari <crope@iki.fi>
To: Mark Brown <broonie@kernel.org>
Cc: linux-media@vger.kernel.org, Lars-Peter Clausen <lars@metafoo.de>
Subject: Re: [PATCHv2 1/2] regmap: add configurable lock class key for lockdep
Date: Mon, 22 Dec 2014 14:55:23 +0200	[thread overview]
Message-ID: <549814BB.3040808@iki.fi> (raw)
In-Reply-To: <20141222124411.GK17800@sirena.org.uk>

On 12/22/2014 02:44 PM, Mark Brown wrote:
> On Sun, Dec 21, 2014 at 12:34:51AM +0200, Antti Palosaari wrote:
>> Lockdep validator complains recursive locking and deadlock when two
>> different regmap instances are called in a nested order, as regmap
>> groups locks by default. That happens easily for example when both
>
> I don't know what "regmap groups locks by default" means.

It means, that lockdep does not track individual lock instances, but 
group of lock instances, which are called classes. In that case, there 
is 2 regmap mutexes, one in a I2C client driver and another in I2C 
adapter driver. Even those are different locks (mutexes) in a different 
driver, lockdep refers those as a single and same lock and due to that 
it thinks there is recursive lock => deadlock.

from: Documentation/locking/lockdep-design.txt

Lock-class
----------

The basic object the validator operates upon is a 'class' of locks.

A class of locks is a group of locks that are logically the same with
respect to locking rules, even if the locks may have multiple (possibly
tens of thousands of) instantiations. For example a lock in the inode
struct is one class, while each inode has its own instantiation of that
lock class.

The validator tracks the 'state' of lock-classes, and it tracks
dependencies between different lock-classes. The validator maintains a
rolling proof that the state and the dependencies are correct.

Unlike an lock instantiation, the lock-class itself never goes away: when
a lock-class is used for the first time after bootup it gets registered,
and all subsequent uses of that lock-class will be attached to this
lock-class.


>> I2C client and I2C adapter are using regmap. As a solution, add
>> configuration option to pass custom lock class key for lockdep
>> validator.
>
> Why is this configurable, how would a device know if the system it is in
> needs a custom locking class and can safely use one?

If RegMap instance is bus master, eg. I2C adapter, then you should 
define own custom key. If you don't define own key and there will be 
slave on that bus which uses RegMap too, there will be recursive locking 
from a lockdep point of view.


regards
Antti

-- 
http://palosaari.fi/

  reply	other threads:[~2014-12-22 12:55 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-20 22:34 [PATCHv2 1/2] regmap: add configurable lock class key for lockdep Antti Palosaari
2014-12-20 22:34 ` [PATCHv2 2/2] rtl2832: use custom lock class key for regmap Antti Palosaari
2014-12-22 12:44 ` [PATCHv2 1/2] regmap: add configurable lock class key for lockdep Mark Brown
2014-12-22 12:55   ` Antti Palosaari [this message]
2014-12-22 13:31     ` Mark Brown
2014-12-22 13:53       ` Antti Palosaari
2014-12-22 15:05         ` Mark Brown
2015-02-02 14:31           ` Mauro Carvalho Chehab
2015-02-03 12:06             ` Mark Brown
2014-12-22 14:23       ` Mauro Carvalho Chehab
2014-12-22 15:32         ` Mark Brown
2014-12-22 20:06 ` 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=549814BB.3040808@iki.fi \
    --to=crope@iki.fi \
    --cc=broonie@kernel.org \
    --cc=lars@metafoo.de \
    --cc=linux-media@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).