On Nov 21, 2005, at 1:26 PM, Ingo Molnar wrote:
* David Singleton <[email protected]> wrote:Ingo, 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 minimum)? 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 @@ #ifdef CONFIG_NUMA struct mempolicy *vm_policy; /* NUMA policy for the VMA */ #endif +#ifdef CONFIG_FUTEX + 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 */ +#endif };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 hangthe 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 problem(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
function.I hope this patch solve's Dinakar's problem. unfortunately, I don't have Dinakar's test.
David
Attachment:
patch-2.6.14-rt13-rf2
Description: Binary data
Ingo
- Follow-Ups:
- Re: PI BUG with -rt13
- From: Ingo Molnar <[email protected]>
- Re: PI BUG with -rt13
- From: Ingo Molnar <[email protected]>
- Re: PI BUG with -rt13
- References:
- PI BUG with -rt13
- From: Dinakar Guniguntala <[email protected]>
- Re: PI BUG with -rt13
- From: David Singleton <[email protected]>
- Re: PI BUG with -rt13
- From: Ingo Molnar <[email protected]>
- Re: PI BUG with -rt13
- From: Dinakar Guniguntala <[email protected]>
- Re: PI BUG with -rt13
- From: Ingo Molnar <[email protected]>
- Re: PI BUG with -rt13
- From: david singleton <[email protected]>
- Re: PI BUG with -rt13
- From: Ingo Molnar <[email protected]>
- Re: PI BUG with -rt13
- From: David Singleton <[email protected]>
- Re: PI BUG with -rt13
- From: Ingo Molnar <[email protected]>
- PI BUG with -rt13
- Prev by Date: Re: [PATCH -mm2] net: Fix compiler-error on dgrs.c when !CONFIG_PCI
- Next by Date: Re: [PATCH 0/13] Time: Generic Timeofday Subsystem (v B11)
- Previous by thread: Re: PI BUG with -rt13
- Next by thread: Re: PI BUG with -rt13
- Index(es):