linux-nvme.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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

  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).