lkml.org 
[lkml]   [2011]   [Jan]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: Bug in scheduler when using rt_mutex
    Date


    >-----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

    \
     
     \ /
      Last update: 2011-01-17 16:19    [W:4.159 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site