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]

Message-ID: <alpine.LFD.0.999.0710260814570.30120@woody.linux-foundation.org>
Date:	Fri, 26 Oct 2007 08:27:18 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Bart Van Assche <bart.vanassche@...il.com>
cc:	linux-kernel@...r.kernel.org
Subject: Re: Is gcc thread-unsafe?

On Fri, 26 Oct 2007, Bart Van Assche wrote:
> 
> You can find my proposal to improve gcc here:
> http://gcc.gnu.org/ml/gcc/2007-10/msg00465.html

Btw, I think this is fine per se, but putting "__attribute__((acquire))" 
on the functions that acquire a lock does seem to be problematic, in that 
quite often you might well want to inline those things. How would you 
handle that?

The fact is, the whole optimization is broken. You should never do 
extraneous writes to anything but registers (or your own spill pool on the 
stack - anything that hasn't had its address taken and cannot be visible 
to outsiders). A C compiler should basically do what the user asks it to 
do, and that means that it simply should be _very_ nervous about doing 
optimizations that can have visible secondary effects.

So the first question that should be asked is: "is that optimization even 
worth it in the first place outside of registers and the spill pool?"

If an optimization introduces visible behaviour differences to the 
"obvious" stupid interpretation of the code, it should automatically be 
something that should be given a lot of thought, and perhaps not enabled 
at all by default (where "default" is certainly normal optimization 
levels).

And different languages have different usages. In C, it's quite common 
(and _possible_) for the programmer to specify how to do things at a 
fairly low level. That's not true in all other languages, and it affects 
how a compiler should optimize things. In C, a compiler should give more 
weight to "this is how the user specified the solution" because in C, 
programmers really *do* that. 

So I don't think your proposal is wrong, but I think before even going to 
something like that, you should ask yourself: "was that a valid 
optimization to start with?"

(That said, there may well be *other* reasons for wanting gcc to know 
about lock/unlock behaviour and teaching gcc about barriers. If gcc starts 
getting more threading knowledge, gcc may well need to have that kind of 
information in other places).

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