blob: 1fd175368a875107892f72f412a980e9a93f7d77 [file] [log] [blame]
Linus Torvalds1da177e2005-04-16 15:20:36 -07001Using RCU to Protect Read-Mostly Linked Lists
2
3
4One of the best applications of RCU is to protect read-mostly linked lists
5("struct list_head" in list.h). One big advantage of this approach
6is that all of the required memory barriers are included for you in
7the list macros. This document describes several applications of RCU,
8with the best fits first.
9
10
11Example 1: Read-Side Action Taken Outside of Lock, No In-Place Updates
12
13The best applications are cases where, if reader-writer locking were
14used, the read-side lock would be dropped before taking any action
15based on the results of the search. The most celebrated example is
16the routing table. Because the routing table is tracking the state of
17equipment outside of the computer, it will at times contain stale data.
18Therefore, once the route has been computed, there is no need to hold
19the routing table static during transmission of the packet. After all,
20you can hold the routing table static all you want, but that won't keep
21the external Internet from changing, and it is the state of the external
22Internet that really matters. In addition, routing entries are typically
23added or deleted, rather than being modified in place.
24
25A straightforward example of this use of RCU may be found in the
26system-call auditing support. For example, a reader-writer locked
27implementation of audit_filter_task() might be as follows:
28
29 static enum audit_state audit_filter_task(struct task_struct *tsk)
30 {
31 struct audit_entry *e;
32 enum audit_state state;
33
34 read_lock(&auditsc_lock);
Paul E. McKenneya83f1fe2005-05-01 08:59:05 -070035 /* Note: audit_netlink_sem held by caller. */
Linus Torvalds1da177e2005-04-16 15:20:36 -070036 list_for_each_entry(e, &audit_tsklist, list) {
37 if (audit_filter_rules(tsk, &e->rule, NULL, &state)) {
38 read_unlock(&auditsc_lock);
39 return state;
40 }
41 }
42 read_unlock(&auditsc_lock);
43 return AUDIT_BUILD_CONTEXT;
44 }
45
46Here the list is searched under the lock, but the lock is dropped before
47the corresponding value is returned. By the time that this value is acted
48on, the list may well have been modified. This makes sense, since if
49you are turning auditing off, it is OK to audit a few extra system calls.
50
51This means that RCU can be easily applied to the read side, as follows:
52
53 static enum audit_state audit_filter_task(struct task_struct *tsk)
54 {
55 struct audit_entry *e;
56 enum audit_state state;
57
58 rcu_read_lock();
Paul E. McKenneya83f1fe2005-05-01 08:59:05 -070059 /* Note: audit_netlink_sem held by caller. */
Linus Torvalds1da177e2005-04-16 15:20:36 -070060 list_for_each_entry_rcu(e, &audit_tsklist, list) {
61 if (audit_filter_rules(tsk, &e->rule, NULL, &state)) {
62 rcu_read_unlock();
63 return state;
64 }
65 }
66 rcu_read_unlock();
67 return AUDIT_BUILD_CONTEXT;
68 }
69
70The read_lock() and read_unlock() calls have become rcu_read_lock()
71and rcu_read_unlock(), respectively, and the list_for_each_entry() has
72become list_for_each_entry_rcu(). The _rcu() list-traversal primitives
73insert the read-side memory barriers that are required on DEC Alpha CPUs.
74
75The changes to the update side are also straightforward. A reader-writer
76lock might be used as follows for deletion and insertion:
77
78 static inline int audit_del_rule(struct audit_rule *rule,
79 struct list_head *list)
80 {
81 struct audit_entry *e;
82
83 write_lock(&auditsc_lock);
84 list_for_each_entry(e, list, list) {
85 if (!audit_compare_rule(rule, &e->rule)) {
86 list_del(&e->list);
87 write_unlock(&auditsc_lock);
88 return 0;
89 }
90 }
91 write_unlock(&auditsc_lock);
92 return -EFAULT; /* No matching rule */
93 }
94
95 static inline int audit_add_rule(struct audit_entry *entry,
96 struct list_head *list)
97 {
98 write_lock(&auditsc_lock);
99 if (entry->rule.flags & AUDIT_PREPEND) {
100 entry->rule.flags &= ~AUDIT_PREPEND;
101 list_add(&entry->list, list);
102 } else {
103 list_add_tail(&entry->list, list);
104 }
105 write_unlock(&auditsc_lock);
106 return 0;
107 }
108
109Following are the RCU equivalents for these two functions:
110
111 static inline int audit_del_rule(struct audit_rule *rule,
112 struct list_head *list)
113 {
114 struct audit_entry *e;
115
116 /* Do not use the _rcu iterator here, since this is the only
117 * deletion routine. */
118 list_for_each_entry(e, list, list) {
119 if (!audit_compare_rule(rule, &e->rule)) {
120 list_del_rcu(&e->list);
121 call_rcu(&e->rcu, audit_free_rule, e);
122 return 0;
123 }
124 }
125 return -EFAULT; /* No matching rule */
126 }
127
128 static inline int audit_add_rule(struct audit_entry *entry,
129 struct list_head *list)
130 {
131 if (entry->rule.flags & AUDIT_PREPEND) {
132 entry->rule.flags &= ~AUDIT_PREPEND;
133 list_add_rcu(&entry->list, list);
134 } else {
135 list_add_tail_rcu(&entry->list, list);
136 }
137 return 0;
138 }
139
140Normally, the write_lock() and write_unlock() would be replaced by
141a spin_lock() and a spin_unlock(), but in this case, all callers hold
142audit_netlink_sem, so no additional locking is required. The auditsc_lock
143can therefore be eliminated, since use of RCU eliminates the need for
Paul E. McKenneya83f1fe2005-05-01 08:59:05 -0700144writers to exclude readers. Normally, the write_lock() calls would
145be converted into spin_lock() calls.
Linus Torvalds1da177e2005-04-16 15:20:36 -0700146
147The list_del(), list_add(), and list_add_tail() primitives have been
148replaced by list_del_rcu(), list_add_rcu(), and list_add_tail_rcu().
149The _rcu() list-manipulation primitives add memory barriers that are
Paul E. McKenneya83f1fe2005-05-01 08:59:05 -0700150needed on weakly ordered CPUs (most of them!). The list_del_rcu()
151primitive omits the pointer poisoning debug-assist code that would
152otherwise cause concurrent readers to fail spectacularly.
Linus Torvalds1da177e2005-04-16 15:20:36 -0700153
154So, when readers can tolerate stale data and when entries are either added
155or deleted, without in-place modification, it is very easy to use RCU!
156
157
158Example 2: Handling In-Place Updates
159
160The system-call auditing code does not update auditing rules in place.
161However, if it did, reader-writer-locked code to do so might look as
162follows (presumably, the field_count is only permitted to decrease,
163otherwise, the added fields would need to be filled in):
164
165 static inline int audit_upd_rule(struct audit_rule *rule,
166 struct list_head *list,
167 __u32 newaction,
168 __u32 newfield_count)
169 {
170 struct audit_entry *e;
171 struct audit_newentry *ne;
172
173 write_lock(&auditsc_lock);
Paul E. McKenneya83f1fe2005-05-01 08:59:05 -0700174 /* Note: audit_netlink_sem held by caller. */
Linus Torvalds1da177e2005-04-16 15:20:36 -0700175 list_for_each_entry(e, list, list) {
176 if (!audit_compare_rule(rule, &e->rule)) {
177 e->rule.action = newaction;
178 e->rule.file_count = newfield_count;
179 write_unlock(&auditsc_lock);
180 return 0;
181 }
182 }
183 write_unlock(&auditsc_lock);
184 return -EFAULT; /* No matching rule */
185 }
186
187The RCU version creates a copy, updates the copy, then replaces the old
188entry with the newly updated entry. This sequence of actions, allowing
189concurrent reads while doing a copy to perform an update, is what gives
190RCU ("read-copy update") its name. The RCU code is as follows:
191
192 static inline int audit_upd_rule(struct audit_rule *rule,
193 struct list_head *list,
194 __u32 newaction,
195 __u32 newfield_count)
196 {
197 struct audit_entry *e;
198 struct audit_newentry *ne;
199
200 list_for_each_entry(e, list, list) {
201 if (!audit_compare_rule(rule, &e->rule)) {
202 ne = kmalloc(sizeof(*entry), GFP_ATOMIC);
203 if (ne == NULL)
204 return -ENOMEM;
205 audit_copy_rule(&ne->rule, &e->rule);
206 ne->rule.action = newaction;
207 ne->rule.file_count = newfield_count;
Paul E. McKenneya83f1fe2005-05-01 08:59:05 -0700208 list_replace_rcu(e, ne);
Linus Torvalds1da177e2005-04-16 15:20:36 -0700209 call_rcu(&e->rcu, audit_free_rule, e);
210 return 0;
211 }
212 }
213 return -EFAULT; /* No matching rule */
214 }
215
216Again, this assumes that the caller holds audit_netlink_sem. Normally,
217the reader-writer lock would become a spinlock in this sort of code.
218
219
220Example 3: Eliminating Stale Data
221
222The auditing examples above tolerate stale data, as do most algorithms
223that are tracking external state. Because there is a delay from the
224time the external state changes before Linux becomes aware of the change,
225additional RCU-induced staleness is normally not a problem.
226
227However, there are many examples where stale data cannot be tolerated.
228One example in the Linux kernel is the System V IPC (see the ipc_lock()
229function in ipc/util.c). This code checks a "deleted" flag under a
230per-entry spinlock, and, if the "deleted" flag is set, pretends that the
231entry does not exist. For this to be helpful, the search function must
232return holding the per-entry spinlock, as ipc_lock() does in fact do.
233
234Quick Quiz: Why does the search function need to return holding the
Paul E. McKenneyd19720a2006-02-01 03:06:42 -0800235 per-entry lock for this deleted-flag technique to be helpful?
Linus Torvalds1da177e2005-04-16 15:20:36 -0700236
237If the system-call audit module were to ever need to reject stale data,
238one way to accomplish this would be to add a "deleted" flag and a "lock"
239spinlock to the audit_entry structure, and modify audit_filter_task()
240as follows:
241
242 static enum audit_state audit_filter_task(struct task_struct *tsk)
243 {
244 struct audit_entry *e;
245 enum audit_state state;
246
247 rcu_read_lock();
248 list_for_each_entry_rcu(e, &audit_tsklist, list) {
249 if (audit_filter_rules(tsk, &e->rule, NULL, &state)) {
250 spin_lock(&e->lock);
251 if (e->deleted) {
252 spin_unlock(&e->lock);
253 rcu_read_unlock();
254 return AUDIT_BUILD_CONTEXT;
255 }
256 rcu_read_unlock();
257 return state;
258 }
259 }
260 rcu_read_unlock();
261 return AUDIT_BUILD_CONTEXT;
262 }
263
264Note that this example assumes that entries are only added and deleted.
265Additional mechanism is required to deal correctly with the
266update-in-place performed by audit_upd_rule(). For one thing,
267audit_upd_rule() would need additional memory barriers to ensure
268that the list_add_rcu() was really executed before the list_del_rcu().
269
270The audit_del_rule() function would need to set the "deleted"
271flag under the spinlock as follows:
272
273 static inline int audit_del_rule(struct audit_rule *rule,
274 struct list_head *list)
275 {
276 struct audit_entry *e;
277
Paul E. McKenneyd19720a2006-02-01 03:06:42 -0800278 /* Do not need to use the _rcu iterator here, since this
279 * is the only deletion routine. */
Linus Torvalds1da177e2005-04-16 15:20:36 -0700280 list_for_each_entry(e, list, list) {
281 if (!audit_compare_rule(rule, &e->rule)) {
282 spin_lock(&e->lock);
283 list_del_rcu(&e->list);
284 e->deleted = 1;
285 spin_unlock(&e->lock);
286 call_rcu(&e->rcu, audit_free_rule, e);
287 return 0;
288 }
289 }
290 return -EFAULT; /* No matching rule */
291 }
292
293
294Summary
295
296Read-mostly list-based data structures that can tolerate stale data are
297the most amenable to use of RCU. The simplest case is where entries are
298either added or deleted from the data structure (or atomically modified
299in place), but non-atomic in-place modifications can be handled by making
300a copy, updating the copy, then replacing the original with the copy.
301If stale data cannot be tolerated, then a "deleted" flag may be used
302in conjunction with a per-entry spinlock in order to allow the search
303function to reject newly deleted data.
304
305
306Answer to Quick Quiz
Paul E. McKenneyd19720a2006-02-01 03:06:42 -0800307 Why does the search function need to return holding the per-entry
308 lock for this deleted-flag technique to be helpful?
Linus Torvalds1da177e2005-04-16 15:20:36 -0700309
Paul E. McKenneyd19720a2006-02-01 03:06:42 -0800310 If the search function drops the per-entry lock before returning,
311 then the caller will be processing stale data in any case. If it
312 is really OK to be processing stale data, then you don't need a
313 "deleted" flag. If processing stale data really is a problem,
314 then you need to hold the per-entry lock across all of the code
315 that uses the value that was returned.