Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1324167

Re: [PATCH] NVMe: do not touch sq door bell if nvmeq has been suspended

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

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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