path: root/Documentation/DocBook/kernel-locking.tmpl
diff options
authorPaul E. McKenney <>2010-05-19 10:46:55 -0700
committerPaul E. McKenney <>2010-08-19 17:18:03 -0700
commitded5e5ed2f3348ba2f9a319c6497e46c22850e97 (patch)
tree8057debf79c6407544684928ca668b8954010791 /Documentation/DocBook/kernel-locking.tmpl
parent65e423f8ee5843e1ea3f2d94adf4ba3560a17f7b (diff)
Update call_rcu() usage, add synchronize_rcu()
Reported-by: Kyle Hubert <> Signed-off-by: Paul E. McKenney <> Reviewed-by: Josh Triplett <>
Diffstat (limited to 'Documentation/DocBook/kernel-locking.tmpl')
1 files changed, 4 insertions, 2 deletions
diff --git a/Documentation/DocBook/kernel-locking.tmpl b/Documentation/DocBook/kernel-locking.tmpl
index e6cc57460212..ed64d220baf2 100644
--- a/Documentation/DocBook/kernel-locking.tmpl
+++ b/Documentation/DocBook/kernel-locking.tmpl
@@ -1645,7 +1645,9 @@ the amount of locking which needs to be done.
all the readers who were traversing the list when we deleted the
element are finished. We use <function>call_rcu()</function> to
register a callback which will actually destroy the object once
- the readers are finished.
+ all pre-existing readers are finished. Alternatively,
+ <function>synchronize_rcu()</function> may be used to block until
+ all pre-existing are finished.
But how does Read Copy Update know when the readers are
@@ -1714,7 +1716,7 @@ the amount of locking which needs to be done.
- object_put(obj);
+ list_del_rcu(&amp;obj-&gt;list);
-+ call_rcu(&amp;obj-&gt;rcu, cache_delete_rcu, obj);
++ call_rcu(&amp;obj-&gt;rcu, cache_delete_rcu);
/* Must be holding cache_lock */