Messages in this thread Patch in this message | | | From | "Paul E. McKenney" <> | Subject | [PATCH tip/core/rcu 1/5] documentation: Record limitations of bitfields and small variables | Date | Tue, 28 Oct 2014 15:00:13 -0700 |
| |
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
This commit documents the fact that it is not safe to use bitfields as shared variables in synchronization algorithms. It also documents that CPUs must provide one-byte and two-byte normal load and store instructions in order to be supported by the Linux kernel. (Michael Cree has agreed to the resulting non-support of pre-EV56 Alpha CPUs: https://lkml.org/lkml/2014/9/5/143.)
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> --- Documentation/memory-barriers.txt | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+)
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index 22a969cdd476..d6bc77eb179a 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -269,6 +269,37 @@ And there are a number of things that _must_ or _must_not_ be assumed: STORE *(A + 4) = Y; STORE *A = X; STORE {*A, *(A + 4) } = {X, Y}; +And there are anti-guarantees: + + (*) These guarantees do not apply to bitfields, because compilers often + generate code to modify these using non-atomic read-modify-write + sequences. Do not attempt to use bitfields to synchronize parallel + algorithms. + + (*) Even in cases where bitfields are protected by locks, all fields + in a given bitfield must be protected by one lock. If two fields + in a given bitfield are protected by different locks, the compiler's + non-atomic read-modify-write sequences can cause an update to one + field to corrupt the value of an adjacent field. + + (*) These guarantees apply only to properly aligned and sized scalar + variables. "Properly sized" currently means variables that are + the same size as "char", "short", "int" and "long". "Properly + aligned" means the natural alignment, thus no constraints for + "char", two-byte alignment for "short", four-byte alignment for + "int", and either four-byte or eight-byte alignment for "long", + on 32-bit and 64-bit systems, respectively. Note that this means + that the Linux kernel does not support pre-EV56 Alpha CPUs, + because these older CPUs do not provide one-byte and two-byte + load and store instructions. (In theory, the pre-EV56 Alpha CPUs + can emulate these instructions using load-linked/store-conditional + instructions, but in practice this approach has excessive overhead. + Keep in mind that this emulation would be required on -all- single- + and double-byte loads and stores in order to handle adjacent bytes + protected by different locks.) + + Alpha EV56 and later Alpha CPUs are still supported. + ========================= WHAT ARE MEMORY BARRIERS? -- 1.8.1.5
| |