From: Peter Zijlstra <peterz@infradead.org>
To: samu.p.onkalo@nokia.com
Cc: mingo@elte.hu,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
tglx <tglx@linutronix.de>
Subject: Re: Bug in scheduler when using rt_mutex
Date: Mon, 17 Jan 2011 16:00:01 +0100 [thread overview]
Message-ID: <1295276401.30950.125.camel@laptop> (raw)
In-Reply-To: <1295275365.12840.13.camel@kolo>
On Mon, 2011-01-17 at 16:42 +0200, Onkalo Samu wrote:
> Hi
>
> I believe that there are some problems in the scheduling when
> the following happens:
> - Normal priority process locks rt_mutex and sleeps while keeping it
> locked.
There's your fail, don't do that!
> - RT priority process blocks on the rt_mutex while normal priority
> process is sleeping
>
> This sequence can occur with I2C access when both normal priority
> thread and irq-thread access the same I2C bus. I2C core
> contains rt_mutex and I2C drivers can sleep with wait_for_completion.
Why does I2C core use rt_mutex, that's utterly broken.
> Based on my debugging following sequence occurs (single CPU
> system):
>
> 1) There is some user process running at the background (like
> cat /dev/zero..)
> 2) User process reads sysfs entry which causes I2C acccess
> 3) User process locks rt_mutex in the I2C-core
> 4) User process sleeps while it keeps rt_mutex locked
> (wait_for_completion in I2C transfer function)
That's where things go wrong, there's absolutely nothing you can do to
fix the system once you block while holding a mutex.
next prev parent reply other threads:[~2011-01-17 14:59 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-17 14:42 Bug in scheduler when using rt_mutex Onkalo Samu
2011-01-17 15:00 ` Peter Zijlstra [this message]
2011-01-17 15:15 ` samu.p.onkalo
2011-01-17 15:28 ` Peter Zijlstra
2011-01-17 16:00 ` Peter Zijlstra
2011-01-18 8:23 ` Onkalo Samu
2011-01-18 8:59 ` Yong Zhang
2011-01-18 13:35 ` Peter Zijlstra
2011-01-18 14:25 ` Onkalo Samu
2011-01-19 2:38 ` Yong Zhang
2011-01-19 3:43 ` Mike Galbraith
2011-01-19 4:35 ` Yong Zhang
2011-01-19 5:40 ` Mike Galbraith
2011-01-19 6:09 ` Yong Zhang
2011-01-19 6:37 ` Mike Galbraith
2011-01-19 7:19 ` Ingo Molnar
2011-01-19 7:41 ` Mike Galbraith
2011-01-19 9:44 ` Peter Zijlstra
2011-01-19 10:38 ` Peter Zijlstra
2011-01-19 11:30 ` Peter Zijlstra
2011-01-19 12:58 ` Onkalo Samu
2011-01-19 13:13 ` Onkalo Samu
2011-01-19 13:30 ` Peter Zijlstra
2011-01-20 4:18 ` Yong Zhang
2011-01-20 4:27 ` Yong Zhang
2011-01-20 5:32 ` Yong Zhang
2011-01-20 4:59 ` Mike Galbraith
2011-01-20 5:30 ` Yong Zhang
2011-01-20 6:12 ` Mike Galbraith
2011-01-20 7:06 ` Yong Zhang
2011-01-20 8:37 ` Mike Galbraith
2011-01-20 9:07 ` Yong Zhang
2011-01-20 10:07 ` Mike Galbraith
2011-01-21 11:08 ` Peter Zijlstra
2011-01-21 12:24 ` Yong Zhang
2011-01-21 13:40 ` Peter Zijlstra
2011-01-21 15:03 ` Yong Zhang
2011-01-21 15:10 ` Peter Zijlstra
2011-01-21 13:15 ` Yong Zhang
2011-01-20 7:07 ` Onkalo Samu
2011-01-21 6:25 ` Onkalo Samu
2011-01-20 3:10 ` Yong Zhang
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=1295276401.30950.125.camel@laptop \
--to=peterz@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=samu.p.onkalo@nokia.com \
--cc=tglx@linutronix.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