xref: /openbmc/linux/Documentation/locking/spinlocks.rst (revision 8dd06ef34b6e2f41b29fbf5fc1663780f2524285)
1387b1468SMauro Carvalho Chehab===============
2387b1468SMauro Carvalho ChehabLocking lessons
3387b1468SMauro Carvalho Chehab===============
4387b1468SMauro Carvalho Chehab
5387b1468SMauro Carvalho ChehabLesson 1: Spin locks
6387b1468SMauro Carvalho Chehab====================
7387b1468SMauro Carvalho Chehab
8387b1468SMauro Carvalho ChehabThe most basic primitive for locking is spinlock::
9387b1468SMauro Carvalho Chehab
10387b1468SMauro Carvalho Chehab  static DEFINE_SPINLOCK(xxx_lock);
11387b1468SMauro Carvalho Chehab
12387b1468SMauro Carvalho Chehab	unsigned long flags;
13387b1468SMauro Carvalho Chehab
14387b1468SMauro Carvalho Chehab	spin_lock_irqsave(&xxx_lock, flags);
15387b1468SMauro Carvalho Chehab	... critical section here ..
16387b1468SMauro Carvalho Chehab	spin_unlock_irqrestore(&xxx_lock, flags);
17387b1468SMauro Carvalho Chehab
18387b1468SMauro Carvalho ChehabThe above is always safe. It will disable interrupts _locally_, but the
19387b1468SMauro Carvalho Chehabspinlock itself will guarantee the global lock, so it will guarantee that
20387b1468SMauro Carvalho Chehabthere is only one thread-of-control within the region(s) protected by that
21387b1468SMauro Carvalho Chehablock. This works well even under UP also, so the code does _not_ need to
22387b1468SMauro Carvalho Chehabworry about UP vs SMP issues: the spinlocks work correctly under both.
23387b1468SMauro Carvalho Chehab
24387b1468SMauro Carvalho Chehab   NOTE! Implications of spin_locks for memory are further described in:
25387b1468SMauro Carvalho Chehab
26387b1468SMauro Carvalho Chehab     Documentation/memory-barriers.txt
27387b1468SMauro Carvalho Chehab
28*4bfdebd6SSeongJae Park       (5) ACQUIRE operations.
29387b1468SMauro Carvalho Chehab
30*4bfdebd6SSeongJae Park       (6) RELEASE operations.
31387b1468SMauro Carvalho Chehab
32387b1468SMauro Carvalho ChehabThe above is usually pretty simple (you usually need and want only one
33387b1468SMauro Carvalho Chehabspinlock for most things - using more than one spinlock can make things a
34387b1468SMauro Carvalho Chehablot more complex and even slower and is usually worth it only for
35387b1468SMauro Carvalho Chehabsequences that you **know** need to be split up: avoid it at all cost if you
36387b1468SMauro Carvalho Chehabaren't sure).
37387b1468SMauro Carvalho Chehab
38387b1468SMauro Carvalho ChehabThis is really the only really hard part about spinlocks: once you start
39387b1468SMauro Carvalho Chehabusing spinlocks they tend to expand to areas you might not have noticed
40387b1468SMauro Carvalho Chehabbefore, because you have to make sure the spinlocks correctly protect the
41387b1468SMauro Carvalho Chehabshared data structures **everywhere** they are used. The spinlocks are most
42387b1468SMauro Carvalho Chehabeasily added to places that are completely independent of other code (for
43387b1468SMauro Carvalho Chehabexample, internal driver data structures that nobody else ever touches).
44387b1468SMauro Carvalho Chehab
45387b1468SMauro Carvalho Chehab   NOTE! The spin-lock is safe only when you **also** use the lock itself
46387b1468SMauro Carvalho Chehab   to do locking across CPU's, which implies that EVERYTHING that
47387b1468SMauro Carvalho Chehab   touches a shared variable has to agree about the spinlock they want
48387b1468SMauro Carvalho Chehab   to use.
49387b1468SMauro Carvalho Chehab
50387b1468SMauro Carvalho Chehab----
51387b1468SMauro Carvalho Chehab
52387b1468SMauro Carvalho ChehabLesson 2: reader-writer spinlocks.
53387b1468SMauro Carvalho Chehab==================================
54387b1468SMauro Carvalho Chehab
55387b1468SMauro Carvalho ChehabIf your data accesses have a very natural pattern where you usually tend
56387b1468SMauro Carvalho Chehabto mostly read from the shared variables, the reader-writer locks
57387b1468SMauro Carvalho Chehab(rw_lock) versions of the spinlocks are sometimes useful. They allow multiple
58387b1468SMauro Carvalho Chehabreaders to be in the same critical region at once, but if somebody wants
59387b1468SMauro Carvalho Chehabto change the variables it has to get an exclusive write lock.
60387b1468SMauro Carvalho Chehab
61387b1468SMauro Carvalho Chehab   NOTE! reader-writer locks require more atomic memory operations than
62387b1468SMauro Carvalho Chehab   simple spinlocks.  Unless the reader critical section is long, you
63387b1468SMauro Carvalho Chehab   are better off just using spinlocks.
64387b1468SMauro Carvalho Chehab
65387b1468SMauro Carvalho ChehabThe routines look the same as above::
66387b1468SMauro Carvalho Chehab
67387b1468SMauro Carvalho Chehab   rwlock_t xxx_lock = __RW_LOCK_UNLOCKED(xxx_lock);
68387b1468SMauro Carvalho Chehab
69387b1468SMauro Carvalho Chehab	unsigned long flags;
70387b1468SMauro Carvalho Chehab
71387b1468SMauro Carvalho Chehab	read_lock_irqsave(&xxx_lock, flags);
72387b1468SMauro Carvalho Chehab	.. critical section that only reads the info ...
73387b1468SMauro Carvalho Chehab	read_unlock_irqrestore(&xxx_lock, flags);
74387b1468SMauro Carvalho Chehab
75387b1468SMauro Carvalho Chehab	write_lock_irqsave(&xxx_lock, flags);
76387b1468SMauro Carvalho Chehab	.. read and write exclusive access to the info ...
77387b1468SMauro Carvalho Chehab	write_unlock_irqrestore(&xxx_lock, flags);
78387b1468SMauro Carvalho Chehab
79387b1468SMauro Carvalho ChehabThe above kind of lock may be useful for complex data structures like
80387b1468SMauro Carvalho Chehablinked lists, especially searching for entries without changing the list
81387b1468SMauro Carvalho Chehabitself.  The read lock allows many concurrent readers.  Anything that
82387b1468SMauro Carvalho Chehab**changes** the list will have to get the write lock.
83387b1468SMauro Carvalho Chehab
84387b1468SMauro Carvalho Chehab   NOTE! RCU is better for list traversal, but requires careful
85bff9e34cSMauro Carvalho Chehab   attention to design detail (see Documentation/RCU/listRCU.rst).
86387b1468SMauro Carvalho Chehab
87387b1468SMauro Carvalho ChehabAlso, you cannot "upgrade" a read-lock to a write-lock, so if you at _any_
88387b1468SMauro Carvalho Chehabtime need to do any changes (even if you don't do it every time), you have
89387b1468SMauro Carvalho Chehabto get the write-lock at the very beginning.
90387b1468SMauro Carvalho Chehab
91387b1468SMauro Carvalho Chehab   NOTE! We are working hard to remove reader-writer spinlocks in most
92387b1468SMauro Carvalho Chehab   cases, so please don't add a new one without consensus.  (Instead, see
93bff9e34cSMauro Carvalho Chehab   Documentation/RCU/rcu.rst for complete information.)
94387b1468SMauro Carvalho Chehab
95387b1468SMauro Carvalho Chehab----
96387b1468SMauro Carvalho Chehab
97387b1468SMauro Carvalho ChehabLesson 3: spinlocks revisited.
98387b1468SMauro Carvalho Chehab==============================
99387b1468SMauro Carvalho Chehab
100387b1468SMauro Carvalho ChehabThe single spin-lock primitives above are by no means the only ones. They
101387b1468SMauro Carvalho Chehabare the most safe ones, and the ones that work under all circumstances,
102387b1468SMauro Carvalho Chehabbut partly **because** they are safe they are also fairly slow. They are slower
103387b1468SMauro Carvalho Chehabthan they'd need to be, because they do have to disable interrupts
104387b1468SMauro Carvalho Chehab(which is just a single instruction on a x86, but it's an expensive one -
105387b1468SMauro Carvalho Chehaband on other architectures it can be worse).
106387b1468SMauro Carvalho Chehab
107387b1468SMauro Carvalho ChehabIf you have a case where you have to protect a data structure across
108387b1468SMauro Carvalho Chehabseveral CPU's and you want to use spinlocks you can potentially use
109387b1468SMauro Carvalho Chehabcheaper versions of the spinlocks. IFF you know that the spinlocks are
110387b1468SMauro Carvalho Chehabnever used in interrupt handlers, you can use the non-irq versions::
111387b1468SMauro Carvalho Chehab
112387b1468SMauro Carvalho Chehab	spin_lock(&lock);
113387b1468SMauro Carvalho Chehab	...
114387b1468SMauro Carvalho Chehab	spin_unlock(&lock);
115387b1468SMauro Carvalho Chehab
116387b1468SMauro Carvalho Chehab(and the equivalent read-write versions too, of course). The spinlock will
117387b1468SMauro Carvalho Chehabguarantee the same kind of exclusive access, and it will be much faster.
118387b1468SMauro Carvalho ChehabThis is useful if you know that the data in question is only ever
119387b1468SMauro Carvalho Chehabmanipulated from a "process context", ie no interrupts involved.
120387b1468SMauro Carvalho Chehab
121387b1468SMauro Carvalho ChehabThe reasons you mustn't use these versions if you have interrupts that
122387b1468SMauro Carvalho Chehabplay with the spinlock is that you can get deadlocks::
123387b1468SMauro Carvalho Chehab
124387b1468SMauro Carvalho Chehab	spin_lock(&lock);
125387b1468SMauro Carvalho Chehab	...
126387b1468SMauro Carvalho Chehab		<- interrupt comes in:
127387b1468SMauro Carvalho Chehab			spin_lock(&lock);
128387b1468SMauro Carvalho Chehab
129387b1468SMauro Carvalho Chehabwhere an interrupt tries to lock an already locked variable. This is ok if
130387b1468SMauro Carvalho Chehabthe other interrupt happens on another CPU, but it is _not_ ok if the
131387b1468SMauro Carvalho Chehabinterrupt happens on the same CPU that already holds the lock, because the
132387b1468SMauro Carvalho Chehablock will obviously never be released (because the interrupt is waiting
133387b1468SMauro Carvalho Chehabfor the lock, and the lock-holder is interrupted by the interrupt and will
134387b1468SMauro Carvalho Chehabnot continue until the interrupt has been processed).
135387b1468SMauro Carvalho Chehab
136387b1468SMauro Carvalho Chehab(This is also the reason why the irq-versions of the spinlocks only need
137387b1468SMauro Carvalho Chehabto disable the _local_ interrupts - it's ok to use spinlocks in interrupts
138387b1468SMauro Carvalho Chehabon other CPU's, because an interrupt on another CPU doesn't interrupt the
139387b1468SMauro Carvalho ChehabCPU that holds the lock, so the lock-holder can continue and eventually
140387b1468SMauro Carvalho Chehabreleases the lock).
141387b1468SMauro Carvalho Chehab
142387b1468SMauro Carvalho Chehab		Linus
143387b1468SMauro Carvalho Chehab
144387b1468SMauro Carvalho Chehab----
145387b1468SMauro Carvalho Chehab
146387b1468SMauro Carvalho ChehabReference information:
147387b1468SMauro Carvalho Chehab======================
148387b1468SMauro Carvalho Chehab
149387b1468SMauro Carvalho ChehabFor dynamic initialization, use spin_lock_init() or rwlock_init() as
150387b1468SMauro Carvalho Chehabappropriate::
151387b1468SMauro Carvalho Chehab
152387b1468SMauro Carvalho Chehab   spinlock_t xxx_lock;
153387b1468SMauro Carvalho Chehab   rwlock_t xxx_rw_lock;
154387b1468SMauro Carvalho Chehab
155387b1468SMauro Carvalho Chehab   static int __init xxx_init(void)
156387b1468SMauro Carvalho Chehab   {
157387b1468SMauro Carvalho Chehab	spin_lock_init(&xxx_lock);
158387b1468SMauro Carvalho Chehab	rwlock_init(&xxx_rw_lock);
159387b1468SMauro Carvalho Chehab	...
160387b1468SMauro Carvalho Chehab   }
161387b1468SMauro Carvalho Chehab
162387b1468SMauro Carvalho Chehab   module_init(xxx_init);
163387b1468SMauro Carvalho Chehab
164387b1468SMauro Carvalho ChehabFor static initialization, use DEFINE_SPINLOCK() / DEFINE_RWLOCK() or
165387b1468SMauro Carvalho Chehab__SPIN_LOCK_UNLOCKED() / __RW_LOCK_UNLOCKED() as appropriate.
166