linux-kernel - Re: [PATCH] doc: volatile considered evil

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]

Date:	Wed, 09 May 2007 19:26:51 +1000
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	David Rientjes <rientjes@...gle.com>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	Satyam Sharma <satyam.sharma@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Paul Sokolovsky <pmiscml@...il.com>,
	linux-kernel@...r.kernel.org, jeremy@...p.org
Subject: Re: [PATCH] doc: volatile considered evil

Alan Cox wrote:
>>It's still ambiguous.  A much more explicit title that nobody could argue 
>>with would be "do not use the 'volatile' keyword as a type qualifier for 
>>an object."
> 
> 
> Except when you do. The kernel uses the C volatile in various places
> itself for specific good reasons (and some for historical bad ones)
> 
> Perhaps a closer summary would be
> 
> Do Not Use Volatile
> -------------------
> 
> 1.	volatile is not a locking mechanism
> 
> Volatile does not define sufficiently sane or strong semantics for
> locking. The kernel has proper locking mechanisms which also act as
> compiler fetch/store barriers and where neccessary hardware barriers for
> SMP systems. The kernel knows about all the corner cases, you probably
> don't.
> 
> 2.	volatile is not needed for mmio space
> 
> I/O memory access are done via readb/writeb and friends. They deal with
> volatility themselves so you don't have to. They may nor may not use
> volatile internally to their implementation, but that is none of your
> business.
> 
> 3.	volatile is not atomic
> 
> Using volatile does not guarantee atomic behaviour. This often requires
> special instructions or code sequences too. We have atomic_t and the
> atomic_* operators for this.
> 
> 4.	volatile is not a store or read barrier
> 
> Using volatile is not always sufficient to order accesses on SMP or to
> ensure things execute in the order expected. Instead the kernel provides
> a set of barrier operations which have clearly defined semantics on all
> systems. Make use of rmb, wmb, barrier, smp_wmb etc instead
> 
> When Might You Need volatile ?
> ------------------------------
> 
> When you are implementing the locking primitives on a new platform. When
> you are implementing the I/O and atomic prmitives on a new platform. Also
> in inline gcc assembler where "volatile" is used for subtly different
> purposes.

Is there a good reason for using volatile in atomic/locking primitives?
AFAIKS there is not.

-- 
SUSE Labs, Novell Inc.
-
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/