From: paulmck@linux.ibm.com (Paul E. McKenney)
Subject: v5.0-rc2 and NVMeOF
Date: Tue, 26 Feb 2019 09:35:20 -0800 [thread overview]
Message-ID: <20190226173520.GA21832@linux.ibm.com> (raw)
In-Reply-To: <20190214010210.GM4240@linux.ibm.com>
On Wed, Feb 13, 2019@05:02:10PM -0800, Paul E. McKenney wrote:
> On Wed, Feb 13, 2019@04:21:53PM -0800, Bart Van Assche wrote:
> > On Wed, 2019-02-13@14:09 -0800, Paul E. McKenney wrote:
> > > commit 65f1b53aeb25a9bddabd08e37bb4c7246320f993
> > > Author: Paul E. McKenney <paulmck at linux.ibm.com>
> > > Date: Wed Feb 13 13:54:37 2019 -0800
> > >
> > > srcu: Remove cleanup_srcu_struct_quiesced()
> > >
> > > The cleanup_srcu_struct_quiesced() function was added because NVME
> > > used WQ_MEM_RECLAIM workqueues and SRCU did not, which meant that
> > > NVME workqueues waiting on SRCU workqueues could result in deadlocks
> > > during low-memory conditions. However, SRCU now also has WQ_MEM_RECLAIM
> > > workqueues, so there is no longer a potential for deadlock. Furthermore,
> > > it turns out to be extremely hard to use cleanup_srcu_struct_quiesced()
> > > correctly due to the fact that SRCU callback invocation accesses the
> > > srcu_struct structure's per-CPU data area just after callbacks are
> > > invoked. Therefore, the usual practice of using srcu_barrier() to wait
> > > for callbacks to be invoked before invoking cleanup_srcu_struct_quiesced()
> > > fails because SRCU's callback-invocation workqueue handler might be
> > > delayed, which can result in cleanup_srcu_struct_quiesced() being invoked
> > > (and thus freeing the per-CPU data) before the SRCU's callback-invocation
> > > workqueue handler is finished using that per-CPU data. Nor is this a
> > > theoretical problem: KASAN emitted use-after-free warnings because of
> > > this problem on actual runs.
> > >
> > > In short, NVME can now safely invoke cleanup_srcu_struct(), which
> > > avoids the use-after-free scenario. And cleanup_srcu_struct_quiesced()
> > > is quite difficult to use safely. This commit therefore removes
> > > cleanup_srcu_struct_quiesced(), switching its sole user back to
> > > cleanup_srcu_struct(). This effectively reverts the following pair
> > > of commits:
> > >
> > > f7194ac32ca2 ("srcu: Add cleanup_srcu_struct_quiesced()")
> > > 4317228ad9b8 ("nvme: Avoid flush dependency in delete controller flow")
> > >
> > > Reported-by: Bart Van Assche <bvanassche at acm.org>
> > > Signed-off-by: Paul E. McKenney <paulmck at linux.ibm.com>
> > >
> > > [ ... ]
> >
> > Reviewed-by: Bart Van Assche <bvanassche at acm.org>
>
> Applied thank you!
>
> Looking forward to hearing the results of testing as well!
The time during which I might reasonably push this into the upcoming
(v5.1) merge window is quickly drawing to a close. If you need this
before the v5.2 merge window, could you please let me know? If so,
a Tested-by would make things work much more smoothly.
Thanx, Paul
next prev parent reply other threads:[~2019-02-26 17:35 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-15 19:07 v5.0-rc2 and NVMeOF Bart Van Assche
2019-01-17 1:16 ` Sagi Grimberg
2019-02-11 17:24 ` Bart Van Assche
2019-02-11 21:08 ` Paul E. McKenney
2019-02-11 22:27 ` Bart Van Assche
2019-02-12 1:24 ` Paul E. McKenney
2019-02-12 16:47 ` Bart Van Assche
2019-02-12 17:47 ` Paul E. McKenney
2019-02-12 19:15 ` Paul E. McKenney
2019-02-13 0:44 ` Bart Van Assche
2019-02-13 1:10 ` Paul E. McKenney
2019-02-13 15:19 ` Paul E. McKenney
2019-02-13 15:24 ` Paul E. McKenney
2019-02-13 18:36 ` Bart Van Assche
2019-02-13 18:48 ` Paul E. McKenney
2019-02-13 19:12 ` Bart Van Assche
2019-02-13 19:30 ` Paul E. McKenney
2019-02-13 19:52 ` Paul E. McKenney
2019-02-13 21:00 ` Bart Van Assche
2019-02-13 22:09 ` Paul E. McKenney
2019-02-13 23:07 ` Paul E. McKenney
2019-02-14 0:21 ` Bart Van Assche
2019-02-14 1:02 ` Paul E. McKenney
2019-02-26 17:35 ` Paul E. McKenney [this message]
2019-02-26 17:47 ` Bart Van Assche
2019-02-26 18:12 ` Paul E. McKenney
2019-02-26 18:40 ` Bart Van Assche
2019-02-26 19:20 ` Paul E. McKenney
2019-02-26 23:48 ` Bart Van Assche
2019-02-27 16:04 ` Paul E. McKenney
2019-02-27 16:25 ` Bart Van Assche
2019-02-27 18:22 ` Paul E. McKenney
2019-02-13 19:13 ` Paul E. McKenney
2019-02-13 0:47 ` Bart Van Assche
2019-02-13 1:07 ` 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=20190226173520.GA21832@linux.ibm.com \
--to=paulmck@linux.ibm.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;
as well as URLs for NNTP newsgroup(s).