linux-kernel - Re: [PATCH v3 1/6] rtmutex: Deboost before waking up the top waiter

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:	Mon, 18 Apr 2016 11:02:28 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	xlpang@...hat.com
cc:	linux-kernel@...r.kernel.org,
	Peter Zijlstra <peterz@...radead.org>,
	Juri Lelli <juri.lelli@....com>,
	Ingo Molnar <mingo@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH v3 1/6] rtmutex: Deboost before waking up the top
 waiter

On Mon, 18 Apr 2016, Xunlei Pang wrote:
> On 2016/04/18 at 16:23, Thomas Gleixner wrote:
> > On Thu, 14 Apr 2016, Xunlei Pang wrote:
> >> We should deboost before waking the high-prio task such that
> >> we don't run two tasks with the 'same' priority.
> > No. This is fundamentaly broken.
> >  
> > T1 (prio 0)	lock(X)
> >
> > -->	 	preemption
> >
> > T2 (prio 10)	lock(X)
> >    	 	boost(T1)
> > 		schedule()
> >
> > T1 (prio 10)	unlock(X)
> 
> We add a preempt_disable() before deboost to avoid the breakage,
> there's also some comment about this in the patch's code.

So the changelog is useless and misleading. Neither does it explain what's
wrong with having two tasks with the same priority in running state.

Thanks,

	tglx