Messages in this thread | | | Date | Fri, 8 Apr 2016 20:59:16 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH] sched/deadline/rtmutex: Fix a PI crash for deadline tasks |
| |
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.
| |