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.0710261111390.30120@woody.linux-foundation.org>
Date:	Fri, 26 Oct 2007 11:14:17 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
cc:	Bart Van Assche <bart.vanassche@...il.com>,
	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, Alan Cox wrote:
>
> > 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.
> 
> IFF the processor doesn't reorder them in hardware, which on some
> processors is visibly out of order when viewed from an I/O device or
> another CPU.
> 
> You can stop the compiler but not the CPU - and some processors will
> certainly speculatively load across conditionals, reorder writes etc

Well, when we're talking inline asms used for locking, the whole point of 
using inline asm is exactly that you cannot do it with regular accesses, 
and have to add architecture-specific barriers. If the user gets that 
wrong, then it's a user problem, not a compiler issue.

So that's not the problem. The problem is if the compiler then does other 
things wrong *despite* the inline asm being correct. 

				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/