linux-kernel - RE: Bug in scheduler when using rt

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <90C2C3D80A94B8448891D39FF568E8760760B892@008-AM1MPN1-012.mgdnok.nokia.com>
Date:	Mon, 17 Jan 2011 15:15:38 +0000
From:	<samu.p.onkalo@...ia.com>
To:	<peterz@...radead.org>
CC:	<mingo@...e.hu>, <linux-kernel@...r.kernel.org>,
	<tglx@...utronix.de>
Subject: RE: Bug in scheduler when using rt_mutex



>-----Original Message-----
>From: ext Peter Zijlstra [mailto:peterz@...radead.org]
>Sent: 17 January, 2011 17:00
>To: Onkalo Samu.P (Nokia-MS/Tampere)
>Cc: mingo@...e.hu; linux-kernel@...r.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