From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Tomasz Figa <t.figa@samsung.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Tomasz Stanisławski" <t.stanislaws@samsung.com>,
"linux-samsung-soc@vger.kernel.org"
<linux-samsung-soc@vger.kernel.org>,
"Mike Turquette" <mturquette@linaro.org>,
"Wolfram Sang" <wsa@the-dreams.de>,
"Andrzej Hajda" <a.hajda@samsung.com>,
"Mark Brown" <broonie@kernel.org>,
"Lee Jones" <lee.jones@linaro.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: ABBA deadlock in Common Clock Framework
Date: Wed, 2 Jul 2014 12:23:14 +0100 [thread overview]
Message-ID: <20140702112314.GI32514@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <53B3E5F8.80501@samsung.com>
On Wed, Jul 02, 2014 at 12:59:04PM +0200, Tomasz Figa wrote:
> Hi All,
>
> While testing linux-next (next-20140625) on Exynos4412-based TRATS2
> board, from time to time I hit a deadlock between clk_disable_unused()
> of Common Clock Framework and parallel clk_prepare() from s3c24xx-i2c
> driver.
This is pretty sad. The Linux kernel has quite a range of truely excellent
debugging tools which can be built in, but it seems many developers don't
enable them. The important one here is lockdep (which I notice isn't on
in your kernel.)
Lockdep is a static lock checker - it tracks the dependencies and contexts
between various locks and can report whether deadlock is possible without
having to run into the deadlock. It is /highly/ recommended that all
developers should run their changes through a kernel with this feature
on before submitting them upstream - see Documentation/SubmitChecklist
point 15.
It can really catch these things before the patch is even submitted...
The recommendation is that if you're doing kernel development, always
have lockdep enabled. If you want to do performance checking, then
obviously it has an impact on that, so turn it off to do that, but
remember to turn it back on before you do further development.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
next prev parent reply other threads:[~2014-07-02 11:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-02 10:59 ABBA deadlock in Common Clock Framework Tomasz Figa
2014-07-02 11:23 ` Russell King - ARM Linux [this message]
2014-07-02 11:49 ` Peter De Schrijver
2014-07-02 12:41 ` Sylwester Nawrocki
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=20140702112314.GI32514@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=a.hajda@samsung.com \
--cc=broonie@kernel.org \
--cc=lee.jones@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=mturquette@linaro.org \
--cc=t.figa@samsung.com \
--cc=t.stanislaws@samsung.com \
--cc=wsa@the-dreams.de \
/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).