linux-kernel - Re: why are some atomic_t's not volatile, while most are?

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: <46B8F62C.6030607@nortel.com>
Date:	Tue, 07 Aug 2007 16:46:04 -0600
From:	"Chris Friesen" <cfriesen@...tel.com>
To:	Chris Snook <csnook@...hat.com>
CC:	Jerry Jiang <wjiang@...ilience.com>,
	"Robert P. J. Day" <rpjday@...dspring.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: why are some atomic_t's not volatile, while most are?

Chris Snook wrote:
> Chris Friesen wrote:
>> Without other restrictions, a suficiently 
>> intelligent optimiser could notice that the address of v doesn't 
>> change in the loop and the destination is never written within the 
>> loop, so the read could be hoisted out of the loop.

> That would be a compiler bug.

Could you elaborate?  From the point of view of the compiler, it "knows" 
that the variable doesn't change inside the loop.

In the "volatile considered evil" discussion in May of this year, Alan 
Cox explicitly mentioned the implementation of atomic primitives as a 
case where "volatile" might be required.

> On most superscalar architectures, including powerpc, multiple 
> instructions can be in flight simultaneously, potentially even reading 
> and writing the same data.  When the compiler detects data dependencies 
> within a thread of execution, it will do the right thing.

In the example I gave, as far as the compiler can detect there are no 
dependencies.  The code that changes the value is in a different 
compilation unit.

> Modern ISAs that lack legacy baggage do away 
> with this guarantee, putting the burden on the compiler to enforce 
> serialization.  When the compiler can't detect that it's needed, we use 
> volatile to inform it explicitly.

I certainly agree with this statement.

This leads logically to the question of whether there are cases where 
the compiler cannot detect that serialization is needed when 
implementing atomic_t accessor functions.  Previously in this thread 
you've said that there are not, while I've attempted to show that it is 
possible.

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/