From: Brice Goglin <Brice.Goglin@inria.fr>
To: Nadia Derbey <Nadia.Derbey@bull.net>
Cc: LKML <linux-kernel@vger.kernel.org>,
"Paul E. McKenney" <paulmck@us.ibm.com>,
Jim Houston <jim.houston@comcast.net>
Subject: [PATCH] idr: document that idr_for_each may be used under rcu_read_lock()
Date: Mon, 10 May 2010 18:55:17 +0200 [thread overview]
Message-ID: <4BE83A75.7050003@inria.fr> (raw)
Hello Nadia,
In commit f9c46d6ea5ce138a886c3a0f10a46130afab75f5, you converted
idr_find() and idr_for_each() to rcu_dereference(). The documentation
of idr_find() was updated to say that it may now be called under
rcu_read_lock(). But the doc of idr_for_each() still says:
"The caller must serialize idr_for_each() vs idr_get_new() and
idr_remove()."
I might be missing something, but assuming idr_for_each() may also be
called under rcu_read_lock(), we need something like the patch below,
right? (I just duplicated the doc update of idr_find())
thanks,
Brice
>From 35a05eba9cc16d7fe786a9a7ff17f88fcf8b06e2 Mon Sep 17 00:00:00 2001
From: Brice Goglin <Brice.Goglin@inria.fr>
Date: Mon, 10 May 2010 18:49:51 +0200
Subject: [PATCH] idr: document that idr_for_each may be used under rcu_read_lock()
Since commit f9c46d6ea5ce138a886c3a0f10a46130afab75f5, idr_for_each()
may be called under rcu_read_lock(). It does not need serialization
against idr_get_new() and idr_remove() anymore.
Signed-off-by: Brice Goglin <Brice.Goglin@inria.fr>
---
lib/idr.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/lib/idr.c b/lib/idr.c
index 2eb1dca..7eb435d 100644
--- a/lib/idr.c
+++ b/lib/idr.c
@@ -541,7 +541,8 @@ EXPORT_SYMBOL(idr_find);
* We check the return of @fn each time. If it returns anything other
* than 0, we break out and return that value.
*
- * The caller must serialize idr_for_each() vs idr_get_new() and idr_remove().
+ * This function can be called under rcu_read_lock(), given that the leaf
+ * pointers lifetimes are correctly managed.
*/
int idr_for_each(struct idr *idp,
int (*fn)(int id, void *p, void *data), void *data)
--
1.7.1
reply other threads:[~2010-05-10 17:21 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BE83A75.7050003@inria.fr \
--to=brice.goglin@inria.fr \
--cc=Nadia.Derbey@bull.net \
--cc=jim.houston@comcast.net \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.