From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S941559AbcIZPWk (ORCPT ); Mon, 26 Sep 2016 11:22:40 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:52062 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933889AbcIZPWj (ORCPT ); Mon, 26 Sep 2016 11:22:39 -0400 Date: Mon, 26 Sep 2016 17:22:28 +0200 From: Peter Zijlstra To: Steven Rostedt Cc: mingo@kernel.org, tglx@linutronix.de, juri.lelli@arm.com, xlpang@redhat.com, bigeasy@linutronix.de, linux-kernel@vger.kernel.org, mathieu.desnoyers@efficios.com, jdesfossez@efficios.com, bristot@redhat.com, Ingo Molnar Subject: Re: [PATCH -v2 1/9] rtmutex: Deboost before waking up the top waiter Message-ID: <20160926152228.GE5016@twins.programming.kicks-ass.net> References: <20160926123213.851818224@infradead.org> <20160926124127.863639194@infradead.org> <20160926111511.1d963075@grimm.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160926111511.1d963075@grimm.local.home> User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 26, 2016 at 11:15:11AM -0400, Steven Rostedt wrote: > On Mon, 26 Sep 2016 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); > > 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.