linux-kernel - Re: [patch 3/3] [-rt] Fixes the timeout-bug in the rtmutex/PI-futex.

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: <1153666661.4002.4.camel@localhost.localdomain>
Date:	Sun, 23 Jul 2006 10:57:41 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Esben Nielsen <nielsen.esben@...glemail.com>
Cc:	Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...e.hu>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [patch 3/3] [-rt] Fixes the timeout-bug in the
	rtmutex/PI-futex.

On Sun, 2006-07-23 at 02:18 +0100, Esben Nielsen wrote:
> This patch fixes
> 
> 1) The timeout bug in rtmutexes and PI futexes: When a task is blocked on a 
> lock with timeout and times out it will not wakeup until the owner of the lock
> is done. This is because the owner is boosted to the same priority as the 
> blocked task and therefore has the CPU such the blocked task never gets around 
> to de-boost it!
> 
> 2) setscheduler() now does the PI walking - but defers the work to the blocked
> task.
> 
> 3) In general it makes sure that a task, which is boosting another has enough
> priority to do the de-boosting no matter how complicated the lock structure is, 
> or how many times the priorities have changed.
> 
> The idea behind the patch is simple:
> If a task is boosting another it is scheduled in LIFO order and it will never
> loose it's priority. This property lasts until it has left the lock operation
> (successfully or not).
> 
> The needed priority to do the unboosting is stored in task->boosting_prio.
> In the current patch this is always increasing (numerically decreasing) while
> trying to take a lock. In a future it might be found safe to decrease
> boosting_prio before finally leaving the lock operation.
> 
>   include/linux/rtmutex.h                               |    1
>   include/linux/sched.h                                 |    7
>   kernel/fork.c                                         |    1
>   kernel/rtmutex.c                                      |  151 +++++++++++++-----

It is possible that these changes can break the pi code in rtmutex.c.  I
haven't analyzed it enough yet.  But just so that you know that your
changes don't break the code, and to make it easier for me to look at
it. Please update Documentation/rt-mutex-design.txt including your
changes.  This will be a good exercise to see if it doesn't really break
anything, and it will give other reviewers a better starting point for
review.

>   kernel/rtmutex_common.h                               |    1
>   kernel/sched.c                                        |   14 +
>   scripts/rt-tester/t5-l4-pi-boost-deboost-setsched.tst |   42 +++--
>   scripts/rt-tester/t5-l4-pi-boost-deboost.tst          |   12 -
>   8 files changed, 167 insertions(+), 62 deletions(-)

-- Steve


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/