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] [day] [month] [year] [list]
Date:	Mon, 9 May 2016 15:42:34 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Maximilian Krüger <maximilian.krueger@....de>
Cc:	Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [RFC] sched: low latency feedback to userspace

On Mon, May 09, 2016 at 03:03:59PM +0200, Maximilian Krüger wrote:
> 
> >sched_yield() for anything other than SCHED_FIFO / SCHED_DEADLINE is a
> >'bug'. That is, calling sched_yield() outside of those two cases is
> >undefined behaviour and the kernel is free to eat your granny and set your
> >pet on fire.
> 
> okay, fair.c/yield_task_fair() does not exactly sound, as if it would set my
> granny on fire or eat my pet, nor does man 2 yield, but correct me if I'm
> wrong.

So barring the co-operative multitasking model (which is still somewhat
employed in places), sched_yield() is basically undefined except for
FIFO / DEADLINE.

Now, every OS does 'something', and we do too. But that something could
really include anything from nothing to setting pet on fire.

That said; there is a lot of crufty code out there that calls
sched_yield() for all sorts of reasons, but mostly bad ones.

I have seen code like:

	while (!event)
		sched_yield();

to wait for completion of 'event'. Now imagine what would happen if this
code ends up running at a real-time priority?

And, no, you really cannot say that will never happen as an application
developer, because the application user might start you with a different
scheduling class (for whatever reason), or the system might have
unconditional priority inheritance and you get caught in a boost chain,
or whatever.

The worst part is; we've had people reject patches when we fixed their
yield abuse for them :/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ