[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160928092413.GN5012@twins.programming.kicks-ass.net>
Date: Wed, 28 Sep 2016 11:24:13 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: mingo@...nel.org, tglx@...utronix.de, juri.lelli@....com,
rostedt@...dmis.org, xlpang@...hat.com,
linux-kernel@...r.kernel.org, mathieu.desnoyers@...icios.com,
jdesfossez@...icios.com, bristot@...hat.com,
Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH -v2 1/9] rtmutex: Deboost before waking up the top waiter
On Wed, Sep 28, 2016 at 11:07:40AM +0200, Sebastian Andrzej Siewior wrote:
> On 2016-09-26 14:32:14 [+0200], Peter Zijlstra wrote:
> > --- a/kernel/futex.c
> > +++ b/kernel/futex.c
> > @@ -1374,9 +1374,8 @@ static int wake_futex_pi(u32 __user *uad
> > * scheduled away before the wake up can take place.
> > */
> > spin_unlock(&hb->lock);
> > - wake_up_q(&wake_q);
> > - if (deboost)
> > - rt_mutex_adjust_prio(current);
> > +
> > + rt_mutex_postunlock(&wake_q, deboost);
>
> This breaks -RT. Before that spin_unlock() you do a preempt_disable()
> which means you had one spinlock with enabled preemption and now you get
> one unlock with disabled preemption. And this breaks migrate_disable() /
> enable (because we take the fast path in the in_atomic() case).
Oh crud, the hb lock is not raw :/
Powered by blists - more mailing lists