1. 01 5月, 2019 1 次提交
  2. 14 3月, 2019 1 次提交
  3. 20 2月, 2019 3 次提交
  4. 06 2月, 2019 1 次提交
  5. 04 2月, 2019 1 次提交
  6. 10 1月, 2019 1 次提交
  7. 19 12月, 2018 1 次提交
  8. 13 12月, 2018 2 次提交
  9. 12 12月, 2018 1 次提交
  10. 08 12月, 2018 5 次提交
  11. 01 12月, 2018 1 次提交
  12. 09 11月, 2018 1 次提交
  13. 18 10月, 2018 1 次提交
  14. 02 10月, 2018 1 次提交
  15. 28 9月, 2018 1 次提交
  16. 30 7月, 2018 1 次提交
  17. 28 7月, 2018 3 次提交
  18. 23 7月, 2018 2 次提交
  19. 22 6月, 2018 1 次提交
    • J
      nvme-pci: limit max IO size and segments to avoid high order allocations · 943e942e
      Jens Axboe 提交于
      nvme requires an sg table allocation for each request. If the request
      is large, then the allocation can become quite large. For instance,
      with our default software settings of 1280KB IO size, we'll need
      10248 bytes of sg table. That turns into a 2nd order allocation,
      which we can't always guarantee. If we fail the allocation, blk-mq
      will retry it later. But there's no guarantee that we'll EVER be
      able to allocate that much contigious memory.
      
      Limit the IO size such that we never need more than a single page
      of memory. That's a lot faster and more reliable. Then back that
      allocation with a mempool, so that we know we'll always be able
      to succeed the allocation at some point.
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Acked-by: NKeith Busch <keith.busch@intel.com>
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      943e942e
  20. 14 6月, 2018 1 次提交
  21. 09 6月, 2018 1 次提交
  22. 01 6月, 2018 3 次提交
  23. 23 5月, 2018 1 次提交
    • J
      nvme: fix lockdep warning in nvme_mpath_clear_current_path · 978628ec
      Johannes Thumshirn 提交于
      When running blktest's nvme/005 with a lockdep enabled kernel the test
      case fails due to the following lockdep splat in dmesg:
      
       =============================
       WARNING: suspicious RCU usage
       4.17.0-rc5 #881 Not tainted
       -----------------------------
       drivers/nvme/host/nvme.h:457 suspicious rcu_dereference_check() usage!
      
       other info that might help us debug this:
      
       rcu_scheduler_active = 2, debug_locks = 1
       3 locks held by kworker/u32:5/1102:
        #0:         (ptrval) ((wq_completion)"nvme-wq"){+.+.}, at: process_one_work+0x152/0x5c0
        #1:         (ptrval) ((work_completion)(&ctrl->scan_work)){+.+.}, at: process_one_work+0x152/0x5c0
        #2:         (ptrval) (&subsys->lock#2){+.+.}, at: nvme_ns_remove+0x43/0x1c0 [nvme_core]
      
      The only caller of nvme_mpath_clear_current_path() is nvme_ns_remove()
      which holds the subsys lock so it's likely a false positive, but when
      using rcu_access_pointer(), we're telling rcu and lockdep that we're
      only after the pointer falue.
      
      Fixes: 32acab31 ("nvme: implement multipath access to nvme subsystems")
      Signed-off-by: NJohannes Thumshirn <jthumshirn@suse.de>
      Suggested-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NKeith Busch <keith.busch@intel.com>
      978628ec
  24. 19 5月, 2018 1 次提交
  25. 12 5月, 2018 1 次提交
    • J
      nvme: add quirk to force medium priority for SQ creation · 9abd68ef
      Jens Axboe 提交于
      Some P3100 drives have a bug where they think WRRU (weighted round robin)
      is always enabled, even though the host doesn't set it. Since they think
      it's enabled, they also look at the submission queue creation priority. We
      used to set that to MEDIUM by default, but that was removed in commit
      81c1cd98. This causes various issues on that drive. Add a quirk to
      still set MEDIUM priority for that controller.
      
      Fixes: 81c1cd98 ("nvme/pci: Don't set reserved SQ create flags")
      Cc: stable@vger.kernel.org
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NKeith Busch <keith.busch@intel.com>
      9abd68ef
  26. 03 5月, 2018 1 次提交
  27. 12 4月, 2018 2 次提交
    • J
      nvme: expand nvmf_check_if_ready checks · bb06ec31
      James Smart 提交于
      The nvmf_check_if_ready() checks that were added are very simplistic.
      As such, the routine allows a lot of cases to fail ios during windows
      of reset or re-connection. In cases where there are not multi-path
      options present, the error goes back to the callee - the filesystem
      or application. Not good.
      
      The common routine was rewritten and calling syntax slightly expanded
      so that per-transport is_ready routines don't need to be present.
      The transports now call the routine directly. The routine is now a
      fabrics routine rather than an inline function.
      
      The routine now looks at controller state to decide the action to
      take. Some states mandate io failure. Others define the condition where
      a command can be accepted.  When the decision is unclear, a generic
      queue-or-reject check is made to look for failfast or multipath ios and
      only fails the io if it is so marked. Otherwise, the io will be queued
      and wait for the controller state to resolve.
      
      Admin commands issued via ioctl share a live admin queue with commands
      from the transport for controller init. The ioctls could be intermixed
      with the initialization commands. It's possible for the ioctl cmd to
      be issued prior to the controller being enabled. To block this, the
      ioctl admin commands need to be distinguished from admin commands used
      for controller init. Added a USERCMD nvme_req(req)->rq_flags bit to
      reflect this division and set it on ioctls requests.  As the
      nvmf_check_if_ready() routine is called prior to nvme_setup_cmd(),
      ensure that commands allocated by the ioctl path (actually anything
      in core.c) preps the nvme_req(req) before starting the io. This will
      preserve the USERCMD flag during execution and/or retry.
      Signed-off-by: NJames Smart <james.smart@broadcom.com>
      Reviewed-by: NSagi Grimberg <sagi@grimberg.e>
      Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: NKeith Busch <keith.busch@intel.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      bb06ec31
    • J
      nvme: unexport nvme_start_keep_alive · 00b683db
      Johannes Thumshirn 提交于
      nvme_start_keep_alive() isn't used outside core.c so unexport it and
      make it static.
      Signed-off-by: NJohannes Thumshirn <jthumshirn@suse.de>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NKeith Busch <keith.busch@intel.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      00b683db