From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750771AbVKUV0u (ORCPT ); Mon, 21 Nov 2005 16:26:50 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750782AbVKUV0u (ORCPT ); Mon, 21 Nov 2005 16:26:50 -0500 Received: from mx3.mail.elte.hu ([157.181.1.138]:34786 "EHLO mx3.mail.elte.hu") by vger.kernel.org with ESMTP id S1750771AbVKUV0t (ORCPT ); Mon, 21 Nov 2005 16:26:49 -0500 Date: Mon, 21 Nov 2005 22:26:53 +0100 From: Ingo Molnar To: David Singleton Cc: Dinakar Guniguntala , linux-kernel@vger.kernel.org, "David F. Carlson" Subject: Re: PI BUG with -rt13 Message-ID: <20051121212653.GA6143@elte.hu> References: <20051117161817.GA3935@in.ibm.com> <437D0C59.1060607@mvista.com> <20051118092909.GC4858@elte.hu> <20051118132137.GA5639@in.ibm.com> <20051118132715.GA3314@elte.hu> <8311ADE9-5855-11DA-BBAB-000A959BB91E@mvista.com> <20051118174454.GA2793@elte.hu> <43822480.6080301@mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43822480.6080301@mvista.com> User-Agent: Mutt/1.4.2.1i X-ELTE-SpamScore: 0.0 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=0.0 required=5.9 tests=AWL autolearn=disabled SpamAssassin version=3.0.3 0.0 AWL AWL: From: address is in the auto white-list X-ELTE-VirusStatus: clean Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org * David Singleton 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 you 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? Also, what testing did this patch have - should it solve Dinakar's problem(s)? Ingo