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:	Mon, 26 Oct 2009 20:00:34 +0100
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	"Leonidas ." <leonidas137@...il.com>
CC:	Noah Watkins <noah@...hdesu.com>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Difference between atomic operations and memory barriers

Leonidas . wrote:
> On Mon, Oct 26, 2009 at 11:49 PM, Noah Watkins <noah@...hdesu.com> wrote:
>>> Trying to understand difference between atomic ops and memory barriers.

Atomic accesses and barriers are different concepts.

The former means that there won't be intermediary values visible (to
another CPU or to a DMA capable device) at any time; there will only be
either the old value or the new value, but nothing half-done.

The latter means that an order between two (or more) separate accesses
is enforced.

You cannot use barriers to make intrinsically non-atomic accesses look
atomically; you need a lock for such a purpose.  (Or RCU.)

>>> I was thinking all atomic operations must be using barrier internally, but I read
>>> somewhere that only some of them use barriers. Sorry for being vague here.
>>> 
>>> Operations before call to smp_mb() will not be re-ordered and all cpus will see
>>> consistent value after the variable is updated.
>>> 
>>> E.g.
>>> void * ptr = (void *) str;
>>> smb_mb();
>>> 
>>> Will this not atomically update ptr? Ptr will be seen by all cpu's in same state
>>> after it has been assigned str, right?
>> 
>> There is a bit of info in:
>>    Documentation/atomic_ops.txt
>>
>> -noah
>>
>>
> 
> 
> Thanks for the pointer, there are no atomic operations for pointers, right?
> I guess barrier is what we need in that case.

There are more atomic accesses than those which deal with atomic_t.  For
example,
	any_t *ptr = something;
is definitely atomic, and we rely on this atomicity in the kernel at
many places.

I guess these things can be found somewhere in the C language specification.
-- 
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/