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  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:	Tue, 27 Oct 2009 15:57:49 +0100
From:	Stefan Richter <>
To:	"Leonidas ." <>
CC:	Michael Schnell <>,
	Noah Watkins <>,
	linux-kernel <>
Subject: Re: Difference between atomic operations and memory barriers

Leonidas . wrote:
> On Tue, Oct 27, 2009 at 3:21 AM, Michael Schnell <> wrote:
>> Leonidas . wrote:
>>> any_t *ptr = something;
>>> is always atomic even on SMPs without using locks, barriers then my
>>> doubt is cleared. Thanks.
>> I assume that this only holds if the pointer (not the thing it points
>> to) is denoted as volatile.

  - Atomic access (either old or new value is visible to CPUs or
    devices, but never any intermediary, half-baked value),
  - memory barrier (enforced order of accesses),
  - volatile qualifier (disabled compiler optimization of accesses)

are three different concepts.

We rely on atomic pointer load and store all over the kernel, yet never
qualify them as "volatile".  (A look into the C language spec might
bring clarity here.  I don't have the spec at hand alas.)

> I dont think so,  volatile would only ensure no caching, so some cpus
> might see the cached pointer (this is where you would want to use
> barriers), but pointer assignment would still be atomic.

What "volatile" ensures or not ensures is not that well defined in the C
language specification as far as I recall prior discussion.  Its precise
effects are compiler dependent.  You are right in so far as volatile
(given or missing) does not change whether an access is guaranteed
atomic or not.  Since it affects compiler optimizations, I think it
could possibly affect atomicity of accesses which were never guaranteed
to be atomic.  But this should not be interesting to 99.99% of all
kernel coders because they better use guaranteed atomic accesses when
they really need them.  (E.g. <linux/atomic.h> or pointer load/ store.)
Stefan Richter
-=====-==--= =-=- ==-==
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists