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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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.