Re: [PATCH] sched/deadline/rtmutex: Fix a PI crash for deadline tasks

[Peter Zijlstra <peterz@infradead.org>]

On Fri, Apr 08, 2016 at 02:50:55PM -0400, Steven Rostedt wrote:
> On Fri, 8 Apr 2016 19:38:35 +0200
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > On Fri, Apr 08, 2016 at 12:25:10PM -0400, Steven Rostedt wrote:
> > 
> > > So the preempt_disable() is to allow us to set current back to its
> > > normal priority first before waking up the other task because we don't
> > > want two tasks at the same priority?  
> > 
> > > What's the point of swapping deboost and the wake up again?  
> > 
> > In the context of this patch, it ensures the new pi_task pointer points
> > to something that exists -- this is a rather useful property for a
> > pointer to have.
> 
> It's not clear to what would make the new pi_task pointer object no
> longer exist from this patch. I take it that waking up the wake_q, will
> cause something to change in the code of rt_mutex_adjust_prio(current).
> If so, it should probably be stated in a comment, because nothing is
> obvious here.

Its pretty obvious that a running task can exit :-)

But also, wake_q holds a task ref.

> > It furthermore guarantees that it points to a blocked task, another
> > useful property.
> 
> I would think that the slowfn() would have removed anything to do with
> what's on the wake_q removed from current.

It cannot.

> What task on what pointer.
> I'm only looking at this current patch, not anything to do with the
> original patch of this thread. That is, just the swap of waking up
> wake_q and calling rt_mutex_adjust_prio().

This whole patch was in the context of the previous patch, as should be
clear from the thread.

In any case, I just realized we do not in fact provide this guarantee
(of pointing to a blocked task) that needs a bit more work.