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]

Date:	Wed, 15 Feb 2012 14:52:25 +0000
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Arjan van de Ven <arjan@...radead.org>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH] hrtimers: Special-case zero length sleeps

On Wed, Feb 15, 2012 at 03:40:24PM +0100, Thomas Gleixner wrote:
> > +	 * be scheduled. Special case that to avoid actually putting them
> > +	 * to sleep for the duration of the slack.
> > +	 */
> > +	if (rqtp->tv_sec == 0 && rqtp->tv_nsec == 0)
> > +		slack = 0;
> 
> That's pretty pointless. You can simply return 0 here as
> do_nanosleep() will not call the scheduler on an already expired
> timer, which is always true for a relative timer with delta 0.

I'm actually starting to wonder about the applications doing this. We 
default to adding a small amount of slack even if the application has 
done sleep(0), which will mean that the timer hasn't expired at this 
point. Do we then go through the scheduler differently? Are these 
applications actually relying on an invalid assumption?

-- 
Matthew Garrett | mjg59@...f.ucam.org
--
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/