^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) ===============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2) Locking lessons
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) ===============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) Lesson 1: Spin locks
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6) ====================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) The most basic primitive for locking is spinlock::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) static DEFINE_SPINLOCK(xxx_lock);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) unsigned long flags;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) spin_lock_irqsave(&xxx_lock, flags);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) ... critical section here ..
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) spin_unlock_irqrestore(&xxx_lock, flags);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) The above is always safe. It will disable interrupts _locally_, but the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) spinlock itself will guarantee the global lock, so it will guarantee that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) there is only one thread-of-control within the region(s) protected by that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) lock. This works well even under UP also, so the code does _not_ need to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) worry about UP vs SMP issues: the spinlocks work correctly under both.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) NOTE! Implications of spin_locks for memory are further described in:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) Documentation/memory-barriers.txt
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) (5) ACQUIRE operations.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) (6) RELEASE operations.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) The above is usually pretty simple (you usually need and want only one
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) spinlock for most things - using more than one spinlock can make things a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) lot more complex and even slower and is usually worth it only for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) sequences that you **know** need to be split up: avoid it at all cost if you
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) aren't sure).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) This is really the only really hard part about spinlocks: once you start
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) using spinlocks they tend to expand to areas you might not have noticed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) before, because you have to make sure the spinlocks correctly protect the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) shared data structures **everywhere** they are used. The spinlocks are most
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) easily added to places that are completely independent of other code (for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) example, internal driver data structures that nobody else ever touches).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) NOTE! The spin-lock is safe only when you **also** use the lock itself
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) to do locking across CPU's, which implies that EVERYTHING that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) touches a shared variable has to agree about the spinlock they want
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) to use.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) ----
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) Lesson 2: reader-writer spinlocks.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) ==================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) If your data accesses have a very natural pattern where you usually tend
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) to mostly read from the shared variables, the reader-writer locks
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) (rw_lock) versions of the spinlocks are sometimes useful. They allow multiple
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) readers to be in the same critical region at once, but if somebody wants
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) to change the variables it has to get an exclusive write lock.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) NOTE! reader-writer locks require more atomic memory operations than
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) simple spinlocks. Unless the reader critical section is long, you
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) are better off just using spinlocks.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) The routines look the same as above::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) rwlock_t xxx_lock = __RW_LOCK_UNLOCKED(xxx_lock);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) unsigned long flags;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) read_lock_irqsave(&xxx_lock, flags);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) .. critical section that only reads the info ...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) read_unlock_irqrestore(&xxx_lock, flags);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75) write_lock_irqsave(&xxx_lock, flags);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) .. read and write exclusive access to the info ...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) write_unlock_irqrestore(&xxx_lock, flags);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79) The above kind of lock may be useful for complex data structures like
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) linked lists, especially searching for entries without changing the list
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) itself. The read lock allows many concurrent readers. Anything that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82) **changes** the list will have to get the write lock.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) NOTE! RCU is better for list traversal, but requires careful
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) attention to design detail (see Documentation/RCU/listRCU.rst).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87) Also, you cannot "upgrade" a read-lock to a write-lock, so if you at _any_
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) time need to do any changes (even if you don't do it every time), you have
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) to get the write-lock at the very beginning.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91) NOTE! We are working hard to remove reader-writer spinlocks in most
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) cases, so please don't add a new one without consensus. (Instead, see
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) Documentation/RCU/rcu.rst for complete information.)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95) ----
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) Lesson 3: spinlocks revisited.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98) ==============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) The single spin-lock primitives above are by no means the only ones. They
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) are the most safe ones, and the ones that work under all circumstances,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) but partly **because** they are safe they are also fairly slow. They are slower
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) than they'd need to be, because they do have to disable interrupts
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) (which is just a single instruction on a x86, but it's an expensive one -
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) and on other architectures it can be worse).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) If you have a case where you have to protect a data structure across
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) several CPU's and you want to use spinlocks you can potentially use
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) cheaper versions of the spinlocks. IFF you know that the spinlocks are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) never used in interrupt handlers, you can use the non-irq versions::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) spin_lock(&lock);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) ...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114) spin_unlock(&lock);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) (and the equivalent read-write versions too, of course). The spinlock will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) guarantee the same kind of exclusive access, and it will be much faster.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) This is useful if you know that the data in question is only ever
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) manipulated from a "process context", ie no interrupts involved.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) The reasons you mustn't use these versions if you have interrupts that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122) play with the spinlock is that you can get deadlocks::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) spin_lock(&lock);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125) ...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126) <- interrupt comes in:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127) spin_lock(&lock);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) where an interrupt tries to lock an already locked variable. This is ok if
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130) the other interrupt happens on another CPU, but it is _not_ ok if the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) interrupt happens on the same CPU that already holds the lock, because the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132) lock will obviously never be released (because the interrupt is waiting
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) for the lock, and the lock-holder is interrupted by the interrupt and will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) not continue until the interrupt has been processed).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136) (This is also the reason why the irq-versions of the spinlocks only need
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137) to disable the _local_ interrupts - it's ok to use spinlocks in interrupts
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138) on other CPU's, because an interrupt on another CPU doesn't interrupt the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139) CPU that holds the lock, so the lock-holder can continue and eventually
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140) releases the lock).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142) Linus
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) ----
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146) Reference information:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) ======================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149) For dynamic initialization, use spin_lock_init() or rwlock_init() as
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150) appropriate::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) spinlock_t xxx_lock;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) rwlock_t xxx_rw_lock;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) static int __init xxx_init(void)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156) {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) spin_lock_init(&xxx_lock);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158) rwlock_init(&xxx_rw_lock);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) ...
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160) }
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162) module_init(xxx_init);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) For static initialization, use DEFINE_SPINLOCK() / DEFINE_RWLOCK() or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) __SPIN_LOCK_UNLOCKED() / __RW_LOCK_UNLOCKED() as appropriate.
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags