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