On Mon, 2010-07-12 at 07:45 -0400, Steven Rostedt wrote: > On Sun, 2010-07-11 at 15:33 +0200, Mike Galbraith wrote: > > On Sat, 2010-07-10 at 21:41 +0200, Mike Galbraith wrote: > > > diff --git a/kernel/futex.c b/kernel/futex.c > > index a6cec32..ef489f3 100644 > > --- a/kernel/futex.c > > +++ b/kernel/futex.c > > @@ -2255,7 +2255,14 @@ static int futex_wait_requeue_pi(u32 __user *uaddr, int fshared, > > /* Queue the futex_q, drop the hb lock, wait for wakeup. */ > > futex_wait_queue_me(hb, &q, to); > > > > - spin_lock(&hb->lock); > > + /* > > + * Non-blocking synchronization point with futex_requeue(). > > + * > > + * We dare not block here because this will alter PI state, possibly > > + * before our waker finishes modifying same in wakeup_next_waiter(). > > + */ > > + while(!spin_trylock(&hb->lock)) > > + cpu_relax(); > > I agree that this would work. But I wonder if this should have an: > > #ifdef PREEMPT_RT > [...] > #else > spin_lock(&hb->lock); > #endif > > around it. Or encapsulate this lock in a macro that does the same thing > (just to keep the actual code cleaner) Yeah, it should. I'll wait to see what Darren/others say about holding the wakee's pi_lock across wakeup to plug it. If he submits something along that line, I can bin this. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
