All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Sagi Grimberg <sagi@grimberg.me>
Cc: Keith Busch <kbusch@kernel.org>,
	Anton Eidelman <anton@lightbitslabs.com>,
	Christoph Hellwig <hch@lst.de>,
	linux-nvme@lists.infradead.org
Subject: Re: [PATCH v2 RFC 6/6] nvme-core: fix deadlock in disconnect during scan_work and/or ana_work
Date: Wed, 24 Jun 2020 08:43:09 +0200	[thread overview]
Message-ID: <20200624064309.GG17594@lst.de> (raw)
In-Reply-To: <20200624001853.5408-7-sagi@grimberg.me>

On Tue, Jun 23, 2020 at 05:18:53PM -0700, Sagi Grimberg wrote:
> From: Anton Eidelman <anton@lightbitslabs.com>
> 
> A deadlock happens in the following scenario with multipath:
> 1) scan_work(nvme0) detects a new nsid while nvme0
>     is an optimized path to it, path nvme1 happens to be
>     inaccessible.
> 
> 2) Before scan_work is complete nvme0 disconnect is initiated
>     nvme_delete_ctrl_sync() sets nvme0 state to NVME_CTRL_DELETING
> 
> 3) scan_work(1) attempts to submit IO,
>     but nvme_path_is_optimized() observes nvme0 is not LIVE.
>     Since nvme1 is a possible path IO is requeued and scan_work hangs.

I'm really worried about another flag outside the state machine.  If
we really need a multi-step deletion we should have
NVME_CTRL_DELETE_START, NVME_CTRL_DELETE_CONT or so states and run
this via the state machine.

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

  reply	other threads:[~2020-06-24  6:43 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-24  0:18 [PATCH v2 for-5.8-rc 0/6] address deadlocks in high stress ns scanning and ana updates Sagi Grimberg
2020-06-24  0:18 ` [PATCH v2 for-5.8-rc 1/6] nvme: fix possible deadlock when I/O is blocked Sagi Grimberg
2020-06-24  6:29   ` Christoph Hellwig
2020-06-24  6:54     ` Sagi Grimberg
2020-06-24  6:57       ` Christoph Hellwig
2020-06-24  7:09         ` Sagi Grimberg
2020-07-07 10:57       ` Anthony Iliopoulos
2020-07-08 14:42         ` Christoph Hellwig
2020-07-10  4:47           ` Sagi Grimberg
2020-07-14 11:12         ` Christoph Hellwig
2020-06-24  0:18 ` [PATCH v2 for-5.8-rc 2/6] nvme-multipath: fix deadlock between ana_work and scan_work Sagi Grimberg
2020-06-24  6:34   ` Christoph Hellwig
2020-06-24  6:56     ` Sagi Grimberg
2020-06-24  0:18 ` [PATCH v2 for-5.8-rc 3/6] nvme: don't protect ns mutation with ns->head->lock Sagi Grimberg
2020-06-24  6:37   ` Christoph Hellwig
2020-06-24  6:58     ` Sagi Grimberg
2020-06-24  8:24     ` Sagi Grimberg
2020-06-24  0:18 ` [PATCH v2 for-5.8-rc 4/6] nvme-multipath: fix deadlock due to head->lock Sagi Grimberg
2020-06-24  6:39   ` Christoph Hellwig
2020-06-24  7:00     ` Sagi Grimberg
2020-06-24  0:18 ` [PATCH v2 for-5.8-rc 5/6] nvme-multipath: fix bogus request queue reference put Sagi Grimberg
2020-06-24  6:40   ` Christoph Hellwig
2020-06-24  0:18 ` [PATCH v2 RFC 6/6] nvme-core: fix deadlock in disconnect during scan_work and/or ana_work Sagi Grimberg
2020-06-24  6:43   ` Christoph Hellwig [this message]
2020-06-24  7:13     ` Sagi Grimberg

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=20200624064309.GG17594@lst.de \
    --to=hch@lst.de \
    --cc=anton@lightbitslabs.com \
    --cc=kbusch@kernel.org \
    --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.