From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Josh Triplett <josh@joshtriplett.org>,
Steven Rostedt <rostedt@goodmis.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Lai Jiangshan <jiangshanlai@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] srcu: queue work without holding the lock
Date: Thu, 28 Sep 2017 18:10:46 -0700 [thread overview]
Message-ID: <20170929011046.GW3521@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170928160357.anfyrkwq32tyamez@linutronix.de>
On Thu, Sep 28, 2017 at 06:03:57PM +0200, Sebastian Andrzej Siewior wrote:
> On 2017-09-22 11:46:10 [-0700], Paul E. McKenney wrote:
> > On Fri, Sep 22, 2017 at 05:28:05PM +0200, Sebastian Andrzej Siewior wrote:
> > > On RT we can't invoke queue_delayed_work() within an atomic section
> > > (which is provided by raw_spin_lock_irqsave()).
> > > srcu_reschedule() invokes queue_delayed_work() outside of the
> > > raw_spin_lock_irq_rcu_node() section so this should be fine here, too.
> > > If the remaining callers of call_srcu() aren't atomic
> > > (spin_lock_irqsave() is fine) then this should work on RT, too.
> >
> > Just to make sure I understand... The problem is not the _irqsave,
> > but rather the raw_?
>
> exactly. The _irqsave is translated into a sleeping lock on RT and does
> not matter. The raw_ ones stay as they are and queue_delayed_work() uses
> sleeping locks itself and this is where things fall apart.
OK, internally I could get rid of raw_ at the expense of some code bloat,
but in the call_srcu() case, the caller might well hold a raw_ lock.
Thoughts?
Thanx, Paul
next prev parent reply other threads:[~2017-09-29 1:10 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-22 15:28 [PATCH 1/3] srcu: use cpu_online() instead custom check Sebastian Andrzej Siewior
2017-09-22 15:28 ` [PATCH 2/3] srcu: queue work without holding the lock Sebastian Andrzej Siewior
2017-09-22 18:46 ` Paul E. McKenney
2017-09-28 16:03 ` Sebastian Andrzej Siewior
2017-09-29 1:10 ` Paul E. McKenney [this message]
2017-10-10 21:43 ` Paul E. McKenney
2017-10-11 16:40 ` Sebastian Andrzej Siewior
2017-10-11 16:46 ` Paul E. McKenney
2017-10-12 8:53 ` Sebastian Andrzej Siewior
2017-10-12 18:24 ` Paul E. McKenney
2017-10-13 7:08 ` Sebastian Andrzej Siewior
2017-09-22 15:28 ` [PATCH 3/3] rcu/segcblist: include rcupdate.h Sebastian Andrzej Siewior
2017-09-22 18:47 ` Paul E. McKenney
2017-09-22 18:43 ` [PATCH 1/3] srcu: use cpu_online() instead custom check Paul E. McKenney
2017-09-28 16:02 ` Sebastian Andrzej Siewior
2017-09-29 1:09 ` 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=20170929011046.GW3521@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=bigeasy@linutronix.de \
--cc=jiangshanlai@gmail.com \
--cc=josh@joshtriplett.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=rostedt@goodmis.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.