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: <200710260142.37902.ak@suse.de>
Date:	Fri, 26 Oct 2007 01:42:37 +0200
From:	Andi Kleen <ak@...e.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Nick Piggin <nickpiggin@...oo.com.au>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Is gcc thread-unsafe?

On Friday 26 October 2007 01:32:53 Linus Torvalds wrote:
> 
> On Fri, 26 Oct 2007, Andi Kleen wrote:
> > 
> > No it can't (at least not on x86) as I have explained in the rest of the mail 
> > you conveniently snipped.
> 
> I "conveniently snipped it" because it was pointless.
> 
> "adc" or "cmov" has nothing what-so-ever to do with it. If some routine 
> returns 0-vs-1 and gcc then turns "if (routine()) x++" into 
> "x+=routine()", what does that have to do with adc or cmov?

That is not what gcc did in that case. I don't think it tracks sets of values
over function calls (or even inside functions) at all.

The generated code was

          cmpl    $1, %eax                ; test res
          movl    acquires_count, %edx    ; load
          adcl    $0, %edx                ; maybe add 1
          movl    %edx, acquires_count    ; store

So it just added the result of a comparison into a variable
by (ab)using carry for this.

In theory such things can be done with CMOV too by redirecting
a store into a dummy variable to cancel it, but gcc doesn't
do that on its own.

> The fact is, these kinds of optimizations are *bogus* and they are 
> dangerous.

The conditional add/sub using carry trick is not generally bogus. 
It's just bogus for memory addresses not pretty much guaranteed in L1
[aka small stack frame] because there the pipeline benefit is unlikely to 
offset the memory costs (and of course poor quality of implementation because of the 
missing thread safety). 

But for registers it's a fine optimization.

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