linux-kernel - Re: [PATCH] hrtimers: Special-case zero length sleeps

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: <1329317650.2293.129.camel@twins>
Date:	Wed, 15 Feb 2012 15:54:10 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Matthew Garrett <mjg@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [PATCH] hrtimers: Special-case zero length sleeps

On Wed, 2012-02-15 at 15:40 +0100, Thomas Gleixner wrote:
> On Thu, 29 Sep 2011, Matthew Garrett wrote:
> 
> > sleep(0) is a common construct used by applications that want to trigger
> > the scheduler. sched_yield() might make more sense, but only appeared in
> > POSIX.1-2001 and so plenty of example code still uses the sleep(0) form.

Note that sched_yield() is unspecified for SCHED_OTHER, so any
application using it that is not a real-time application is outside spec
anyway.

Furthermore, both sched_yield() and sleep(0) are fair indications the
application is broken, wait for proper events, not random delays.

> > This wouldn't normally be a problem, but it means that event-driven
> > applications that are merely trying to avoid starving other processes may
> > actually end up sleeping due to having large timer_slack values. Special-
> > casing this seems reasonable.

Again, sleep granularity isn't specified and thus this behaviour isn't
actually buggy, all the spec promises is we won't sleep shorter than
asked.

Also, starvation avoidance isn't something that userspace should concern
itself with.
--
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/