Skip to content

make atomic_read() behave consistently across all architectures

Chris Snook linux-arch lkml netdev 1 version In review

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 Latest24 patches 385 repliesIn review

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/24make atomic_read() behave consistently on alphainclude/asm-alpha/atomic.h+11 -735 replies
2/24make atomic_read() behave consistently on arminclude/asm-arm/atomic.h+6 -21 reply
3/24make atomic_read() behave consistently on avr32include/asm-avr32/atomic.h+6 -20 replies
4/24make atomic_read() behave consistently on blackfininclude/asm-blackfin/atomic.h+5 -10 replies
5/24make atomic_read() behave consistently on crisinclude/asm-cris/atomic.h+6 -20 replies
6/24make atomic_read() behave consistently on frvinclude/asm-frv/atomic.h+6 -129 replies
7/24make atomic_read() behave consistently on h8300include/asm-h8300/atomic.h+5 -10 replies
8/24make atomic_read() behave consistently on i386include/asm-i386/atomic.h+1 -10 replies
9/24make atomic_read() behave consistently on ia64include/asm-ia64/atomic.h+8 -813 replies
10/24make atomic_read() behave consistently on m32rinclude/asm-m32r/atomic.h+2 -20 replies
11/24make atomic_read() behave consistently on m68knommuinclude/asm-m68knommu/atomic.h+5 -10 replies
12/24make atomic_read() behave consistently on m68kinclude/asm-m68k/atomic.h+5 -10 replies
13/24make atomic_read() behave consistently on mipsinclude/asm-mips/atomic.h+4 -41 reply
14/24make atomic_read() behave consistently on pariscinclude/asm-parisc/atomic.h+8 -41 reply
15/24make atomic_read() behave consistently on powerpcinclude/asm-powerpc/atomic.h+8 -40 replies
16/24make atomic_read() behave consistently on s390include/asm-s390/atomic.h+6 -21 reply
17/24make atomic_read() behave consistently on sh64include/asm-sh64/atomic.h+6 -20 replies
18/24make atomic_read() behave consistently on shinclude/asm-sh/atomic.h+6 -21 reply
19/24make atomic_read() behave consistently on sparc64include/asm-sparc64/atomic.h+8 -40 replies
20/24make atomic_read() behave consistently on sparcinclude/asm-sparc/atomic.h+6 -20 replies
21/24make atomic_read() behave consistently on v850include/asm-v850/atomic.h+5 -10 replies
22/24make atomic_read() behave consistently on x86_64include/asm-x86_64/atomic.h+3 -30 replies
23/24make atomic_read() behave consistently on xtensainclude/asm-xtensa/atomic.h+2 -20 replies
24/24document volatile atomic_read() behaviorDocumentation/atomic_ops.txt+11 -37 replies

Reviews trailers per patch

5 of 24 patches have a Reviewed-by or Acked-by of their own; the series has one for all of them.

PatchMartin SchwidefskyRussell KingPaul MundtKyle McMartinRalf BaechlePaul E. McKenneyChristoph Lameter
SeriesA-b A-b
1/24
2/24A-b
3/24
4/24
5/24
6/24
7/24
8/24
9/24
10/24
11/24
12/24
13/24A-b
14/24A-b
15/24
16/24A-b
17/24
18/24A-b
19/24
20/24
21/24
22/24
23/24
24/24

Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes. Scroll the table sideways for all 7 reviewers.

Read the v1 thread

Cover letter [PATCH 0/24] make atomic_read() behave consistently across all architectures

As recent discussions[1], and bugs[2] have shown, there is a great deal of confusion about the expected behavior of atomic_read(), compounded by the fact that it is not the same on all architectures. Since users expect calls to atomic_read() to actually perform a read, it is not desirable to allow the compiler to optimize this away. Requiring the use of barrier() in this case is inefficient, since we only want to re-load the atomic_t variable, not everything else in scope.

This patchset makes the behavior of atomic_read uniform by removing the volatile keyword from all atomic_t and atomic64_t definitions that currently have it, and instead explicitly casts the variable as volatile in atomic_read(). This leaves little room for creative optimization by the compiler, and is in keeping with the principles behind "volatile considered harmful".

Busy-waiters should still use cpu_relax(), but fast paths may be able to reduce their use of barrier() between some atomic_read() calls.

-- Chris

1) http://lkml.org/lkml/2007/7/1/52
2) http://lkml.org/lkml/2007/8/8/122