1. 09 1月, 2015 5 次提交
    • K
      NVMe: Start and stop h/w queues on reset · c9d3bf88
      Keith Busch 提交于
      This freezes and stops all the queues on device shutdown and restarts
      them on resume. This fixes hotplug and reset issues when the controller
      is actively being used.
      Signed-off-by: NKeith Busch <keith.busch@intel.com>
      Signed-off-by: NJens Axboe <axboe@fb.com>
      c9d3bf88
    • K
      NVMe: Command abort handling fixes · cef6a948
      Keith Busch 提交于
      Aborts all requeued commands prior to killing the request_queue. For
      commands that time out on a dying request queue, set the "Do Not Retry"
      bit on the command status so the command cannot be requeued. Finanally, if
      the driver is requested to abort a command it did not start, do nothing.
      Signed-off-by: NKeith Busch <keith.busch@intel.com>
      Signed-off-by: NJens Axboe <axboe@fb.com>
      cef6a948
    • K
      NVMe: Admin queue removal handling · 0fb59cbc
      Keith Busch 提交于
      This protects admin queue access on shutdown. When the controller is
      disabled, the queue is frozen to prevent new entry, and unfrozen on
      resume, and fixes cq_vector signedness to not suspend a queue twice.
      
      Since unfreezing the queue makes it available for commands, it requires
      the queue be initialized, so this moves this part after that.
      
      Special handling is done when the device is unresponsive during
      shutdown. This can be optimized to not require subsequent commands to
      timeout, but saving that fix for later.
      
      This patch also removes the kill signals in this path that were left-over
      artifacts from the blk-mq conversion and no longer necessary.
      Signed-off-by: NKeith Busch <keith.busch@intel.com>
      Signed-off-by: NJens Axboe <axboe@fb.com>
      0fb59cbc
    • K
      NVMe: Reference count admin queue usage · ea191d2f
      Keith Busch 提交于
      Since there is no gendisk associated with the admin queue, the driver
      needs to hold a reference to it until all open references to the
      controller are closed.
      
      This also combines queue cleanup with freeing the tag set since these
      should not be separate.
      Signed-off-by: NKeith Busch <keith.busch@intel.com>
      Signed-off-by: NJens Axboe <axboe@fb.com>
      ea191d2f
    • K
      NVMe: Start all requests · c917dfe5
      Keith Busch 提交于
      Once the nvme callback is set for a request, the driver can start it
      and make it available for timeout handling. For timed out commands on a
      device that is not initialized, this fixes potential deadlocks that can
      occur on startup and shutdown when a device is unresponsive since they
      can now be cancelled.
      
      Asynchronous requests do not have any expected timeout, so these are
      using the new "REQ_NO_TIMEOUT" request flags.
      Signed-off-by: NKeith Busch <keith.busch@intel.com>
      Signed-off-by: NJens Axboe <axboe@fb.com>
      c917dfe5
  2. 03 1月, 2015 1 次提交
  3. 23 12月, 2014 1 次提交
  4. 12 12月, 2014 2 次提交
    • J
      NVMe: fix race condition in nvme_submit_sync_cmd() · 849c6e77
      Jens Axboe 提交于
      If we have a race between the schedule timing out and the command
      completing, we could have the task issuing the command exit
      nvme_submit_sync_cmd() while the irq is running sync_completion().
      If that happens, we could be corrupting memory, since the stack
      that held 'cmdinfo' is no longer valid.
      
      Fix this by always calling nvme_abort_cmd_info(). Once that call
      completes, we know that we have either run sync_completion() if
      the completion came in, or that we will never run it since we now
      have special_completion() as the command callback handler.
      Acked-by: NKeith Busch <keith.busch@intel.com>
      Signed-off-by: NJens Axboe <axboe@fb.com>
      849c6e77
    • J
      NVMe: fix retry/error logic in nvme_queue_rq() · fe54303e
      Jens Axboe 提交于
      The logic around retrying and erroring IO in nvme_queue_rq() is broken
      in a few ways:
      
      - If we fail allocating dma memory for a discard, we return retry. We
        have the 'iod' stored in ->special, but we free the 'iod'.
      
      - For a normal request, if we fail dma mapping of setting up prps, we
        have the same iod situation. Additionally, we haven't set the callback
        for the request yet, so we also potentially leak IOMMU resources.
      
      Get rid of the ->special 'iod' store. The retry is uncommon enough that
      it's not worth optimizing for or holding on to resources to attempt to
      speed it up. Additionally, it's usually best practice to free any
      request related resources when doing retries.
      Acked-by: NKeith Busch <keith.busch@intel.com>
      Signed-off-by: NJens Axboe <axboe@fb.com>
      fe54303e
  5. 11 12月, 2014 3 次提交
  6. 04 12月, 2014 1 次提交
  7. 22 11月, 2014 1 次提交
  8. 21 11月, 2014 2 次提交
  9. 20 11月, 2014 1 次提交
  10. 18 11月, 2014 3 次提交
  11. 11 11月, 2014 1 次提交
  12. 06 11月, 2014 1 次提交
  13. 05 11月, 2014 18 次提交