Commit b03df87d authored by Serge E. Hallyn's avatar Serge E. Hallyn Committed by James Morris

CRED: Holding a spinlock does not imply the holding of RCU read lock

Change the credentials documentation to make it clear that the RCU read lock
must be explicitly held when accessing credentials pointers in some other task
than current.  Holding a spinlock does not implicitly hold the RCU read lock.
Signed-off-by: default avatarSerge Hallyn <serue@us.ibm.com>
Reviewed-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
Signed-off-by: default avatarJames Morris <jmorris@namei.org>
parent 98ec4373
...@@ -408,9 +408,6 @@ This should be used inside the RCU read lock, as in the following example: ...@@ -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 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 time, and possibly to sleep whilst doing so, then the caller should get a
reference on them using: reference on them using:
...@@ -426,17 +423,16 @@ credentials, hiding the RCU magic from the caller: ...@@ -426,17 +423,16 @@ credentials, hiding the RCU magic from the caller:
uid_t task_uid(task) Task's real UID uid_t task_uid(task) Task's real UID
uid_t task_euid(task) Task's effective 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, If the caller is holding the RCU read lock at the time anyway, then:
then:
__task_cred(task)->uid __task_cred(task)->uid
__task_cred(task)->euid __task_cred(task)->euid
should be used instead. Similarly, if multiple aspects of a task's credentials 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
called, the result stored in a temporary pointer and then the credential result stored in a temporary pointer and then the credential aspects called
aspects called from that before dropping the lock. This prevents the from that before dropping the lock. This prevents the potentially expensive
potentially expensive RCU magic from being invoked multiple times. RCU magic from being invoked multiple times.
Should some other single aspect of another task's credentials need to be Should some other single aspect of another task's credentials need to be
accessed, then this can be used: accessed, then this can be used:
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment