linux-kernel - Re: Is gcc thread-unsafe?

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:	Fri, 26 Oct 2007 12:59:10 +0100
From:	Andrew Haley <aph@...hat.com>
To:	Nick Piggin <nickpiggin@...oo.com.au>
Cc:	davids@...master.com,
	"Torvalds, Linus" <torvalds@...ux-foundation.org>,
	"Kleen, Andi" <ak@...e.de>,
	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>
Subject: Re: Is gcc thread-unsafe?

[ I had to resend this message.  Sorry if you received two copies. ]

Nick Piggin writes:
 > Can you retain cc list, please?
 > 
 > On Friday 26 October 2007 07:42, David Schwartz wrote:

 > > 	I asked a collection of knowledgeable people I know about the
 > > issue. The consensus is that the optimization is not permitted in
 > > POSIX code but that it is permitted in pure C code. The basic
 > > argument goes like this:
 > >
 > > 	To make POSIX-compliant code even possible, surely
 > > optimizations that add writes to variables must be
 > > prohibited. That is -- if POSIX prohibits writing to a variable
 > > in certain cases only the programmer can detect, then a
 > > POSIX-compliant compiler cannot write to a variable except where
 > > explicitly told to do so. Any optimization that *adds* a write to
 > > a variable that would not otherwise occur *must* be prohibited.

I don't think that POSIX is quite as explicit as that.  See
http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf

 > > 	Otherwise, it is literally impossible to comply with the POSIX
 > > requirement that concurrent modifications and reads to shared
 > > variables take place while holding a mutex.
 > 
 > Now all you have to do is tell this to the gcc developers ;)

We're listening, really.  It's unacceptable that gcc should break
code.

However, fixing it is hard.  The best plan is probably to implement
(part of) the proposed standard memory model, and that requires
careful consideration.  We could in theory simply disable this
particular optimization, but that probably isn't a good idea on its
own because other optimizations might well break other code in a
similar way.  We need to have a very close look at the thread-safe
memory model in order to determine where we do things that might
break.

An official standard containing this is still at least two years out.

Andrew.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903
-
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/