linux-kernel - [PATCH 2.6.20-rc5 0/4] futexes functionalities and improvements

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>] [day] [month] [year] [list]

Message-ID: <45ADE56B.4010608@bull.net>
Date:	Wed, 17 Jan 2007 09:59:23 +0100
From:	Pierre Peiffer <pierre.peiffer@...l.net>
To:	LKML <linux-kernel@...r.kernel.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Ulrich Drepper <drepper@...hat.com>,
	Jakub Jelinek <jakub@...hat.com>,
	Jean-Pierre Dion <jean-pierre.dion@...l.net>
Subject: [PATCH 2.6.20-rc5 0/4] futexes functionalities and improvements

Hi,

	Today, there are several functionalities or improvements about futexes included
in -rt kernel tree, which, I think, it make sense to have in mainline.

Among them, there are:
     * futex use prio list : allows RT-threads to be woken in priority order
instead of FIFO order.
     * futex_wait use hrtimer : allows the use of finer timer resolution.
     * futex_requeue_pi functionality : allows use of requeue optimization for
PI-mutexes/PI-futexes.
     * futex64 syscall : allows use of 64-bit futexes instead of 32-bit.

The following mails provide the corresponding patches.


I re-send this series for kernel 2.6.20-rc5 with this small modifications:

  - futex_use_prio_list patch stores now all non-real-time threads with the same
priority (MAX_RT_PRIO, which is a lower priority than real-time priorities),
causing them to be stored in FIFO order. RT-threads are still woken first in
priority order.
  - futex_requeue_pi: I've found (and corrected of course) a bug causing a
memory leak.

plist (patch 1/4) is still under discussion: I think it should be taken into
account, because it concerns a correctness issue with a very low cost as
drawback (I would even say "without noticeable cost" ;-) but that's my opinion
of course).
Anyway, I still can provide the same series without patch 1/4 if needed.

Comments and feedback are still welcome, as usual.

-- 
Pierre

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