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