linux-kernel - [patch 0/5] Fix timeout bug in rtmutex in 2.6.18-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-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0610011336040.29459@frodo.shire>
Date:	Sun, 1 Oct 2006 13:36:31 +0200 (CEST)
From:	Esben Nielsen <nielsen.esben@...glemail.com>
To:	Ingo Molnar <mingo@...e.hu>
cc:	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Steven Rostedt <rostedt@...dmis.org>
Subject: [patch 0/5] Fix timeout bug in rtmutex in 2.6.18-rt

Hi,
  I finally got around to merge my patches into a newer -rt kernel and repost 
them.

To refresh:
pthread_mutex_timedlock() for PI-futexes doesn't work on a UP machine:
Task A tries to take a lock with a timeout of say 1 ms. This lock is owned by B
which is boosted to task A's priority. The timeout interrupt wakes up A, but
since B is already running at A's priority, A will not get any CPU before B
unlocks the lock anyway.

This series of patches does the following:

1) It adds an interface to the scheduler such that task A is woken up LIFO
instead of FIFO. That means that A is now preempting B even though they have
the same priority. Thus A can de-boost B and exit the pthread_mutex_timedlock()
before B is done with the lock.

2) This is a smaller update to the rt-mutex-tester scripts. Probably not
needed, I'll post it anyway.

3) This patch makes sure that A will not loose it's priority while boosting B.
In case of other PI-mutex operations touches A's priority or explicit 
setscheduler() calls, A will not actually loose it's priority. That is
postponed until A leaves the lock operation (successfully or not). Thus A will
always be able to de-boost B.

4) Is a documentation update.

5) Is a fix to the PI-futex: There is (still) lacking a protection for
the rtmutex's internal state because. It might not be the cleanest way to do
this.

Esben

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