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
| ||
|
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/
Powered by blists - more mailing lists