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.0710260917500.30120@woody.linux-foundation.org> Date: Fri, 26 Oct 2007 09:28:47 -0700 (PDT) From: Linus Torvalds <torvalds@...ux-foundation.org> To: Bart Van Assche <bart.vanassche@...il.com> cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Andrew Haley <aph@...hat.com> Subject: Re: Is gcc thread-unsafe? On Fri, 26 Oct 2007, Linus Torvalds wrote: > > > 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? Thinking some more about this, you really have two cases: - full functions taking/releasing locks (possibly conditionally, ie with something lik etrylock and/or based on argument values). You simply *cannot* require these to be marked, because the locking may have been done indirectly. Yes, you can mark things like "pthread_mutex_trylock()" as being an acquire-function, but the fact is, users will then wrap these things in *other* functions, and return their return values. Ergo: a compiler *must* assume that a function call that it didn't inline involves locking. There's no point in adding some gcc-specific attributes to system header files, because it's not going to fix anything in any portable program. - inline assembly (together with, potentially, compiler primitives). That's the only other way to reliably do locking from C. This one gcc could certainly extend on. But would there really be any upside? It would be easier/better to say that inline assembly (at least if it clobbers memory or is volatile) has the same serialization issues as a function call. So the fact is, any compiler that turns if (conditional) x++; into an unconditional write to x (where 'x' is potentially visible to the outside - global visibility or has had its address taken) is just broken. No ifs, buts or maybes about it. You simply cannot do that optimization, because there is no way for the compiler to know whether the conditional implies that you hold a lock or not. 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