Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1324167
| From | Keith Busch <keith.busch@intel.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH] NVMe: do not touch sq door bell if nvmeq has been suspended |
| Date | 2016-02-02 15:50 +0100 |
| Message-ID | <qXKri-4kd-65@gated-at.bofh.it> (permalink) |
| References | (1 earlier) <qXpZw-5Jg-1@gated-at.bofh.it> <qXIza-2Za-31@gated-at.bofh.it> <qXIz9-2Za-29@gated-at.bofh.it> <qXK7T-4be-3@gated-at.bofh.it> <qXKhA-4fv-21@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Tue, Feb 02, 2016 at 04:33:10PM +0200, Sagi Grimberg wrote: > Hey Keith, > > >>First of all, I think we need to cancel all > >>inflight requests before nvme_dev_unmap. > > > >IO cancelling is where it is because it protects against host memory > >corruption. If you're going to mess with the ordering, just make sure > >the PCI device is disabled from bus mastering first. > > Little help? :) > > What corruption is the ordering protecting against? Sure thing. :) We free the transfer buffers when a command is cancelled. The controller, however, may still own the command and may try to write to them. We have to fence the controller off from being able to do that, so we can't cancel inflight commands while the PCI device is still bus master enabled. In a perfect world, we could trust in disabling with NVMe registers, but sometimes we can't rely on that. This was commit 07836e659c81ec6b0d683dfbf7958339a22a7b69, which might explain the scenario a little better, and was reported by end user.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH] NVMe: do not touch sq door bell if nvmeq has been suspended Wenbo Wang <mail_weber_wang@163.com> - 2016-02-01 16:50 +0100
RE: [PATCH] NVMe: do not touch sq door bell if nvmeq has been suspended "Busch, Keith" <keith.busch@intel.com> - 2016-02-01 17:00 +0100
RE: [PATCH] NVMe: do not touch sq door bell if nvmeq has been suspended Wenbo Wang <wenbo.wang@memblaze.com> - 2016-02-01 17:20 +0100
Re: [PATCH] NVMe: do not touch sq door bell if nvmeq has been suspended Jens Axboe <axboe@fb.com> - 2016-02-01 18:00 +0100
Re: [PATCH] NVMe: do not touch sq door bell if nvmeq has been suspended Sagi Grimberg <sagig@dev.mellanox.co.il> - 2016-02-02 13:50 +0100
Re: [PATCH] NVMe: do not touch sq door bell if nvmeq has been suspended Keith Busch <keith.busch@intel.com> - 2016-02-02 15:30 +0100
Re: [PATCH] NVMe: do not touch sq door bell if nvmeq has been suspended Sagi Grimberg <sagig@dev.mellanox.co.il> - 2016-02-02 15:40 +0100
Re: [PATCH] NVMe: do not touch sq door bell if nvmeq has been suspended Keith Busch <keith.busch@intel.com> - 2016-02-02 15:50 +0100
Re: [PATCH] NVMe: do not touch sq door bell if nvmeq has been suspended Sagi Grimberg <sagig@dev.mellanox.co.il> - 2016-02-02 18:30 +0100
Re: [PATCH] NVMe: do not touch sq door bell if nvmeq has been suspended Keith Busch <keith.busch@intel.com> - 2016-02-02 18:30 +0100
Re: [PATCH] NVMe: do not touch sq door bell if nvmeq has been suspended Keith Busch <keith.busch@intel.com> - 2016-02-03 15:50 +0100
Re: [PATCH] NVMe: do not touch sq door bell if nvmeq has been suspended Keith Busch <keith.busch@intel.com> - 2016-02-03 17:40 +0100
Re: [PATCH] NVMe: do not touch sq door bell if nvmeq has been suspended Sagi Grimberg <sagig@dev.mellanox.co.il> - 2016-02-07 14:50 +0100
Re: [PATCH] NVMe: do not touch sq door bell if nvmeq has been suspended Keith Busch <keith.busch@intel.com> - 2016-02-08 16:10 +0100
csiph-web