From: David Howells <dhowells@redhat.com>
To: paulmck@linux.vnet.ibm.com
Cc: dhowells@redhat.com,
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: Thu, 29 Jul 2010 09:34:20 +0100 [thread overview]
Message-ID: <30107.1280392460@redhat.com> (raw)
In-Reply-To: <20100729060004.GD2447@linux.vnet.ibm.com>
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.
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?
David
next prev parent reply other threads:[~2010-07-29 8:35 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 [this message]
2010-07-30 21:32 ` Paul E. McKenney
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=30107.1280392460@redhat.com \
--to=dhowells@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=eric.dumazet@gmail.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--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.