From: "Paul E. McKenney" <paulmck@linux.ibm.com>
To: Joel Fernandes <joel@joelfernandes.org>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
Steven Rostedt <rostedt@goodmis.org>, rcu <rcu@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
Josh Triplett <josh@joshtriplett.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Lai Jiangshan <jiangshanlai@gmail.com>
Subject: Re: [RFC] Deadlock via recursive wakeup via RCU with threadirqs
Date: Fri, 28 Jun 2019 13:04:23 -0700 [thread overview]
Message-ID: <20190628200423.GB26519@linux.ibm.com> (raw)
In-Reply-To: <20190628192407.GA89956@google.com>
On Fri, Jun 28, 2019 at 03:24:07PM -0400, Joel Fernandes wrote:
> On Fri, Jun 28, 2019 at 11:52:19AM -0700, Paul E. McKenney wrote:
> > On Fri, Jun 28, 2019 at 08:40:26PM +0200, Sebastian Andrzej Siewior wrote:
> > > On 2019-06-28 08:30:50 [-0700], Paul E. McKenney wrote:
> > > > On Fri, Jun 28, 2019 at 03:54:33PM +0200, Peter Zijlstra wrote:
> > > > > On Thu, Jun 27, 2019 at 11:41:07AM -0700, Paul E. McKenney wrote:
> > > > > > Or just don't do the wakeup at all, if it comes to that. I don't know
> > > > > > of any way to determine whether rcu_read_unlock() is being called from
> > > > > > the scheduler, but it has been some time since I asked Peter Zijlstra
> > > > > > about that.
> > > > >
> > > > > There (still) is no 'in-scheduler' state.
> > > >
> > > > Well, my TREE03 + threadirqs rcutorture test ran for ten hours last
> > > > night with no problems, so we just might be OK.
> > > >
> > > > The apparent fix is below, though my approach would be to do backports
> > > > for the full set of related changes.
> > > >
> > > > Joel, Sebastian, how goes any testing from your end? Any reason
> > > > to believe that this does not represent a fix? (Me, I am still
> > > > concerned about doing raise_softirq() from within a threaded
> > > > interrupt, but am not seeing failures.)
>
> Are you concerned also about a regular process context executing in the
> scheduler and using RCU, having this issue?
> (not anything with threaded or not threaded IRQs, but just a path in the
> scheduler that uses RCU).
>
> I don't think Sebastian's lock up has to do with the fact that an interrupt
> is threaded or not, except that ksoftirqd is awakened in the case where
> threadirqs is passed.
In current -rcu, the checks should suffice in the absence of threaded
interrupts. They might also suffice for threaded interrupts, but a more
direct approach would be better, hence the in_interrupt() patch.
> > > For some reason it does not trigger as good as it did yesterday.
> >
> > I swear that I wasn't watching!!! ;-)
> >
> > But I do know that feeling.
>
> :-)
>
> > > Commit
> > > - 23634ebc1d946 ("rcu: Check for wakeup-safe conditions in
> > > rcu_read_unlock_special()") does not trigger the bug within 94
> > > attempts.
> > >
> > > - 48d07c04b4cc1 ("rcu: Enable elimination of Tree-RCU softirq
> > > processing") needed 12 attempts to trigger the bug.
> >
> > That matches my belief that 23634ebc1d946 ("rcu: Check for wakeup-safe
> > conditions in rcu_read_unlock_special()") will at least greatly decrease
> > the probability of this bug occurring.
>
> I was just typing a reply that I can't reproduce it with:
> rcu: Check for wakeup-safe conditions in rcu_read_unlock_special()
>
> I am trying to revert enough of this patch to see what would break things,
> however I think a better exercise might be to understand more what the patch
> does why it fixes things in the first place ;-) It is probably the
> deferred_qs thing.
The deferred_qs flag is part of it! Looking forward to hearing what
you come up with as being the critical piece of this commit.
Thanx, Paul
next prev parent reply other threads:[~2019-06-28 20:04 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-26 13:54 [RFC] Deadlock via recursive wakeup via RCU with threadirqs Sebastian Andrzej Siewior
2019-06-26 16:25 ` Paul E. McKenney
2019-06-27 7:47 ` Sebastian Andrzej Siewior
2019-06-27 15:52 ` Paul E. McKenney
2019-06-27 14:24 ` Joel Fernandes
2019-06-27 14:34 ` Steven Rostedt
2019-06-27 15:30 ` Joel Fernandes
2019-06-27 15:37 ` Joel Fernandes
2019-06-27 15:40 ` Sebastian Andrzej Siewior
2019-06-27 15:42 ` Joel Fernandes
2019-06-27 17:43 ` Joel Fernandes
2019-06-27 17:46 ` Joel Fernandes
2019-06-27 18:11 ` Paul E. McKenney
2019-06-27 18:27 ` Joel Fernandes
2019-06-27 18:51 ` Joel Fernandes
2019-06-27 19:14 ` Paul E. McKenney
2019-06-27 19:15 ` Paul E. McKenney
2019-06-27 18:30 ` Paul E. McKenney
2019-06-27 20:45 ` Paul E. McKenney
2019-06-27 15:55 ` Paul E. McKenney
2019-06-27 16:47 ` Joel Fernandes
2019-06-27 17:38 ` Paul E. McKenney
2019-06-27 18:16 ` Joel Fernandes
2019-06-27 18:41 ` Paul E. McKenney
2019-06-27 20:17 ` Scott Wood
2019-06-27 20:36 ` Paul E. McKenney
2019-06-28 7:31 ` Byungchul Park
2019-06-28 7:43 ` Byungchul Park
2019-06-28 8:14 ` Byungchul Park
2019-06-28 8:24 ` Byungchul Park
2019-06-28 12:24 ` Paul E. McKenney
2019-06-28 9:10 ` Byungchul Park
2019-06-28 9:28 ` Byungchul Park
2019-06-28 12:21 ` Paul E. McKenney
2019-06-28 10:40 ` Byungchul Park
2019-06-28 12:27 ` Paul E. McKenney
2019-06-28 15:44 ` Steven Rostedt
2019-06-29 15:12 ` Andrea Parri
2019-06-29 16:55 ` Paul E. McKenney
2019-06-29 18:09 ` Andrea Parri
2019-06-29 18:21 ` Andrea Parri
2019-06-29 19:15 ` Paul E. McKenney
2019-06-29 19:35 ` Andrea Parri
2019-06-30 23:55 ` Byungchul Park
2019-06-28 14:15 ` Peter Zijlstra
2019-06-28 15:54 ` Paul E. McKenney
2019-06-28 16:04 ` Peter Zijlstra
2019-06-28 17:20 ` Paul E. McKenney
2019-07-01 9:42 ` Peter Zijlstra
2019-07-01 10:24 ` Sebastian Andrzej Siewior
2019-07-01 12:23 ` Paul E. McKenney
2019-07-01 14:00 ` Peter Zijlstra
2019-07-01 16:01 ` Paul E. McKenney
2019-06-28 20:01 ` Scott Wood
2019-07-01 9:45 ` Peter Zijlstra
2019-06-28 13:54 ` Peter Zijlstra
2019-06-28 15:30 ` Paul E. McKenney
2019-06-28 18:40 ` Sebastian Andrzej Siewior
2019-06-28 18:52 ` Paul E. McKenney
2019-06-28 19:24 ` Joel Fernandes
2019-06-28 20:04 ` Paul E. McKenney [this message]
2019-06-28 21:40 ` Joel Fernandes
2019-06-28 22:25 ` Paul E. McKenney
2019-06-28 23:12 ` Joel Fernandes
2019-06-29 0:06 ` Paul E. McKenney
2019-06-28 16:40 ` Joel Fernandes
2019-06-28 16:45 ` Joel Fernandes
2019-06-28 17:30 ` Paul E. McKenney
2019-06-28 17:41 ` Paul E. McKenney
2019-06-28 17:45 ` Sebastian Andrzej Siewior
2019-06-28 18:07 ` Joel Fernandes
2019-06-28 18:20 ` Sebastian Andrzej Siewior
2019-07-01 2:08 ` Joel Fernandes
2019-06-28 18:22 ` Paul E. McKenney
2019-06-28 19:29 ` Joel Fernandes
2019-06-28 20:06 ` Paul E. McKenney
2019-06-28 18:05 ` Joel Fernandes
2019-06-28 18:23 ` Paul E. McKenney
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=20190628200423.GB26519@linux.ibm.com \
--to=paulmck@linux.ibm.com \
--cc=bigeasy@linutronix.de \
--cc=jiangshanlai@gmail.com \
--cc=joel@joelfernandes.org \
--cc=josh@joshtriplett.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/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;
as well as URLs for NNTP newsgroup(s).