From: keith.busch@intel.com (Keith Busch)
Subject: [PATCH 1/2] NVMe: Make surprise removal work again
Date: Tue, 2 Feb 2016 01:17:52 +0000 [thread overview]
Message-ID: <20160202011752.GB4679@localhost.localdomain> (raw)
In-Reply-To: <B58D82457FDA0744A320A2FC5AC253B93D3D7E57@fmsmsx104.amr.corp.intel.com>
On Mon, Feb 01, 2016@07:27:23AM -0800, Busch, Keith wrote:
> the direction I was given was to move the request ending to the block layer
> when we kill it, so this won't be necessary in the next revision (will be
> sent out today).
After merging and moving io ending to the block layer, something appears
broken. Not sure what's going on, so just posting here in case there's
better ideas.
The test runs buffered writes to an nvme drive (ex: dd if=/dev/zero
of=/dev/nvme0n1 bs=16M), then yank the drive when that ramps up.
Device removal completes after a few seconds, and /dev/nvme0n1 is no
longer present. However, the 'dd' task never completes, with kernel
stack trace:
[<ffffffff81093fb0>] __mod_timer+0xd4/0xe6
[<ffffffff810939bf>] process_timeout+0x0/0xc
[<ffffffff810fcad7>] balance_dirty_pages_ratelimited+0x8b1/0xa05
[<ffffffff8116a2a3>] __set_page_dirty.constprop.61+0x81/0x9f
[<ffffffff810f3457>] generic_perform_write+0x15a/0x1d1
[<ffffffff81157095>] generic_update_time+0x9f/0xaa
[<ffffffff810f4965>] __generic_file_write_iter+0xea/0x146
[<ffffffff8116d2a3>] blkdev_write_iter+0x78/0xf5
[<ffffffff811429b4>] __vfs_write+0x83/0xab
[<ffffffff81143cda>] vfs_write+0x87/0xdd
[<ffffffff81143ed7>] SyS_write+0x56/0x8a
[<ffffffff81472657>] entry_SYSCALL_64_fastpath+0x12/0x6a
[<ffffffffffffffff>] 0xffffffffffffffff
If driver ends all IO's it knows about and blk_cleanup_queue returns,
then the driver did it's part as far as I know. Not sure how to get this
to end with the expected IO error, but I'm pretty sure this used to work.
next prev parent reply other threads:[~2016-02-02 1:17 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-25 21:23 [PATCH 1/2] NVMe: Make surprise removal work again Keith Busch
2016-01-25 21:23 ` [PATCH 2/2] NVMe: Fix io incapable return values Keith Busch
2016-01-26 16:54 ` Christoph Hellwig
2016-01-26 18:11 ` Ming Lin
2016-01-27 11:19 ` Sagi Grimberg
2016-01-26 16:53 ` [PATCH 1/2] NVMe: Make surprise removal work again Christoph Hellwig
2016-01-26 23:59 ` Keith Busch
2016-01-27 11:47 ` Sagi Grimberg
2016-01-27 14:19 ` Keith Busch
2016-01-28 14:48 ` Sagi Grimberg
2016-01-28 14:55 ` Keith Busch
2016-01-28 15:20 ` Sagi Grimberg
2016-02-01 15:01 ` Wenbo Wang
2016-02-01 15:27 ` Busch, Keith
[not found] ` <B58D82457FDA0744A320A2FC5AC253B93D3D7E57@fmsmsx104.amr.corp.intel.com>
2016-02-02 1:17 ` Keith Busch [this message]
2016-02-02 2:41 ` Wenbo Wang
2016-02-02 5:29 ` Keith Busch
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=20160202011752.GB4679@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 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).