Date: Tue, 20 Dec 2005 21:20:04 +0530
From: Dinakar Guniguntala <dino@in.ibm.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: David Singleton <dsingleton@mvista.com>, linux-kernel@vger.kernel.org,
       robustmutexes@lists.osdl.org
Subject: Re: Recursion bug in -rt
Message-ID: <20051220155004.GA3906@in.ibm.com>
Reply-To: dino@in.ibm.com
References: <20051214223912.GA4716@in.ibm.com> <43A1BD61.5070409@mvista.com> <20051220131956.GA24408@elte.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20051220131956.GA24408@elte.hu>
User-Agent: Mutt/1.4.2.1i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 909
Lines: 25

On Tue, Dec 20, 2005 at 02:19:56PM +0100, Ingo Molnar wrote:
> 
> hm, i'm looking at -rf4 - these changes look fishy:
> 
> -       _raw_spin_lock(&lock_owner(lock)->task->pi_lock);
> +       if (current != lock_owner(lock)->task)
> +               _raw_spin_lock(&lock_owner(lock)->task->pi_lock);
> 
> why is this done?
>
 
Ingo, this is to prevent a kernel hang due to application error.

Basically when an application does a pthread_mutex_lock twice on a
_nonrecursive_ mutex with robust/PI attributes the whole system hangs.
Ofcourse the application clearly should not be doing anything like
that, but it should not end up hanging the system either

	-Dinakar

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/