On Mon, Sep 26, 2016 at 11:15:11AM -0400, Steven Rostedt wrote: > On Mon, 26 Sep 2016 14:32:14 +0200 > Peter Zijlstra <pet...@infradead.org> 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); > > Hmm... > > > > > return 0; > > } > > --- a/kernel/locking/rtmutex.c > > +++ b/kernel/locking/rtmutex.c > > @@ -1325,6 +1308,16 @@ static bool __sched rt_mutex_slowunlock( > > */ > > mark_wakeup_next_waiter(wake_q, lock); > > > > + /* > > + * We should deboost before waking the top waiter task such that > > + * we don't run two tasks with the 'same' priority. This however > > + * can lead to prio-inversion if we would get preempted after > > + * the deboost but before waking our high-prio task, hence the > > + * preempt_disable before unlock. Pairs with preempt_enable() in > > + * rt_mutex_postunlock(); > > There's a preempt_enable() in rt_mutex_postunlock()? Does > wake_futex_pi() know that? >
Not sure I see your point. rt_mutex_futex_unlock() calls rt_mutex_slowunlock() which does the preempt_disable(), we then pass the return of that into deboost, which we pass into rt_mutex_postunlock() and everything should be balanced.
