From: Keith Busch <kbusch@kernel.org>
To: Sagi Grimberg <sagi@grimberg.me>
Cc: Edmund Nadolski <edmund.nadolski@intel.com>,
Christoph Hellwig <hch@lst.de>,
linux-nvme@lists.infradead.org
Subject: Re: [PATCH 5/5] nvme: Wait for reset state when required
Date: Thu, 5 Sep 2019 14:55:01 -0600 [thread overview]
Message-ID: <20190905205501.GD25467@localhost.localdomain> (raw)
In-Reply-To: <a1895103-5906-7a46-9222-478bc76a2dbd@grimberg.me>
On Thu, Sep 05, 2019 at 01:47:26PM -0700, Sagi Grimberg wrote:
>
> > Disabling a controller in a path that resets it in a different
> > context needs to fence off other resets from occuring between these
> > actions. Provide a method to block until we've successfully entered a
> > reset state prior to disabling so that we can perform the controller
> > disabling without racing with another reset. Otherwise, that other reset
> > may either undo our teardown, or our teardown may undo the in-progress
> > reset's bringup.
>
> Why not simply flushing the reset work like nvme_reset_ctrl_sync?
>
> I might be out of context here...
It's not enough to know a current reset completes. We have to know that
another won't schedule, which the RESETTING state guarantees.
More context:
This is for when we can't re-enable the controller in the same context
as when we have to disable it.
For example, PCIe FLR occurs in two stages. Suspend/resume is another
example. An IO timeout occuring concurrently with either gets the
wrong end result because the timeout tries to incorrectly re-enable the
device. This patch appropriatly synchronizes everyone through the state
machine to prevent these things from running concurrently.
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
next prev parent reply other threads:[~2019-09-05 20:56 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-05 14:26 [PATCH 1/5] nvme: Restart request timers in resetting state Keith Busch
2019-09-05 14:26 ` [PATCH 2/5] nvme: Prevent resets during paused states Keith Busch
2019-09-05 20:23 ` Sagi Grimberg
2019-09-05 20:35 ` Keith Busch
2019-09-05 20:42 ` Sagi Grimberg
2019-09-05 14:26 ` [PATCH 3/5] nvme-pci: Free tagset if no IO queues Keith Busch
2019-09-05 20:24 ` Sagi Grimberg
2019-09-05 20:40 ` Keith Busch
2019-09-05 20:43 ` Sagi Grimberg
2019-09-05 14:26 ` [PATCH 4/5] nvme: Remove ADMIN_ONLY state Keith Busch
2019-09-05 14:26 ` [PATCH 5/5] nvme: Wait for reset state when required Keith Busch
2019-09-05 15:57 ` James Smart
2019-09-05 20:47 ` Sagi Grimberg
2019-09-05 20:55 ` Keith Busch [this message]
2019-09-05 20:13 ` [PATCH 1/5] nvme: Restart request timers in resetting state Sagi Grimberg
2019-09-05 20:25 ` Keith Busch
2019-09-05 20:39 ` Sagi Grimberg
2019-09-05 21:36 ` James Smart
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=20190905205501.GD25467@localhost.localdomain \
--to=kbusch@kernel.org \
--cc=edmund.nadolski@intel.com \
--cc=hch@lst.de \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
/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.