linux-kernel - Re: [PATCH/RFC] wait_for_completion

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:	Tue, 19 Nov 2013 15:39:54 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Peter Zijlstra <peterz@...radead.org>
cc:	NeilBrown <neilb@...e.de>, Jonathan Corbet <corbet@....net>,
	Dean Nelson <dcn@....com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...hat.com>,
	lkml <linux-kernel@...r.kernel.org>,
	"Dr. H. Nikolaus Schaller" <hns@...delico.com>,
	Marek Belisko <marek@...delico.com>,
	Mark Brown <broonie@...nel.org>
Subject: Re: [PATCH/RFC] wait_for_completion_timeout() considered harmful.

On Tue, 19 Nov 2013, Peter Zijlstra wrote:
> On Tue, Nov 19, 2013 at 07:58:51PM +1100, NeilBrown wrote:
> > 	/*
> > 	 * TODO: Make sure that we wait at least required delay but why we
> > 	 * have to extend it one tick more?
> > 	 */
> > 	schedule_timeout_interruptible(msecs_to_jiffies(delay) + 2);
> 
> What makes me sad is that clearly people knew stuff was broken but
> somehow it never got properly fixed.
> 
> Yes, changing something like this is risky, but I prefer to fix the
> implementation to the sane and documented behaviour and fix up whatever
> fallout that generates. The end result is saner code in general and less
> new bugs.

The underlying issue of the timer wheel is that it is driven by a
coarse grained tick.

So a schedule_timeout(1) is guaranteed to sleep until the next tick
arrives. There is no way to figure out whether the timer was started
right at the beginning of a tick period or right at the end.

This has been the case from day one of the timer wheel.

The user space interfaces [clock_]nanosleep and the various posix
timers had countermeasures based on gettimeofday() to guarantee the
correct behaviour. glibc still has some extra checks around some
timeout related syscalls for that reason. We killed that mess when we
converted them over to hrtimers.

So if you really want to make sure that you slept at minimum the given
number of ticks with the timer wheel, then you have only one choice:

       Add unconditionally 1 to the given number of ticks

I don't think that this will cause a massive fallout as the timing of
the timer_list timers already varies by an order of magnitude due to
the HZ settings. So anything which relies on the timer wheel in terms
of precision is hosed already. So adding 1 will just hose it some
more.

Thanks,

	tglx
--
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/