Messages in this thread | | | Date | Fri, 23 Apr 2010 19:46:17 -0500 | From | "Serge E. Hallyn" <> | Subject | Re: Documentation/credentials.txt |
| |
Quoting Paul E. McKenney (paulmck@linux.vnet.ibm.com): > On Fri, Apr 23, 2010 at 06:55:33PM -0500, Serge E. Hallyn wrote: > > Hi, > > > > In the section 'ACCESSING ANOTHER TASK'S CREDENTIALS', the file > > Documentation/credentials.txt says: > > > > > 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. > > > > AIUI, that is not actually right any more, is it? A spinlock does not > > suffice as it does not necessarily imply an RCU read-side critical section > > (anymore). Of course the spinlock specifically protecting updates would > > suffice, but that's not what this is saying. > > > > Am I way off base? > > You are absolutely correct, good catch!!! > > Now, a spinlock still does imply an RCU read-side critical section given > the following configuration options: > > o !CONFIG_PREEMPT > > o CONFIG_PREEMPT && CONFIG_TREE_RCU > > o CONFIG_PREEMPT && CONFIG_TINY_RCU > > However, relying on this is usually bad practice, as such code is prone > to failure given the following configuration options: > > o CONFIG_PREEMPT && CONFIG_TREE_PREEMPT_RCU > > o CONFIG_PREEMPT_RT (given the -rt patchset) > > And when I get my act together and complete CONFIG_TINY_PREEMPT_RCU, > then CONFIG_PREEMPT && CONFIG_TINY_PREEMPT_RCU will also invalidate > the assumption that holding a spinlock acts as an RCU read-side > critical section. > > Did you want to submit a patch for this?
Yup, sent, thanks.
-serge
| |