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]
Message-ID: <20160408173835.GC1087@worktop>
Date:	Fri, 8 Apr 2016 19:38:35 +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 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 furthermore guarantees that it points to a blocked task, another
useful property.

> Maybe I'm missing something, what exactly do you mean by "same state"?

So the whole point of boosting is to donate the waiters eligibility to
run to the lock owner. Semantically it is very poor to have two tasks
run based on this one eligibility.

And for pure priority inheritance it doesn't go further than that.

But now consider we want to implement things like bandwidth inheritance,
where the lock owner actively consumes the runtime budget of the waiter,
then it is very important to not have any overlap on the budget usage.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ