Messages in this thread | | | From | <> | Subject | RE: Bug in scheduler when using rt_mutex | Date | Mon, 17 Jan 2011 15:15:38 +0000 |
| |
>-----Original Message----- >From: ext Peter Zijlstra [mailto:peterz@infradead.org] >Sent: 17 January, 2011 17:00 >To: Onkalo Samu.P (Nokia-MS/Tampere) >Cc: mingo@elte.hu; linux-kernel@vger.kernel.org; tglx >Subject: Re: Bug in scheduler when using rt_mutex > >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!
So that is forbidden:
rt_mutex_lock(); wait_for_completion(); <--- shared HW finishes its job rt_mutex_unlock();
> >> - 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.
To get low priority task finish ongoing I2C access in time under heavy load cases I think.
> >> 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.
Of course other processes are waiting until the (rt_)mutex is unlocked. Problem is that after the rt_mutex_unlock is done, the task which just released the lock, may be in some non-running state for minutes.
-Samu
| |