Re: PI BUG with -rt13

From: david singleton
Date: Mon Nov 21 2005 - 21:01:28 EST

On Nov 21, 2005, at 1:26 PM, Ingo Molnar wrote:

* David Singleton <dsingleton@xxxxxxxxxx> wrote:

here is a patch that provides the correct locking for the rt_mutex
backing the robust pthread_mutex. The patch also unifies the locking
for all the robust functions and adds support for pthread_mutexes on
the heap.

thanks. Could yo

Sure. Attached is the locking fix patch. The heap support is a very
small patch to the fix patch. I'll do the heap patch next.

u split up the patch into a fix and a 'heap' patch (at a

it's this portion of the 'heap' patch that looks problematic:

--- base/linux-2.6.14/include/linux/mm.h 2005-11-18 20:36:53.000000000 -0800
+++ wip/linux-2.6.14/include/linux/mm.h 2005-11-21 10:51:19.000000000 -0800
@@ -109,6 +109,11 @@
struct mempolicy *vm_policy; /* NUMA policy for the VMA */
+ int robust_init; /* robust initialized? */
+ struct list_head robust_list; /* list of robust futexes in this vma */
+ struct semaphore robust_sem; /* semaphore to protect the list */

why is there per-vma info needed?

I've had numerous requests to add support for pthread_mutexes that have been
'malloc'd and end up in the heap.

The original robust futex patch only supported shared pthread mutexes, backed
either by a file in which the pthread mutex was written on in anonymous
memory allocated via mmap with the MAP_SHARE and MAP_ANONYMOUS flags.

Anonymous memory gets backed by an inode on which we lookup and hang
the robust mutex structure (and which gets freed on the last reference to the inode.)

The choice seemed either to back heap with the anonymous memory/inode framework
or just hang the struct on the vma itself.

Also, what testing did this patch have - should it solve Dinakar's

The patch I sent, (minus the extra parenthesis at the end of the down_try_futex line
I mistyped while porting the patch to a tree with the rt13 patch:-(,)
has undergone testing over the weekend with the fusyn posix tests, which have
been changed to set the PRIO_INHERIT attribute via the pthread_set_protocol

I hope this patch solve's Dinakar's problem. unfortunately, I don't have Dinakar's test.


Attachment: patch-2.6.14-rt13-rf2
Description: Binary data