linux-kernel - Re: [PATCH RFC] sched: deferred set priority (dprio)

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: <1407589454.5156.308.camel@marge.simpson.net>
Date:	Sat, 09 Aug 2014 15:04:14 +0200
From:	Mike Galbraith <umgwanakikbuti@...il.com>
To:	Sergey Oboguev <oboguev.public@...il.com>
Cc:	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
	khalid.aziz@...cle.com
Subject: Re: [PATCH RFC] sched: deferred set priority (dprio)

On Fri, 2014-08-08 at 13:11 -0700, Sergey Oboguev wrote: 
> On Thu, Aug 7, 2014 at 2:03 AM, Mike Galbraith <umgwanakikbuti@...il.com> wrote:
> 
> > task priority cannot be used by any task to describe a critical section.
> > I assert that is that there is _zero_ critical section information present.
> 
> This appears to be the crux of our disagreement.
> 
> This assertion is incorrect. The use of RT to bracket a critical section
> obviously _does_ provide the following information:

You sure don't give up easy.

> 1) designation of entry point for the start of critical activity

Yup, a task can elevate its priority upon entering scram_reactor(), iff
it gets there, scram might still be considered a critical activity.

> 2) designation of exit point, albeit with timing not known in advance at entry
> time

Yeah, exit works ok if enter happens.

You are not going to convince me that it is cool to assign an imaginary
priority to a SCHED_FIFO class task, and still call the resulting mutant
a SCHED_FIFO class task.  Those things have defines semantics.  It is
not ok for a SCHED_FIFO task of a lower priority to completely ignore a
SCHED_FIFO task of a higher priority because it's part of an application
which has one or more wild cards, or maybe even a get out of jail free
card it can pull out of its butt.

NAK.  There it is, my imaginary NAK to imaginary realtime priorities :)

-Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/