From: hch@lst.de (Christoph Hellwig)
Subject: [PATCH 1/2] nvme: fix multiple ctrl removal scheduling
Date: Wed, 24 May 2017 11:37:55 +0200 [thread overview]
Message-ID: <20170524093755.GA17483@lst.de> (raw)
In-Reply-To: <20170523221545.GA23946@dhcp-216.srv.tuxera.com>
On Wed, May 24, 2017@01:15:47AM +0300, Rakesh Pandit wrote:
> Commit c5f6ce97c1210 tries to address multiple resets but fails as
> work_busy doesn't involve any synchronization and can fail. This is
> reproducible easily as can be seen by WARNING below which is triggered
> with line:
>
> WARN_ON(dev->ctrl.state == NVME_CTRL_RESETTING)
>
> Allowing multiple resets can result in multiple controller removal as
> well if different conditions inside nvme_reset_work fail and which
> might deadlock on device_release_driver.
>
> This patch addresses the problem by using state of controller to
> decide whether reset should be queued or not as state change is
> synchronizated using controller spinlock.
But we don't hold the lock over the check and the decision. I suspect
what we need to do is to actually change to the resetting state
before queueing up the reset work. Can you give that a spin?
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Rakesh Pandit <rakesh@tuxera.com>
Cc: linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org,
Keith Busch <keith.busch@intel.com>, Jens Axboe <axboe@fb.com>,
Christoph Hellwig <hch@lst.de>, Sagi Grimberg <sagi@grimberg.me>
Subject: Re: [PATCH 1/2] nvme: fix multiple ctrl removal scheduling
Date: Wed, 24 May 2017 11:37:55 +0200 [thread overview]
Message-ID: <20170524093755.GA17483@lst.de> (raw)
In-Reply-To: <20170523221545.GA23946@dhcp-216.srv.tuxera.com>
On Wed, May 24, 2017 at 01:15:47AM +0300, Rakesh Pandit wrote:
> Commit c5f6ce97c1210 tries to address multiple resets but fails as
> work_busy doesn't involve any synchronization and can fail. This is
> reproducible easily as can be seen by WARNING below which is triggered
> with line:
>
> WARN_ON(dev->ctrl.state == NVME_CTRL_RESETTING)
>
> Allowing multiple resets can result in multiple controller removal as
> well if different conditions inside nvme_reset_work fail and which
> might deadlock on device_release_driver.
>
> This patch addresses the problem by using state of controller to
> decide whether reset should be queued or not as state change is
> synchronizated using controller spinlock.
But we don't hold the lock over the check and the decision. I suspect
what we need to do is to actually change to the resetting state
before queueing up the reset work. Can you give that a spin?
next prev parent reply other threads:[~2017-05-24 9:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-23 22:15 [PATCH 1/2] nvme: fix multiple ctrl removal scheduling Rakesh Pandit
2017-05-23 22:15 ` Rakesh Pandit
2017-05-24 9:37 ` Christoph Hellwig [this message]
2017-05-24 9:37 ` Christoph Hellwig
2017-05-24 10:25 ` Rakesh Pandit
2017-05-24 10:25 ` Rakesh Pandit
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=20170524093755.GA17483@lst.de \
--to=hch@lst.de \
/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.