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: <e2e108260710261007n118186b5geb3a48094638497f@mail.gmail.com> Date: Fri, 26 Oct 2007 19:07:14 +0200 From: "Bart Van Assche" <bart.vanassche@...il.com> To: "Linus Torvalds" <torvalds@...ux-foundation.org> Cc: "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>, "Andrew Haley" <aph@...hat.com> Subject: Re: Is gcc thread-unsafe? On 10/26/07, Linus Torvalds <torvalds@...ux-foundation.org> wrote: > > 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 like trylock 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. You have a point here. > - 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. A problem is that the serialization properties defined for functions in the C standard only apply to volatile variables, not to non-volatile variables. But for asm statements this can be solved by adding memory to the list of clobbered registers -- this will prevent any reordering of manipulations of non-volatile variables and asm statements. Andrew, do you know whether gcc currently contains any optimization that interchanges the order of accesses to non-volatile variables and function calls ? > 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. I agree with the above, but I see this as a different issue -- it wasn't my intention to solve this with my proposal for acquire and release attributes. Bart Van Assche. - 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