[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160408185916.GQ3448@twins.programming.kicks-ass.net>
Date: Fri, 8 Apr 2016 20:59:16 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: xlpang@...hat.com, linux-kernel@...r.kernel.org,
Juri Lelli <juri.lelli@....com>,
Ingo Molnar <mingo@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>
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@...radead.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.
Powered by blists - more mailing lists