All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serue@us.ibm.com>
To: David Howells <dhowells@redhat.com>,
	"Paul E. McKenney" <paulmck@us.ibm.com>
Cc: lkml <linux-kernel@vger.kernel.org>
Subject: [PATCH] Documentation/cred.txt: spinlock no longer implies rcu_read_lock
Date: Fri, 23 Apr 2010 19:45:57 -0500	[thread overview]
Message-ID: <20100424004557.GA21297@us.ibm.com> (raw)

So change the credentials documentation to make it clear that rcu
read lock is required.

Signed-off-by: Serge Hallyn <serue@us.ibm.com>
---
 Documentation/credentials.txt |    8 ++------
 1 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/Documentation/credentials.txt b/Documentation/credentials.txt
index df03169..98a1e9e 100644
--- a/Documentation/credentials.txt
+++ b/Documentation/credentials.txt
@@ -408,9 +408,6 @@ This should be used inside the RCU read lock, as in the following example:
 		...
 	}
 
-A function need not get RCU read lock to use __task_cred() if it is holding a
-spinlock at the time as this implicitly holds the RCU read lock.
-
 Should it be necessary to hold another task's credentials for a long period of
 time, and possibly to sleep whilst doing so, then the caller should get a
 reference on them using:
@@ -426,14 +423,13 @@ credentials, hiding the RCU magic from the caller:
 	uid_t task_uid(task)		Task's real UID
 	uid_t task_euid(task)		Task's effective UID
 
-If the caller is holding a spinlock or the RCU read lock at the time anyway,
-then:
+If the caller is holding the RCU read lock at the time anyway, then:
 
 	__task_cred(task)->uid
 	__task_cred(task)->euid
 
 should be used instead.  Similarly, if multiple aspects of a task's credentials
-need to be accessed, RCU read lock or a spinlock should be used, __task_cred()
+need to be accessed, RCU read lock should be used, __task_cred()
 called, the result stored in a temporary pointer and then the credential
 aspects called from that before dropping the lock.  This prevents the
 potentially expensive RCU magic from being invoked multiple times.
-- 
1.6.3.3


             reply	other threads:[~2010-04-24  0:46 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-24  0:45 Serge E. Hallyn [this message]
2010-04-24  1:24 ` [PATCH] Documentation/cred.txt: spinlock no longer implies rcu_read_lock Paul E. McKenney

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=20100424004557.GA21297@us.ibm.com \
    --to=serue@us.ibm.com \
    --cc=dhowells@redhat.com \
    --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.