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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070312110204.GD2231@elte.hu>
Date:	Mon, 12 Mar 2007 12:02:04 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Nick Piggin <npiggin@...e.de>
Cc:	Roland McGrath <roland@...hat.com>, akpm@...ux-foundation.org,
	mm-commits@...r.kernel.org, drepper@...hat.com, oleg@...sign.ru,
	sebastien.dugue@...l.net, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [patch] change futex_wait() to hrtimers


* Nick Piggin <npiggin@...e.de> wrote:

> > i dont think we should try to do this. We should not and cannot do 
> > anything about all of the artifacts that comes with the use of 
> > relative timeouts and schedule_timeout().
> > 
> > basically, using jiffies here (which schedule_timeout() does) is 
> > /fundamentally/ imprecise. If you get many interrupts, rounding 
> > errors sum up - and there's nothing we can do about it!
> 
> Well I did convert futex_wait to an absolute timeout based version in 
> the subsequent incremental patch. I think that is OK?

it still has the rounding artifacts: using timer_list there is no way to 
do a precise long sleep based on many small sleeps.

even if this means more work for you (i'm sorry about that!) i'm quite 
sure we should take Sebastien's hrtimers based implementation of 
futex_wait(), and use the nanosleep method to restart it. There's no 
point in further tweaking the imprecise approach: whenever some timeout 
needs to be restarted, it's a candidate for hrtimers.

until then, glibc already handles timeouts and restarts it manually.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ