linux-kernel - Re: Difference between atomic operations and memory barriers

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:	Tue, 27 Oct 2009 15:57:49 +0100
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	"Leonidas ." <leonidas137@...il.com>
CC:	Michael Schnell <mschnell@...ino.de>,
	Noah Watkins <noah@...hdesu.com>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Difference between atomic operations and memory barriers

Leonidas . wrote:
> On Tue, Oct 27, 2009 at 3:21 AM, Michael Schnell <mschnell@...ino.de> 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
-=====-==--= =-=- ==-==
http://arcgraph.de/sr/
--
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/