1. 30 3月, 2018 14 次提交
  2. 28 3月, 2018 1 次提交
  3. 26 3月, 2018 18 次提交
  4. 09 3月, 2018 1 次提交
  5. 01 3月, 2018 1 次提交
  6. 28 2月, 2018 1 次提交
    • B
      nvme-multipath: fix sysfs dangerously created links · 9bd82b1a
      Baegjae Sung 提交于
      If multipathing is enabled, each NVMe subsystem creates a head
      namespace (e.g., nvme0n1) and multiple private namespaces
      (e.g., nvme0c0n1 and nvme0c1n1) in sysfs. When creating links for
      private namespaces, links of head namespace are used, so the
      namespace creation order must be followed (e.g., nvme0n1 ->
      nvme0c1n1). If the order is not followed, links of sysfs will be
      incomplete or kernel panic will occur.
      
      The kernel panic was:
        kernel BUG at fs/sysfs/symlink.c:27!
        Call Trace:
          nvme_mpath_add_disk_links+0x5d/0x80 [nvme_core]
          nvme_validate_ns+0x5c2/0x850 [nvme_core]
          nvme_scan_work+0x1af/0x2d0 [nvme_core]
      
      Correct order
      Context A     Context B
      nvme0n1
      nvme0c0n1     nvme0c1n1
      
      Incorrect order
      Context A     Context B
                    nvme0c1n1
      nvme0n1
      nvme0c0n1
      
      The nvme_mpath_add_disk (for creating head namespace) is called
      just before the nvme_mpath_add_disk_links (for creating private
      namespaces). In nvme_mpath_add_disk, the first context acquires
      the lock of subsystem and creates a head namespace, and other
      contexts do nothing by checking GENHD_FL_UP of a head namespace
      after waiting to acquire the lock. We verified the code with or
      without multipathing using three vendors of dual-port NVMe SSDs.
      Signed-off-by: NBaegjae Sung <baegjae@gmail.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NKeith Busch <keith.busch@intel.com>
      9bd82b1a
  7. 26 2月, 2018 1 次提交
  8. 22 2月, 2018 2 次提交
  9. 14 2月, 2018 1 次提交
    • N
      nvme-rdma: fix sysfs invoked reset_ctrl error flow · 8000d1fd
      Nitzan Carmi 提交于
      When reset_controller that is invoked by sysfs fails,
      it enters an error flow which practically removes the
      nvme ctrl entirely (similar to delete_ctrl flow). It
      causes the system to hang, since a sysfs attribute cannot
      be unregistered by one of its own methods.
      
      This can be fixed by calling delete_ctrl as a work rather
      than sequential code. In addition, it should give the ctrl
      a chance to recover using reconnection mechanism (consistant
      with FC reset_ctrl error flow). Also, while we're here, return
      suitable errno in case the reset ended with non live ctrl.
      Signed-off-by: NNitzan Carmi <nitzanc@mellanox.com>
      Reviewed-by: NMax Gurtovoy <maxg@mellanox.com>
      Signed-off-by: NSagi Grimberg <sagi@grimberg.me>
      8000d1fd