Date: Mon, 15 Jul 2019 10:37:05 -0400 From: "Joel Fernandes (Google)" <joel@...lfernandes.org> To: linux-kernel@...r.kernel.org Cc: "Joel Fernandes (Google)" <joel@...lfernandes.org>, Alexey Kuznetsov <kuznet@....inr.ac.ru>, Bjorn Helgaas <bhelgaas@...gle.com>, Borislav Petkov <bp@...en8.de>, c0d1n61at3@...il.com, "David S. Miller" <davem@...emloft.net>, edumazet@...gle.com, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>, "H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>, Jonathan Corbet <corbet@....net>, Josh Triplett <josh@...htriplett.org>, keescook@...omium.org, kernel-hardening@...ts.openwall.com, kernel-team@...roid.com, Lai Jiangshan <jiangshanlai@...il.com>, Len Brown <lenb@...nel.org>, linux-acpi@...r.kernel.org, linux-doc@...r.kernel.org, linux-pci@...r.kernel.org, linux-pm@...r.kernel.org, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, neilb@...e.com, netdev@...r.kernel.org, Oleg Nesterov <oleg@...hat.com>, "Paul E. McKenney" <paulmck@...ux.ibm.com>, Pavel Machek <pavel@....cz>, peterz@...radead.org, "Rafael J. Wysocki" <rjw@...ysocki.net>, Rasmus Villemoes <rasmus.villemoes@...vas.dk>, rcu@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>, Tejun Heo <tj@...nel.org>, Thomas Gleixner <tglx@...utronix.de>, will@...nel.org, x86@...nel.org (maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)) Subject: [PATCH 9/9] doc: Update documentation about list_for_each_entry_rcu (v1) This patch updates the documentation with information about usage of lockdep with list_for_each_entry_rcu(). Signed-off-by: Joel Fernandes (Google) <joel@...lfernandes.org> --- Documentation/RCU/lockdep.txt | 15 +++++++++++---- Documentation/RCU/whatisRCU.txt | 9 ++++++++- 2 files changed, 19 insertions(+), 5 deletions(-) diff --git a/Documentation/RCU/lockdep.txt b/Documentation/RCU/lockdep.txt index da51d3068850..3d967df3a801 100644 --- a/Documentation/RCU/lockdep.txt +++ b/Documentation/RCU/lockdep.txt @@ -96,7 +96,14 @@ other flavors of rcu_dereference(). On the other hand, it is illegal to use rcu_dereference_protected() if either the RCU-protected pointer or the RCU-protected data that it points to can change concurrently. -There are currently only "universal" versions of the rcu_assign_pointer() -and RCU list-/tree-traversal primitives, which do not (yet) check for -being in an RCU read-side critical section. In the future, separate -versions of these primitives might be created. +Similar to rcu_dereference_protected, The RCU list and hlist traversal +primitives also check for whether there are called from within a reader +section. However, an optional lockdep expression can be passed to them as +the last argument in case they are called under other non-RCU protection. + +For example, the workqueue for_each_pwq() macro is implemented as follows. +It is safe to call for_each_pwq() outside a reader section but under protection +of wq->mutex: +#define for_each_pwq(pwq, wq) + list_for_each_entry_rcu((pwq), &(wq)->pwqs, pwqs_node, + lock_is_held(&(wq->mutex).dep_map)) diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt index 7e1a8721637a..00fe77ede1e2 100644 --- a/Documentation/RCU/whatisRCU.txt +++ b/Documentation/RCU/whatisRCU.txt @@ -290,7 +290,7 @@ rcu_dereference() at any time, including immediately after the rcu_dereference(). And, again like rcu_assign_pointer(), rcu_dereference() is typically used indirectly, via the _rcu list-manipulation - primitives, such as list_for_each_entry_rcu(). + primitives, such as list_for_each_entry_rcu() .  The variant rcu_dereference_protected() can be used outside of an RCU read-side critical section as long as the usage is @@ -305,6 +305,13 @@ rcu_dereference() a lockdep splat is emitted. See RCU/Design/Requirements/Requirements.html and the API's code comments for more details and example usage. +  In case the list_for_each_entry_rcu() primitive is intended + to be used outside of an RCU reader section such as when + protected by a lock, then an additional lockdep expression can be + passed as the last argument to it so that RCU lockdep checking code + knows that the dereference of the list pointers are safe. If the + indicated protection is not provided, a lockdep splat is emitted. + The following diagram shows how each API communicates among the reader, updater, and reclaimer. -- 22.214.171.1240.g264f2c817a-goog
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.