Documentation/process/volatile-considered-harmful.rst

   1
   2 .. _volatile_considered_harmful:
   3
   4 Why the "volatile" type class should not be used
   5 ------------------------------------------------
   6
   7 C programmers have often taken volatile to mean that the variable could be
   8 changed outside of the current thread of execution; as a result, they are
   9 sometimes tempted to use it in kernel code when shared data structures are
  10 being used.  In other words, they have been known to treat volatile types
  11 as a sort of easy atomic variable, which they are not.  The use of volatile in
  12 kernel code is almost never correct; this document describes why.
  13
  14 The key point to understand with regard to volatile is that its purpose is
  15 to suppress optimization, which is almost never what one really wants to
  16 do.  In the kernel, one must protect shared data structures against
  17 unwanted concurrent access, which is very much a different task.  The
  18 process of protecting against unwanted concurrency will also avoid almost
  19 all optimization-related problems in a more efficient way.
  20
  21 Like volatile, the kernel primitives which make concurrent access to data
  22 safe (spinlocks, mutexes, memory barriers, etc.) are designed to prevent
  23 unwanted optimization.  If they are being used properly, there will be no
  24 need to use volatile as well.  If volatile is still necessary, there is
  25 almost certainly a bug in the code somewhere.  In properly-written kernel
  26 code, volatile can only serve to slow things down.
  27
  28 Consider a typical block of kernel code::
  29
  30     spin_lock(&the_lock);
  31     do_something_on(&shared_data);
  32     do_something_else_with(&shared_data);
  33     spin_unlock(&the_lock);
  34
  35 If all the code follows the locking rules, the value of shared_data cannot
  36 change unexpectedly while the_lock is held.  Any other code which might
  37 want to play with that data will be waiting on the lock.  The spinlock
  38 primitives act as memory barriers - they are explicitly written to do so -
  39 meaning that data accesses will not be optimized across them.  So the
  40 compiler might think it knows what will be in shared_data, but the
  41 spin_lock() call, since it acts as a memory barrier, will force it to
  42 forget anything it knows.  There will be no optimization problems with
  43 accesses to that data.
  44
  45 If shared_data were declared volatile, the locking would still be
  46 necessary.  But the compiler would also be prevented from optimizing access
  47 to shared_data _within_ the critical section, when we know that nobody else
  48 can be working with it.  While the lock is held, shared_data is not
  49 volatile.  When dealing with shared data, proper locking makes volatile
  50 unnecessary - and potentially harmful.
  51
  52 The volatile storage class was originally meant for memory-mapped I/O
  53 registers.  Within the kernel, register accesses, too, should be protected
  54 by locks, but one also does not want the compiler "optimizing" register
  55 accesses within a critical section.  But, within the kernel, I/O memory
  56 accesses are always done through accessor functions; accessing I/O memory
  57 directly through pointers is frowned upon and does not work on all
  58 architectures.  Those accessors are written to prevent unwanted
  59 optimization, so, once again, volatile is unnecessary.
  60
  61 Another situation where one might be tempted to use volatile is
  62 when the processor is busy-waiting on the value of a variable.  The right
  63 way to perform a busy wait is::
  64
  65     while (my_variable != what_i_want)
  66         cpu_relax();
  67
  68 The cpu_relax() call can lower CPU power consumption or yield to a
  69 hyperthreaded twin processor; it also happens to serve as a compiler
  70 barrier, so, once again, volatile is unnecessary.  Of course, busy-
  71 waiting is generally an anti-social act to begin with.
  72
  73 There are still a few rare situations where volatile makes sense in the
  74 kernel:
  75
  76   - The above-mentioned accessor functions might use volatile on
  77     architectures where direct I/O memory access does work.  Essentially,
  78     each accessor call becomes a little critical section on its own and
  79     ensures that the access happens as expected by the programmer.
  80
  81   - Inline assembly code which changes memory, but which has no other
  82     visible side effects, risks being deleted by GCC.  Adding the volatile
  83     keyword to asm statements will prevent this removal.
  84
  85   - The jiffies variable is special in that it can have a different value
  86     every time it is referenced, but it can be read without any special
  87     locking.  So jiffies can be volatile, but the addition of other
  88     variables of this type is strongly frowned upon.  Jiffies is considered
  89     to be a "stupid legacy" issue (Linus's words) in this regard; fixing it
  90     would be more trouble than it is worth.
  91
  92   - Pointers to data structures in coherent memory which might be modified
  93     by I/O devices can, sometimes, legitimately be volatile.  A ring buffer
  94     used by a network adapter, where that adapter changes pointers to
  95     indicate which descriptors have been processed, is an example of this
  96     type of situation.
  97
  98 For most code, none of the above justifications for volatile apply.  As a
  99 result, the use of volatile is likely to be seen as a bug and will bring
 100 additional scrutiny to the code.  Developers who are tempted to use
 101 volatile should take a step back and think about what they are truly trying
 102 to accomplish.
 103
 104 Patches to remove volatile variables are generally welcome - as long as
 105 they come with a justification which shows that the concurrency issues have
 106 been properly thought through.
 107
 108
 109 References
 110 ==========
 111
 112 [1] https://lwn.net/Articles/233481/
 113
 114 [2] https://lwn.net/Articles/233482/
 115
 116 Credits
 117 =======
 118
 119 Original impetus and research by Randy Dunlap
 120
 121 Written by Jonathan Corbet
 122
 123 Improvements via comments from Satyam Sharma, Johannes Stezenbach, Jesper
 124 Juhl, Heikki Orsila, H. Peter Anvin, Philipp Hahn, and Stefan
 125 Richter.