From: keith.busch@intel.com (Keith Busch)
Subject: [PATCH 3/4] NVMe: Surprise removal fixes
Date: Mon, 8 Feb 2016 23:48:55 +0000 [thread overview]
Message-ID: <20160208234855.GA3058@localhost.localdomain> (raw)
In-Reply-To: <20160208183823.GA29157@localhost.localdomain>
On Mon, Feb 08, 2016@06:38:23PM +0000, Keith Busch wrote:
> On Mon, Feb 08, 2016@10:16:40AM -0800, Christoph Hellwig wrote:
> > Do we really still need all this magic if ->queue_rq returns a failure
> > if the queue is dying?
>
> This is far from perfect. Let me try explaining what's happening, then
> I hope to abandon this patch and do it correctly. :)
I've a new patch that passes all my tests, including the removal deadlock
using device states.
I have namespace capacity set to 0 and revalidate to get buffered writers
to end. The error handling is done in the nvme_workq, which currently
has WQ_MEM_RECLAIM set. That trigger a warning when revalidate_disk
attempts to sync with a non-MEM_RECLAIM work queue, so I removed the
flag from NVMe's to suppress the warning, but I don't see what having
that flag gained us in the first place. It looks to me that it just
spawns a rescuer, but do we need that?
next prev parent reply other threads:[~2016-02-08 23:48 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-03 16:05 [PATCH 0/4] NVMe: Surprise removal fixes Keith Busch
2016-02-03 16:05 ` [PATCH 1/4] NVMe: Fix io incapable return values Keith Busch
2016-02-04 15:55 ` Sagi Grimberg
2016-02-08 18:10 ` Christoph Hellwig
2016-02-03 16:05 ` [PATCH 2/4] NVMe: Sync stopped queues with block layer Keith Busch
2016-02-04 15:57 ` Sagi Grimberg
2016-02-04 16:00 ` Keith Busch
2016-02-08 18:11 ` Christoph Hellwig
2016-02-03 16:05 ` [PATCH 3/4] NVMe: Surprise removal fixes Keith Busch
2016-02-08 18:16 ` Christoph Hellwig
2016-02-08 18:38 ` Keith Busch
2016-02-08 23:48 ` Keith Busch [this message]
2016-02-03 16:05 ` [PATCH 4/4] blk-mq: End unstarted requests on dying queue Keith Busch
2016-02-04 15:59 ` Sagi Grimberg
2016-02-08 18:13 ` Christoph Hellwig
2016-02-04 3:25 ` [PATCH 0/4] NVMe: Surprise removal fixes Wenbo Wang
2016-02-04 15:52 ` Keith Busch
2016-02-04 15:55 ` 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=20160208234855.GA3058@localhost.localdomain \
--to=keith.busch@intel.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 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.