listRCU.rst 16 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468
  1. .. _list_rcu_doc:
  2. Using RCU to Protect Read-Mostly Linked Lists
  3. =============================================
  4. One 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
  6. is that all of the required memory barriers are included for you in
  7. the list macros. This document describes several applications of RCU,
  8. with the best fits first.
  9. Example 1: Read-mostly list: Deferred Destruction
  10. -------------------------------------------------
  11. A widely used usecase for RCU lists in the kernel is lockless iteration over
  12. all processes in the system. ``task_struct::tasks`` represents the list node that
  13. links all the processes. The list can be traversed in parallel to any list
  14. additions or removals.
  15. The traversal of the list is done using ``for_each_process()`` which is defined
  16. by the 2 macros::
  17. #define next_task(p) \
  18. list_entry_rcu((p)->tasks.next, struct task_struct, tasks)
  19. #define for_each_process(p) \
  20. for (p = &init_task ; (p = next_task(p)) != &init_task ; )
  21. The code traversing the list of all processes typically looks like::
  22. rcu_read_lock();
  23. for_each_process(p) {
  24. /* Do something with p */
  25. }
  26. rcu_read_unlock();
  27. The simplified code for removing a process from a task list is::
  28. void release_task(struct task_struct *p)
  29. {
  30. write_lock(&tasklist_lock);
  31. list_del_rcu(&p->tasks);
  32. write_unlock(&tasklist_lock);
  33. call_rcu(&p->rcu, delayed_put_task_struct);
  34. }
  35. When a process exits, ``release_task()`` calls ``list_del_rcu(&p->tasks)`` under
  36. ``tasklist_lock`` writer lock protection, to remove the task from the list of
  37. all tasks. The ``tasklist_lock`` prevents concurrent list additions/removals
  38. from corrupting the list. Readers using ``for_each_process()`` are not protected
  39. with the ``tasklist_lock``. To prevent readers from noticing changes in the list
  40. pointers, the ``task_struct`` object is freed only after one or more grace
  41. periods elapse (with the help of call_rcu()). This deferring of destruction
  42. ensures that any readers traversing the list will see valid ``p->tasks.next``
  43. pointers and deletion/freeing can happen in parallel with traversal of the list.
  44. This pattern is also called an **existence lock**, since RCU pins the object in
  45. memory until all existing readers finish.
  46. Example 2: Read-Side Action Taken Outside of Lock: No In-Place Updates
  47. ----------------------------------------------------------------------
  48. The best applications are cases where, if reader-writer locking were
  49. used, the read-side lock would be dropped before taking any action
  50. based on the results of the search. The most celebrated example is
  51. the routing table. Because the routing table is tracking the state of
  52. equipment outside of the computer, it will at times contain stale data.
  53. Therefore, once the route has been computed, there is no need to hold
  54. the routing table static during transmission of the packet. After all,
  55. you can hold the routing table static all you want, but that won't keep
  56. the external Internet from changing, and it is the state of the external
  57. Internet that really matters. In addition, routing entries are typically
  58. added or deleted, rather than being modified in place.
  59. A straightforward example of this use of RCU may be found in the
  60. system-call auditing support. For example, a reader-writer locked
  61. implementation of ``audit_filter_task()`` might be as follows::
  62. static enum audit_state audit_filter_task(struct task_struct *tsk)
  63. {
  64. struct audit_entry *e;
  65. enum audit_state state;
  66. read_lock(&auditsc_lock);
  67. /* Note: audit_filter_mutex held by caller. */
  68. list_for_each_entry(e, &audit_tsklist, list) {
  69. if (audit_filter_rules(tsk, &e->rule, NULL, &state)) {
  70. read_unlock(&auditsc_lock);
  71. return state;
  72. }
  73. }
  74. read_unlock(&auditsc_lock);
  75. return AUDIT_BUILD_CONTEXT;
  76. }
  77. Here the list is searched under the lock, but the lock is dropped before
  78. the corresponding value is returned. By the time that this value is acted
  79. on, the list may well have been modified. This makes sense, since if
  80. you are turning auditing off, it is OK to audit a few extra system calls.
  81. This means that RCU can be easily applied to the read side, as follows::
  82. static enum audit_state audit_filter_task(struct task_struct *tsk)
  83. {
  84. struct audit_entry *e;
  85. enum audit_state state;
  86. rcu_read_lock();
  87. /* Note: audit_filter_mutex held by caller. */
  88. list_for_each_entry_rcu(e, &audit_tsklist, list) {
  89. if (audit_filter_rules(tsk, &e->rule, NULL, &state)) {
  90. rcu_read_unlock();
  91. return state;
  92. }
  93. }
  94. rcu_read_unlock();
  95. return AUDIT_BUILD_CONTEXT;
  96. }
  97. The ``read_lock()`` and ``read_unlock()`` calls have become rcu_read_lock()
  98. and rcu_read_unlock(), respectively, and the list_for_each_entry() has
  99. become list_for_each_entry_rcu(). The **_rcu()** list-traversal primitives
  100. insert the read-side memory barriers that are required on DEC Alpha CPUs.
  101. The changes to the update side are also straightforward. A reader-writer lock
  102. might be used as follows for deletion and insertion::
  103. static inline int audit_del_rule(struct audit_rule *rule,
  104. struct list_head *list)
  105. {
  106. struct audit_entry *e;
  107. write_lock(&auditsc_lock);
  108. list_for_each_entry(e, list, list) {
  109. if (!audit_compare_rule(rule, &e->rule)) {
  110. list_del(&e->list);
  111. write_unlock(&auditsc_lock);
  112. return 0;
  113. }
  114. }
  115. write_unlock(&auditsc_lock);
  116. return -EFAULT; /* No matching rule */
  117. }
  118. static inline int audit_add_rule(struct audit_entry *entry,
  119. struct list_head *list)
  120. {
  121. write_lock(&auditsc_lock);
  122. if (entry->rule.flags & AUDIT_PREPEND) {
  123. entry->rule.flags &= ~AUDIT_PREPEND;
  124. list_add(&entry->list, list);
  125. } else {
  126. list_add_tail(&entry->list, list);
  127. }
  128. write_unlock(&auditsc_lock);
  129. return 0;
  130. }
  131. Following are the RCU equivalents for these two functions::
  132. static inline int audit_del_rule(struct audit_rule *rule,
  133. struct list_head *list)
  134. {
  135. struct audit_entry *e;
  136. /* No need to use the _rcu iterator here, since this is the only
  137. * deletion routine. */
  138. list_for_each_entry(e, list, list) {
  139. if (!audit_compare_rule(rule, &e->rule)) {
  140. list_del_rcu(&e->list);
  141. call_rcu(&e->rcu, audit_free_rule);
  142. return 0;
  143. }
  144. }
  145. return -EFAULT; /* No matching rule */
  146. }
  147. static inline int audit_add_rule(struct audit_entry *entry,
  148. struct list_head *list)
  149. {
  150. if (entry->rule.flags & AUDIT_PREPEND) {
  151. entry->rule.flags &= ~AUDIT_PREPEND;
  152. list_add_rcu(&entry->list, list);
  153. } else {
  154. list_add_tail_rcu(&entry->list, list);
  155. }
  156. return 0;
  157. }
  158. Normally, the ``write_lock()`` and ``write_unlock()`` would be replaced by a
  159. spin_lock() and a spin_unlock(). But in this case, all callers hold
  160. ``audit_filter_mutex``, so no additional locking is required. The
  161. ``auditsc_lock`` can therefore be eliminated, since use of RCU eliminates the
  162. need for writers to exclude readers.
  163. The list_del(), list_add(), and list_add_tail() primitives have been
  164. replaced by list_del_rcu(), list_add_rcu(), and list_add_tail_rcu().
  165. The **_rcu()** list-manipulation primitives add memory barriers that are needed on
  166. weakly ordered CPUs (most of them!). The list_del_rcu() primitive omits the
  167. pointer poisoning debug-assist code that would otherwise cause concurrent
  168. readers to fail spectacularly.
  169. So, when readers can tolerate stale data and when entries are either added or
  170. deleted, without in-place modification, it is very easy to use RCU!
  171. Example 3: Handling In-Place Updates
  172. ------------------------------------
  173. The system-call auditing code does not update auditing rules in place. However,
  174. if it did, the reader-writer-locked code to do so might look as follows
  175. (assuming only ``field_count`` is updated, otherwise, the added fields would
  176. need to be filled in)::
  177. static inline int audit_upd_rule(struct audit_rule *rule,
  178. struct list_head *list,
  179. __u32 newaction,
  180. __u32 newfield_count)
  181. {
  182. struct audit_entry *e;
  183. struct audit_entry *ne;
  184. write_lock(&auditsc_lock);
  185. /* Note: audit_filter_mutex held by caller. */
  186. list_for_each_entry(e, list, list) {
  187. if (!audit_compare_rule(rule, &e->rule)) {
  188. e->rule.action = newaction;
  189. e->rule.field_count = newfield_count;
  190. write_unlock(&auditsc_lock);
  191. return 0;
  192. }
  193. }
  194. write_unlock(&auditsc_lock);
  195. return -EFAULT; /* No matching rule */
  196. }
  197. The RCU version creates a copy, updates the copy, then replaces the old
  198. entry with the newly updated entry. This sequence of actions, allowing
  199. concurrent reads while making a copy to perform an update, is what gives
  200. RCU (*read-copy update*) its name. The RCU code is as follows::
  201. static inline int audit_upd_rule(struct audit_rule *rule,
  202. struct list_head *list,
  203. __u32 newaction,
  204. __u32 newfield_count)
  205. {
  206. struct audit_entry *e;
  207. struct audit_entry *ne;
  208. list_for_each_entry(e, list, list) {
  209. if (!audit_compare_rule(rule, &e->rule)) {
  210. ne = kmalloc(sizeof(*entry), GFP_ATOMIC);
  211. if (ne == NULL)
  212. return -ENOMEM;
  213. audit_copy_rule(&ne->rule, &e->rule);
  214. ne->rule.action = newaction;
  215. ne->rule.field_count = newfield_count;
  216. list_replace_rcu(&e->list, &ne->list);
  217. call_rcu(&e->rcu, audit_free_rule);
  218. return 0;
  219. }
  220. }
  221. return -EFAULT; /* No matching rule */
  222. }
  223. Again, this assumes that the caller holds ``audit_filter_mutex``. Normally, the
  224. writer lock would become a spinlock in this sort of code.
  225. Another use of this pattern can be found in the openswitch driver's *connection
  226. tracking table* code in ``ct_limit_set()``. The table holds connection tracking
  227. entries and has a limit on the maximum entries. There is one such table
  228. per-zone and hence one *limit* per zone. The zones are mapped to their limits
  229. through a hashtable using an RCU-managed hlist for the hash chains. When a new
  230. limit is set, a new limit object is allocated and ``ct_limit_set()`` is called
  231. to replace the old limit object with the new one using list_replace_rcu().
  232. The old limit object is then freed after a grace period using kfree_rcu().
  233. Example 4: Eliminating Stale Data
  234. ---------------------------------
  235. The auditing example above tolerates stale data, as do most algorithms
  236. that are tracking external state. Because there is a delay from the
  237. time the external state changes before Linux becomes aware of the change,
  238. additional RCU-induced staleness is generally not a problem.
  239. However, there are many examples where stale data cannot be tolerated.
  240. One example in the Linux kernel is the System V IPC (see the shm_lock()
  241. function in ipc/shm.c). This code checks a *deleted* flag under a
  242. per-entry spinlock, and, if the *deleted* flag is set, pretends that the
  243. entry does not exist. For this to be helpful, the search function must
  244. return holding the per-entry spinlock, as shm_lock() does in fact do.
  245. .. _quick_quiz:
  246. Quick Quiz:
  247. For the deleted-flag technique to be helpful, why is it necessary
  248. to hold the per-entry lock while returning from the search function?
  249. :ref:`Answer to Quick Quiz <quick_quiz_answer>`
  250. If the system-call audit module were to ever need to reject stale data, one way
  251. to accomplish this would be to add a ``deleted`` flag and a ``lock`` spinlock to the
  252. audit_entry structure, and modify ``audit_filter_task()`` as follows::
  253. static enum audit_state audit_filter_task(struct task_struct *tsk)
  254. {
  255. struct audit_entry *e;
  256. enum audit_state state;
  257. rcu_read_lock();
  258. list_for_each_entry_rcu(e, &audit_tsklist, list) {
  259. if (audit_filter_rules(tsk, &e->rule, NULL, &state)) {
  260. spin_lock(&e->lock);
  261. if (e->deleted) {
  262. spin_unlock(&e->lock);
  263. rcu_read_unlock();
  264. return AUDIT_BUILD_CONTEXT;
  265. }
  266. rcu_read_unlock();
  267. return state;
  268. }
  269. }
  270. rcu_read_unlock();
  271. return AUDIT_BUILD_CONTEXT;
  272. }
  273. Note that this example assumes that entries are only added and deleted.
  274. Additional mechanism is required to deal correctly with the update-in-place
  275. performed by ``audit_upd_rule()``. For one thing, ``audit_upd_rule()`` would
  276. need additional memory barriers to ensure that the list_add_rcu() was really
  277. executed before the list_del_rcu().
  278. The ``audit_del_rule()`` function would need to set the ``deleted`` flag under the
  279. spinlock as follows::
  280. static inline int audit_del_rule(struct audit_rule *rule,
  281. struct list_head *list)
  282. {
  283. struct audit_entry *e;
  284. /* No need to use the _rcu iterator here, since this
  285. * is the only deletion routine. */
  286. list_for_each_entry(e, list, list) {
  287. if (!audit_compare_rule(rule, &e->rule)) {
  288. spin_lock(&e->lock);
  289. list_del_rcu(&e->list);
  290. e->deleted = 1;
  291. spin_unlock(&e->lock);
  292. call_rcu(&e->rcu, audit_free_rule);
  293. return 0;
  294. }
  295. }
  296. return -EFAULT; /* No matching rule */
  297. }
  298. This too assumes that the caller holds ``audit_filter_mutex``.
  299. Example 5: Skipping Stale Objects
  300. ---------------------------------
  301. For some usecases, reader performance can be improved by skipping stale objects
  302. during read-side list traversal if the object in concern is pending destruction
  303. after one or more grace periods. One such example can be found in the timerfd
  304. subsystem. When a ``CLOCK_REALTIME`` clock is reprogrammed - for example due to
  305. setting of the system time, then all programmed timerfds that depend on this
  306. clock get triggered and processes waiting on them to expire are woken up in
  307. advance of their scheduled expiry. To facilitate this, all such timers are added
  308. to an RCU-managed ``cancel_list`` when they are setup in
  309. ``timerfd_setup_cancel()``::
  310. static void timerfd_setup_cancel(struct timerfd_ctx *ctx, int flags)
  311. {
  312. spin_lock(&ctx->cancel_lock);
  313. if ((ctx->clockid == CLOCK_REALTIME &&
  314. (flags & TFD_TIMER_ABSTIME) && (flags & TFD_TIMER_CANCEL_ON_SET)) {
  315. if (!ctx->might_cancel) {
  316. ctx->might_cancel = true;
  317. spin_lock(&cancel_lock);
  318. list_add_rcu(&ctx->clist, &cancel_list);
  319. spin_unlock(&cancel_lock);
  320. }
  321. }
  322. spin_unlock(&ctx->cancel_lock);
  323. }
  324. When a timerfd is freed (fd is closed), then the ``might_cancel`` flag of the
  325. timerfd object is cleared, the object removed from the ``cancel_list`` and
  326. destroyed::
  327. int timerfd_release(struct inode *inode, struct file *file)
  328. {
  329. struct timerfd_ctx *ctx = file->private_data;
  330. spin_lock(&ctx->cancel_lock);
  331. if (ctx->might_cancel) {
  332. ctx->might_cancel = false;
  333. spin_lock(&cancel_lock);
  334. list_del_rcu(&ctx->clist);
  335. spin_unlock(&cancel_lock);
  336. }
  337. spin_unlock(&ctx->cancel_lock);
  338. hrtimer_cancel(&ctx->t.tmr);
  339. kfree_rcu(ctx, rcu);
  340. return 0;
  341. }
  342. If the ``CLOCK_REALTIME`` clock is set, for example by a time server, the
  343. hrtimer framework calls ``timerfd_clock_was_set()`` which walks the
  344. ``cancel_list`` and wakes up processes waiting on the timerfd. While iterating
  345. the ``cancel_list``, the ``might_cancel`` flag is consulted to skip stale
  346. objects::
  347. void timerfd_clock_was_set(void)
  348. {
  349. struct timerfd_ctx *ctx;
  350. unsigned long flags;
  351. rcu_read_lock();
  352. list_for_each_entry_rcu(ctx, &cancel_list, clist) {
  353. if (!ctx->might_cancel)
  354. continue;
  355. spin_lock_irqsave(&ctx->wqh.lock, flags);
  356. if (ctx->moffs != ktime_mono_to_real(0)) {
  357. ctx->moffs = KTIME_MAX;
  358. ctx->ticks++;
  359. wake_up_locked_poll(&ctx->wqh, EPOLLIN);
  360. }
  361. spin_unlock_irqrestore(&ctx->wqh.lock, flags);
  362. }
  363. rcu_read_unlock();
  364. }
  365. The key point here is, because RCU-traversal of the ``cancel_list`` happens
  366. while objects are being added and removed to the list, sometimes the traversal
  367. can step on an object that has been removed from the list. In this example, it
  368. is seen that it is better to skip such objects using a flag.
  369. Summary
  370. -------
  371. Read-mostly list-based data structures that can tolerate stale data are
  372. the most amenable to use of RCU. The simplest case is where entries are
  373. either added or deleted from the data structure (or atomically modified
  374. in place), but non-atomic in-place modifications can be handled by making
  375. a copy, updating the copy, then replacing the original with the copy.
  376. If stale data cannot be tolerated, then a *deleted* flag may be used
  377. in conjunction with a per-entry spinlock in order to allow the search
  378. function to reject newly deleted data.
  379. .. _quick_quiz_answer:
  380. Answer to Quick Quiz:
  381. For the deleted-flag technique to be helpful, why is it necessary
  382. to hold the per-entry lock while returning from the search function?
  383. If the search function drops the per-entry lock before returning,
  384. then the caller will be processing stale data in any case. If it
  385. is really OK to be processing stale data, then you don't need a
  386. *deleted* flag. If processing stale data really is a problem,
  387. then you need to hold the per-entry lock across all of the code
  388. that uses the value that was returned.
  389. :ref:`Back to Quick Quiz <quick_quiz>`