Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755498Ab0GMK3N (ORCPT ); Tue, 13 Jul 2010 06:29:13 -0400 Received: from www.tglx.de ([62.245.132.106]:43108 "EHLO www.tglx.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750942Ab0GMK3L (ORCPT ); Tue, 13 Jul 2010 06:29:11 -0400 Date: Tue, 13 Jul 2010 12:28:32 +0200 (CEST) From: Thomas Gleixner To: Darren Hart cc: "lkml, " , Peter Zijlstra , Ingo Molnar , Eric Dumazet , John Kacur , Steven Rostedt , Mike Galbraith , linux-rt-users Subject: Re: [PATCH][RT] futex: protect against pi_blocked_on corruption during requeue PI In-Reply-To: Message-ID: References: <1278478019.10245.77.camel@marge.simson.net> <4C3C1DCF.9090509@us.ibm.com> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1728 Lines: 47 On Tue, 13 Jul 2010, Thomas Gleixner wrote: > On Tue, 13 Jul 2010, Darren Hart wrote: > > > --- a/kernel/rtmutex.c > > +++ b/kernel/rtmutex.c > > @@ -227,7 +227,7 @@ static int rt_mutex_adjust_prio_chain(struct task_struct *task, > > * reached or the state of the chain has changed while we > > * dropped the locks. > > */ > > - if (!waiter || !waiter->task) > > + if (!waiter || (long)waiter == PI_WAKEUP_INPROGRESS || !waiter->task) > > goto out_unlock_pi; > > Why do we need that check ? Either the requeue succeeded then > task->pi_blocked_on is set to the real waiter or the wakeup won and > we are in no lock chain. > > If we ever find a waiter with PI_WAKEUP_INPROGRESS set in > rt_mutex_adjust_prio_chain() then it's a bug nothing else. Grrr, I'm wrong. If we take hb->lock in the fast path then something else might try to boost us and trip over this :( This code causes braindamage. I really wonder whether we need to remove it according to the "United Nations Convention against Torture and Other Cruel, Inhuman or Degrading Treatment or Punishment". > > @@ -6377,7 +6379,8 @@ void task_setprio(struct task_struct *p, int prio) > > */ > > if (unlikely(p == rq->idle)) { > > WARN_ON(p != rq->curr); > > - WARN_ON(p->pi_blocked_on); > > + WARN_ON(p->pi_blocked_on && > > + (long)p->pi_blocked_on != PI_WAKEUP_INPROGRESS); > > Yuck. Paranoia ? If we ever requeue idle, then ..... At least one which is bogus :) Thanks, tglx -- 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/