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: <20070312111958.GA14573@elte.hu>
Date:	Mon, 12 Mar 2007 12:19:58 +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:

> > 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.
> 
> Absolute timeout is needed, sure. But once that is done, hrtimers does 
> not fix a bug, does it?

the issue is this: your fix reduces the effects of the bug but it is 
still fundamentally incomplete because of the use of timer_list. So 
instead of trying to fix the bug the wrong way, please try to fix it the 
right way, ontop of an already existing and tested patch, ok? That also 
enables the other neat stuff Thomas talked about.

> > until then, glibc already handles timeouts and restarts it manually.
> 
> It isn't timeout handling that is buggy, but EINTR behaviour. And 
> glibc does not handle that here.

hm. I'm wondering how this wasnt noticed sooner - this futex_wait 
behavior has been there for like forever.

	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