From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Oleg Nesterov <oleg@tv-sign.ru>,
hugh@veritas.com, clameter@sgi.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] adapt page_lock_anon_vma() to PREEMPT_RCU
Date: Tue, 27 Feb 2007 15:13:15 -0800 [thread overview]
Message-ID: <20070227231315.GC1919@linux.vnet.ibm.com> (raw)
In-Reply-To: <20070227122517.c8bceaf5.akpm@linux-foundation.org>
On Tue, Feb 27, 2007 at 12:25:17PM -0800, Andrew Morton wrote:
> > On Sun, 25 Feb 2007 23:06:21 +0300 Oleg Nesterov <oleg@tv-sign.ru> wrote:
> > page_lock_anon_vma() uses spin_lock() to block RCU. This doesn't work with
> > PREEMPT_RCU, we have to do rcu_read_lock() explicitely. Otherwise, it is
> > theoretically possible that slab returns anon_vma's memory to the system
> > before we do spin_unlock(&anon_vma->lock).
> >
> > ...
> >
> > +static void page_unlock_anon_vma(struct anon_vma *anon_vma)
> > +{
> > + spin_unlock(&anon_vma->lock);
> > + rcu_read_unlock();
> > }
>
> It's a bit sad doing a double preempt_disable() for non-PREEMPT_RCU builds.
>
> Perhaps we would benefit from a new rcu_read_lock_preempt_rcu() which is a
> no-op if !PREEMPT_RCU.
We were doing double preempt_disable() before as well. The only
difference is that we moved RCU preempt_enable() (it used to be inside the
critical section, and now it is after the corresponding spin_unlock()).
I hope to keep RCU API proliferation down to a dull roar, but if we
need more APIs, we need more APIs. This example does not demonstrate
that need to me, however.
Thanx, Paul
next prev parent reply other threads:[~2007-02-27 23:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-25 20:06 [PATCH] adapt page_lock_anon_vma() to PREEMPT_RCU Oleg Nesterov
2007-02-27 20:25 ` Andrew Morton
2007-02-27 21:46 ` Oleg Nesterov
2007-02-27 23:13 ` Paul E. McKenney [this message]
2007-02-28 19:48 ` Hugh Dickins
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=20070227231315.GC1919@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=clameter@sgi.com \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@tv-sign.ru \
/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.