From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Rik van Riel <riel@redhat.com>
Cc: Linux kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: RCU recursion? (code inspection)
Date: Fri, 1 May 2015 13:10:05 -0700 [thread overview]
Message-ID: <20150501201005.GA15557@linux.vnet.ibm.com> (raw)
In-Reply-To: <20150501194102.GH5381@linux.vnet.ibm.com>
On Fri, May 01, 2015 at 12:41:02PM -0700, Paul E. McKenney wrote:
> On Fri, May 01, 2015 at 03:18:28PM -0400, Rik van Riel wrote:
> > Hi Paul,
> >
> > While looking at synchronize_rcu(), I noticed that
> > synchronize_rcu_expedited() calls synchronize_sched_expedited(),
> > which can call synchronize_sched() when it is worried about
> > the counter wrapping, which can call synchronize_sched_expedited()
> >
> > The code is sufficiently convoluted that I am unsure whether this
> > recursion can actually happen in practice, but I also did not spot
> > anything that would stop it.
>
> Hmmm... Sounds like I should take a look!
And good catch! The following patch should fix this. Bad one on me,
given that all the other places in synchronize_sched_expedited() that
you would expect to invoke synchronize_sched() instead invoke
wait_rcu_gp(call_rcu_sched)...
Thanx, Paul
------------------------------------------------------------------------
rcu: Make synchronize_sched_expedited() call wait_rcu_gp()
Currently, synchronize_sched_expedited() will call synchronize_sched()
if there is danger of counter wrap. But if configuration says to
always do expedited grace periods, synchronize_sched() will just
call synchronize_sched_expedited() right back again. In theory,
the old expedited operations will complete, the counters will
get back in synch, and the recursion will end. But we could
easily run out of stack long before that time. This commit
therefore makes synchronize_sched_expedited() invoke the underlying
wait_rcu_gp(call_rcu_sched) instead of synchronize_sched(), the same as
all the other calls out from synchronize_sched_expedited().
This bug was introduced by commit 1924bcb02597 (Avoid counter wrap in
synchronize_sched_expedited()).
Reported-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index bcc59437fc93..4e6902005228 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -3310,7 +3310,7 @@ void synchronize_sched_expedited(void)
if (ULONG_CMP_GE((ulong)atomic_long_read(&rsp->expedited_start),
(ulong)atomic_long_read(&rsp->expedited_done) +
ULONG_MAX / 8)) {
- synchronize_sched();
+ wait_rcu_gp(call_rcu_sched);
atomic_long_inc(&rsp->expedited_wrap);
return;
}
prev parent reply other threads:[~2015-05-01 20:10 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-01 19:18 RCU recursion? (code inspection) Rik van Riel
2015-05-01 19:41 ` Paul E. McKenney
2015-05-01 20:10 ` Paul E. McKenney [this message]
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=20150501201005.GA15557@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox