linux-kernel - Re: [PATCH 1/24] make atomic_read() behave consistently on alpha

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <b6f6588ccebe3e91a03fb2f76febbe34@kernel.crashing.org>
Date:	Thu, 9 Aug 2007 21:17:12 +0200
From:	Segher Boessenkool <segher@...nel.crashing.org>
To:	Chris Snook <csnook@...hat.com>
Cc:	wjiang@...ilience.com, rpjday@...dspring.com, wensong@...ux-vs.org,
	heiko.carstens@...ibm.com, linux-kernel@...r.kernel.org,
	ak@...e.de, netdev@...r.kernel.org, paulmck@...ux.vnet.ibm.com,
	horms@...ge.net.au, akpm@...ux-foundation.org,
	linux-arch@...r.kernel.org, jesper.juhl@...il.com,
	torvalds@...ux-foundation.org, schwidefsky@...ibm.com,
	davem@...emloft.net, cfriesen@...tel.com, zlynx@....org
Subject: Re: [PATCH 1/24] make atomic_read() behave consistently on alpha

> If you need to guarantee that the value is written to memory at a 
> particular time in your execution sequence, you either have to read it 
> from memory to force the compiler to store it first

That isn't enough.  The CPU will happily read the datum back from
its own store queue before it ever hit memory or cache or any
external bus.  If you need the value to be globally visible before
another store, you use wmb(); if you need it before some read,
you use mb().

These concepts are completely separate from both atomicity and
volatility (which aren't the same themselves).

> No, but I can reason about it and be confident that this won't break 
> anything that isn't already broken.  At worst, this patch will make 
> any existing subtly incorrect uses of atomic_t much more obvious and 
> easier to track down.

PR22278, PR29753 -- both P2 bugs, and both about basic *(volatile *)
usage.  Yeah, it's definitely not problematic, esp. not if you want
to support older compilers than 4.2 too.</sarcasm>


Segher

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