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/
next prev parent 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).