|
@@ -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,17 +423,16 @@ 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()
|
|
|
-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.
|
|
|
+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.
|
|
|
|
|
|
Should some other single aspect of another task's credentials need to be
|
|
|
accessed, then this can be used:
|