0001
0002 .. _volatile_considered_harmful:
0003
0004 Why the "volatile" type class should not be used
0005 ------------------------------------------------
0006
0007 C programmers have often taken volatile to mean that the variable could be
0008 changed outside of the current thread of execution; as a result, they are
0009 sometimes tempted to use it in kernel code when shared data structures are
0010 being used. In other words, they have been known to treat volatile types
0011 as a sort of easy atomic variable, which they are not. The use of volatile in
0012 kernel code is almost never correct; this document describes why.
0013
0014 The key point to understand with regard to volatile is that its purpose is
0015 to suppress optimization, which is almost never what one really wants to
0016 do. In the kernel, one must protect shared data structures against
0017 unwanted concurrent access, which is very much a different task. The
0018 process of protecting against unwanted concurrency will also avoid almost
0019 all optimization-related problems in a more efficient way.
0020
0021 Like volatile, the kernel primitives which make concurrent access to data
0022 safe (spinlocks, mutexes, memory barriers, etc.) are designed to prevent
0023 unwanted optimization. If they are being used properly, there will be no
0024 need to use volatile as well. If volatile is still necessary, there is
0025 almost certainly a bug in the code somewhere. In properly-written kernel
0026 code, volatile can only serve to slow things down.
0027
0028 Consider a typical block of kernel code::
0029
0030 spin_lock(&the_lock);
0031 do_something_on(&shared_data);
0032 do_something_else_with(&shared_data);
0033 spin_unlock(&the_lock);
0034
0035 If all the code follows the locking rules, the value of shared_data cannot
0036 change unexpectedly while the_lock is held. Any other code which might
0037 want to play with that data will be waiting on the lock. The spinlock
0038 primitives act as memory barriers - they are explicitly written to do so -
0039 meaning that data accesses will not be optimized across them. So the
0040 compiler might think it knows what will be in shared_data, but the
0041 spin_lock() call, since it acts as a memory barrier, will force it to
0042 forget anything it knows. There will be no optimization problems with
0043 accesses to that data.
0044
0045 If shared_data were declared volatile, the locking would still be
0046 necessary. But the compiler would also be prevented from optimizing access
0047 to shared_data _within_ the critical section, when we know that nobody else
0048 can be working with it. While the lock is held, shared_data is not
0049 volatile. When dealing with shared data, proper locking makes volatile
0050 unnecessary - and potentially harmful.
0051
0052 The volatile storage class was originally meant for memory-mapped I/O
0053 registers. Within the kernel, register accesses, too, should be protected
0054 by locks, but one also does not want the compiler "optimizing" register
0055 accesses within a critical section. But, within the kernel, I/O memory
0056 accesses are always done through accessor functions; accessing I/O memory
0057 directly through pointers is frowned upon and does not work on all
0058 architectures. Those accessors are written to prevent unwanted
0059 optimization, so, once again, volatile is unnecessary.
0060
0061 Another situation where one might be tempted to use volatile is
0062 when the processor is busy-waiting on the value of a variable. The right
0063 way to perform a busy wait is::
0064
0065 while (my_variable != what_i_want)
0066 cpu_relax();
0067
0068 The cpu_relax() call can lower CPU power consumption or yield to a
0069 hyperthreaded twin processor; it also happens to serve as a compiler
0070 barrier, so, once again, volatile is unnecessary. Of course, busy-
0071 waiting is generally an anti-social act to begin with.
0072
0073 There are still a few rare situations where volatile makes sense in the
0074 kernel:
0075
0076 - The above-mentioned accessor functions might use volatile on
0077 architectures where direct I/O memory access does work. Essentially,
0078 each accessor call becomes a little critical section on its own and
0079 ensures that the access happens as expected by the programmer.
0080
0081 - Inline assembly code which changes memory, but which has no other
0082 visible side effects, risks being deleted by GCC. Adding the volatile
0083 keyword to asm statements will prevent this removal.
0084
0085 - The jiffies variable is special in that it can have a different value
0086 every time it is referenced, but it can be read without any special
0087 locking. So jiffies can be volatile, but the addition of other
0088 variables of this type is strongly frowned upon. Jiffies is considered
0089 to be a "stupid legacy" issue (Linus's words) in this regard; fixing it
0090 would be more trouble than it is worth.
0091
0092 - Pointers to data structures in coherent memory which might be modified
0093 by I/O devices can, sometimes, legitimately be volatile. A ring buffer
0094 used by a network adapter, where that adapter changes pointers to
0095 indicate which descriptors have been processed, is an example of this
0096 type of situation.
0097
0098 For most code, none of the above justifications for volatile apply. As a
0099 result, the use of volatile is likely to be seen as a bug and will bring
0100 additional scrutiny to the code. Developers who are tempted to use
0101 volatile should take a step back and think about what they are truly trying
0102 to accomplish.
0103
0104 Patches to remove volatile variables are generally welcome - as long as
0105 they come with a justification which shows that the concurrency issues have
0106 been properly thought through.
0107
0108
0109 References
0110 ==========
0111
0112 [1] https://lwn.net/Articles/233481/
0113
0114 [2] https://lwn.net/Articles/233482/
0115
0116 Credits
0117 =======
0118
0119 Original impetus and research by Randy Dunlap
0120
0121 Written by Jonathan Corbet
0122
0123 Improvements via comments from Satyam Sharma, Johannes Stezenbach, Jesper
0124 Juhl, Heikki Orsila, H. Peter Anvin, Philipp Hahn, and Stefan
0125 Richter.
