From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: David Howells <dhowells@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Jiri Olsa <jolsa@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Eric Dumazet <eric.dumazet@gmail.com>,
linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org
Subject: Re: [PATCH] cred - synchronize rcu before releasing cred
Date: Fri, 30 Jul 2010 14:32:56 -0700 [thread overview]
Message-ID: <20100730213256.GA2470@linux.vnet.ibm.com> (raw)
In-Reply-To: <30107.1280392460@redhat.com>
On Thu, Jul 29, 2010 at 09:34:20AM +0100, David Howells wrote:
> Paul E. McKenney <paulmck@linux.vnet.ibm.com> wrote:
>
> > It is perfectly legal for an RCU callback to invoke call_rcu(). However,
> > this should be used -only- to wait for RCU readers. If there are no
> > RCU readers, the callback might be re-invoked in very short order,
> > expecially on UP systems.
> >
> > Or am I misunderstanding what you mean by "require call_rcu() to be
> > able to cope iwth requeueing"?
>
> I mean for call_rcu() to be called on an object that's already been
> call_rcu()'d but not yet processed.
That would indeed be very bad!!!
> For example if struct cred gets its usage count reduced to 0, __put_cred()
> will call_rcu() it, but what happens if someone comes along and resurrects it
> by increasing its usage count again? And what happens if the usage count is
> reduced back to zero and __put_cred() calls call_rcu() again before
> put_cred_rcu() has a chance to run?
Doing this would mess up RCU's internal data structures. Mathieu
Desnoyers's recent debug changes (DEBUG_OBJECTS_RCU_HEAD) would catch
this sort of error.
Thanx, Paul
next prev parent reply other threads:[~2010-07-30 21:33 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-27 15:50 [PATCH] cred - synchronize rcu before releasing cred Jiri Olsa
2010-07-27 16:16 ` Linus Torvalds
2010-07-27 16:46 ` David Howells
2010-07-27 17:56 ` Linus Torvalds
2010-07-28 8:25 ` Jiri Olsa
2010-07-28 12:07 ` David Howells
2010-07-28 12:47 ` David Howells
2010-07-29 6:00 ` Paul E. McKenney
2010-07-29 8:34 ` David Howells
2010-07-30 21:32 ` Paul E. McKenney [this message]
2010-07-28 13:17 ` David Howells
2010-07-28 14:46 ` Jiri Olsa
2010-07-29 9:38 ` Jiri Olsa
2010-07-28 15:51 ` Linus Torvalds
-- strict thread matches above, loose matches on Subject: below --
2010-06-25 13:33 Jiri Olsa
2010-07-02 12:14 ` Jiri Olsa
2010-06-16 12:24 Jiri Olsa
2010-06-16 12:45 ` Eric Dumazet
2010-06-16 12:57 ` Jiri Olsa
2010-06-16 13:10 ` Eric Dumazet
2010-06-16 16:08 ` Jiri Olsa
2010-06-17 23:50 ` David Howells
2010-06-19 12:01 ` Jiri Olsa
2010-06-25 12:55 ` Jiri Olsa
2010-06-25 13:28 ` David Howells
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=20100730213256.GA2470@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=dhowells@redhat.com \
--cc=eric.dumazet@gmail.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/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.