From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: "Serge E. Hallyn" <serue@us.ibm.com>
Cc: David Howells <dhowells@redhat.com>, lkml <linux-kernel@vger.kernel.org>
Subject: Re: Documentation/credentials.txt
Date: Fri, 23 Apr 2010 17:14:37 -0700 [thread overview]
Message-ID: <20100424001437.GB2589@linux.vnet.ibm.com> (raw)
In-Reply-To: <20100423235532.GA17804@us.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?
Thanx, Paul
next prev parent reply other threads:[~2010-04-24 0:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-23 23:55 Documentation/credentials.txt Serge E. Hallyn
2010-04-24 0:14 ` Paul E. McKenney [this message]
2010-04-24 0:46 ` Documentation/credentials.txt Serge E. Hallyn
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=20100424001437.GB2589@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=dhowells@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=serue@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.