rculist_nulls.rst 6.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215
  1. .. SPDX-License-Identifier: GPL-2.0
  2. =================================================
  3. Using RCU hlist_nulls to protect list and objects
  4. =================================================
  5. This section describes how to use hlist_nulls to
  6. protect read-mostly linked lists and
  7. objects using SLAB_TYPESAFE_BY_RCU allocations.
  8. Please read the basics in listRCU.rst.
  9. Using 'nulls'
  10. =============
  11. Using special makers (called 'nulls') is a convenient way
  12. to solve following problem.
  13. Without 'nulls', a typical RCU linked list managing objects which are
  14. allocated with SLAB_TYPESAFE_BY_RCU kmem_cache can use the following
  15. algorithms. Following examples assume 'obj' is a pointer to such
  16. objects, which is having below type.
  17. ::
  18. struct object {
  19. struct hlist_node obj_node;
  20. atomic_t refcnt;
  21. unsigned int key;
  22. };
  23. 1) Lookup algorithm
  24. -------------------
  25. ::
  26. begin:
  27. rcu_read_lock();
  28. obj = lockless_lookup(key);
  29. if (obj) {
  30. if (!try_get_ref(obj)) { // might fail for free objects
  31. rcu_read_unlock();
  32. goto begin;
  33. }
  34. /*
  35. * Because a writer could delete object, and a writer could
  36. * reuse these object before the RCU grace period, we
  37. * must check key after getting the reference on object
  38. */
  39. if (obj->key != key) { // not the object we expected
  40. put_ref(obj);
  41. rcu_read_unlock();
  42. goto begin;
  43. }
  44. }
  45. rcu_read_unlock();
  46. Beware that lockless_lookup(key) cannot use traditional hlist_for_each_entry_rcu()
  47. but a version with an additional memory barrier (smp_rmb())
  48. ::
  49. lockless_lookup(key)
  50. {
  51. struct hlist_node *node, *next;
  52. for (pos = rcu_dereference((head)->first);
  53. pos && ({ next = pos->next; smp_rmb(); prefetch(next); 1; }) &&
  54. ({ obj = hlist_entry(pos, typeof(*obj), obj_node); 1; });
  55. pos = rcu_dereference(next))
  56. if (obj->key == key)
  57. return obj;
  58. return NULL;
  59. }
  60. And note the traditional hlist_for_each_entry_rcu() misses this smp_rmb()::
  61. struct hlist_node *node;
  62. for (pos = rcu_dereference((head)->first);
  63. pos && ({ prefetch(pos->next); 1; }) &&
  64. ({ obj = hlist_entry(pos, typeof(*obj), obj_node); 1; });
  65. pos = rcu_dereference(pos->next))
  66. if (obj->key == key)
  67. return obj;
  68. return NULL;
  69. Quoting Corey Minyard::
  70. "If the object is moved from one list to another list in-between the
  71. time the hash is calculated and the next field is accessed, and the
  72. object has moved to the end of a new list, the traversal will not
  73. complete properly on the list it should have, since the object will
  74. be on the end of the new list and there's not a way to tell it's on a
  75. new list and restart the list traversal. I think that this can be
  76. solved by pre-fetching the "next" field (with proper barriers) before
  77. checking the key."
  78. 2) Insertion algorithm
  79. ----------------------
  80. We need to make sure a reader cannot read the new 'obj->obj_node.next' value
  81. and previous value of 'obj->key'. Otherwise, an item could be deleted
  82. from a chain, and inserted into another chain. If new chain was empty
  83. before the move, 'next' pointer is NULL, and lockless reader can not
  84. detect the fact that it missed following items in original chain.
  85. ::
  86. /*
  87. * Please note that new inserts are done at the head of list,
  88. * not in the middle or end.
  89. */
  90. obj = kmem_cache_alloc(...);
  91. lock_chain(); // typically a spin_lock()
  92. obj->key = key;
  93. atomic_set_release(&obj->refcnt, 1); // key before refcnt
  94. hlist_add_head_rcu(&obj->obj_node, list);
  95. unlock_chain(); // typically a spin_unlock()
  96. 3) Removal algorithm
  97. --------------------
  98. Nothing special here, we can use a standard RCU hlist deletion.
  99. But thanks to SLAB_TYPESAFE_BY_RCU, beware a deleted object can be reused
  100. very very fast (before the end of RCU grace period)
  101. ::
  102. if (put_last_reference_on(obj) {
  103. lock_chain(); // typically a spin_lock()
  104. hlist_del_init_rcu(&obj->obj_node);
  105. unlock_chain(); // typically a spin_unlock()
  106. kmem_cache_free(cachep, obj);
  107. }
  108. --------------------------------------------------------------------------
  109. Avoiding extra smp_rmb()
  110. ========================
  111. With hlist_nulls we can avoid extra smp_rmb() in lockless_lookup().
  112. For example, if we choose to store the slot number as the 'nulls'
  113. end-of-list marker for each slot of the hash table, we can detect
  114. a race (some writer did a delete and/or a move of an object
  115. to another chain) checking the final 'nulls' value if
  116. the lookup met the end of chain. If final 'nulls' value
  117. is not the slot number, then we must restart the lookup at
  118. the beginning. If the object was moved to the same chain,
  119. then the reader doesn't care: It might occasionally
  120. scan the list again without harm.
  121. Note that using hlist_nulls means the type of 'obj_node' field of
  122. 'struct object' becomes 'struct hlist_nulls_node'.
  123. 1) lookup algorithm
  124. -------------------
  125. ::
  126. head = &table[slot];
  127. begin:
  128. rcu_read_lock();
  129. hlist_nulls_for_each_entry_rcu(obj, node, head, obj_node) {
  130. if (obj->key == key) {
  131. if (!try_get_ref(obj)) { // might fail for free objects
  132. rcu_read_unlock();
  133. goto begin;
  134. }
  135. if (obj->key != key) { // not the object we expected
  136. put_ref(obj);
  137. rcu_read_unlock();
  138. goto begin;
  139. }
  140. goto out;
  141. }
  142. }
  143. // If the nulls value we got at the end of this lookup is
  144. // not the expected one, we must restart lookup.
  145. // We probably met an item that was moved to another chain.
  146. if (get_nulls_value(node) != slot) {
  147. put_ref(obj);
  148. rcu_read_unlock();
  149. goto begin;
  150. }
  151. obj = NULL;
  152. out:
  153. rcu_read_unlock();
  154. 2) Insert algorithm
  155. -------------------
  156. Same to the above one, but uses hlist_nulls_add_head_rcu() instead of
  157. hlist_add_head_rcu().
  158. ::
  159. /*
  160. * Please note that new inserts are done at the head of list,
  161. * not in the middle or end.
  162. */
  163. obj = kmem_cache_alloc(cachep);
  164. lock_chain(); // typically a spin_lock()
  165. obj->key = key;
  166. atomic_set_release(&obj->refcnt, 1); // key before refcnt
  167. /*
  168. * insert obj in RCU way (readers might be traversing chain)
  169. */
  170. hlist_nulls_add_head_rcu(&obj->obj_node, list);
  171. unlock_chain(); // typically a spin_unlock()