linux-kernel - Re: [PATCH 24/24] document volatile atomic

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: <46BB403D.10202@redhat.com>
Date:	Thu, 09 Aug 2007 12:26:37 -0400
From:	Chris Snook <csnook@...hat.com>
To:	Segher Boessenkool <segher@...nel.crashing.org>
CC:	wjiang@...ilience.com, wensong@...ux-vs.org,
	heiko.carstens@...ibm.com, linux-kernel@...r.kernel.org,
	ak@...e.de, cfriesen@...tel.com, netdev@...r.kernel.org,
	horms@...ge.net.au, akpm@...ux-foundation.org,
	linux-arch@...r.kernel.org, torvalds@...ux-foundation.org,
	schwidefsky@...ibm.com, davem@...emloft.net, zlynx@....org,
	rpjday@...dspring.com, jesper.juhl@...il.com
Subject: Re: [PATCH 24/24] document volatile atomic_read() behavior

Segher Boessenkool wrote:
>> Historically this has been
>> +accomplished by declaring the counter itself to be volatile, but the
>> +ambiguity of the C standard on the semantics of volatile make this 
>> practice
>> +vulnerable to overly creative interpretation by compilers.
> 
> It's even worse when accessing through a volatile casted pointer;
> see for example the recent(*) GCC bugs in that area.
> 
> (*) Well, not _all_ that recent.  No one should be using the 3.x
> series anymore, right?
> 
>> Explicit
>> +casting in atomic_read() ensures consistent behavior across 
>> architectures
>> +and compilers.
> 
> Even modulo compiler bugs, what makes you believe that?

When you declare a variable volatile, you don't actually tell the compiler where 
you want to override its default optimization behavior, giving it some freedom 
to guess your intentions incorrectly.  When you put the cast on the data access 
itself, there is no question about precisely where in the code you want to 
override the compiler's default optimization behavior.  If the compiler doesn't 
do what you want with a volatile declaration, it might have a plausible excuse 
in the ambiguity of the C standard.  If the compiler doesn't do what you want in 
a cast specific to a single dereference, it's just plain broken.  We try to be 
compatible with plausibly correct compilers, but if they're completely broken, 
we're screwed no matter what.

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