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:	Sat, 18 Aug 2007 16:35:53 +0200
From:	Stefan Richter <>
To:	Jonathan Corbet <>,
	Greg Kroah-Hartman <>
CC:	Nick Piggin <>,,
	Herbert Xu <>,
	Paul Mackerras <>,
	Satyam Sharma <>,
	Christoph Lameter <>,
	Chris Snook <>,
	Linux Kernel Mailing List <>,,
	Linus Torvalds <>,, Andrew Morton <>,,,,,,,,,,,,
Subject: LDD3 pitfalls (was Re: [PATCH 0/24] make atomic_read() behave consistently
 across all architectures)

Nick Piggin wrote:
> Stefan Richter wrote:
>> Nick Piggin wrote:
>>> I don't know why people would assume volatile of atomics. AFAIK, most
>>> of the documentation is pretty clear that all the atomic stuff can be
>>> reordered etc. except for those that modify and return a value.
>> Which documentation is there?
> Documentation/atomic_ops.txt
>> For driver authors, there is LDD3.  It doesn't specifically cover
>> effects of optimization on accesses to atomic_t.
>> For architecture port authors, there is Documentation/atomic_ops.txt.
>> Driver authors also can learn something from that document, as it
>> indirectly documents the atomic_t and bitops APIs.
> "Semantics and Behavior of Atomic and Bitmask Operations" is
> pretty direct :)
> Sure, it says that it's for arch maintainers, but there is no
> reason why users can't make use of it.

Note, LDD3 page 238 says:  "It is worth noting that most of the other
kernel primitives dealing with synchronization, such as spinlock and
atomic_t operations, also function as memory barriers."

I don't know about Linux 2.6.10 against which LDD3 was written, but
currently only _some_ atomic_t operations function as memory barriers.

Besides, judging from some posts in this thread, saying that atomic_t
operations dealt with synchronization may not be entirely precise.
Stefan Richter
-=====-=-=== =--- =--=-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists