1. 07 10月, 2020 20 次提交
  2. 27 9月, 2020 2 次提交
  3. 25 9月, 2020 2 次提交
  4. 17 9月, 2020 1 次提交
    • C
      nvme-core: get/put ctrl and transport module in nvme_dev_open/release() · 52a3974f
      Chaitanya Kulkarni 提交于
      Get and put the reference to the ctrl in the nvme_dev_open() and
      nvme_dev_release() before and after module get/put for ctrl in char
      device file operations.
      
      Introduce char_dev relase function, get/put the controller and module
      which allows us to fix the potential Oops which can be easily reproduced
      with a passthru ctrl (although the problem also exists with pure user
      access):
      
      Entering kdb (current=0xffff8887f8290000, pid 3128) on processor 30 Oops: (null)
      due to oops @ 0xffffffffa01019ad
      CPU: 30 PID: 3128 Comm: bash Tainted: G        W  OE     5.8.0-rc4nvme-5.9+ #35
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.4
      RIP: 0010:nvme_free_ctrl+0x234/0x285 [nvme_core]
      Code: 57 10 a0 e8 73 bf 02 e1 ba 3d 11 00 00 48 c7 c6 98 33 10 a0 48 c7 c7 1d 57 10 a0 e8 5b bf 02 e1 8
      RSP: 0018:ffffc90001d63de0 EFLAGS: 00010246
      RAX: ffffffffa05c0440 RBX: ffff8888119e45a0 RCX: 0000000000000000
      RDX: 0000000000000000 RSI: ffff8888177e9550 RDI: ffff8888119e43b0
      RBP: ffff8887d4768000 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: ffffc90001d63c90 R12: ffff8888119e43b0
      R13: ffff8888119e5108 R14: dead000000000100 R15: ffff8888119e5108
      FS:  00007f1ef27b0740(0000) GS:ffff888817600000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: ffffffffa05c0470 CR3: 00000007f6bee000 CR4: 00000000003406e0
      Call Trace:
       device_release+0x27/0x80
       kobject_put+0x98/0x170
       nvmet_passthru_ctrl_disable+0x4a/0x70 [nvmet]
       nvmet_passthru_enable_store+0x4c/0x90 [nvmet]
       configfs_write_file+0xe6/0x150
       vfs_write+0xba/0x1e0
       ksys_write+0x5f/0xe0
       do_syscall_64+0x52/0xb0
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      RIP: 0033:0x7f1ef1eb2840
      Code: Bad RIP value.
      RSP: 002b:00007fffdbff0eb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
      RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f1ef1eb2840
      RDX: 0000000000000002 RSI: 00007f1ef27d2000 RDI: 0000000000000001
      RBP: 00007f1ef27d2000 R08: 000000000000000a R09: 00007f1ef27b0740
      R10: 0000000000000001 R11: 0000000000000246 R12: 00007f1ef2186400
      R13: 0000000000000002 R14: 0000000000000001 R15: 0000000000000000
      
      With this patch fix we take the module ref count in nvme_dev_open() and
      release that ref count in newly introduced nvme_dev_release().
      Signed-off-by: NChaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      52a3974f
  5. 09 9月, 2020 1 次提交
    • J
      nvme: Revert: Fix controller creation races with teardown flow · b63de840
      James Smart 提交于
      The indicated patch introduced a barrier in the sysfs_delete attribute
      for the controller that rejects the request if the controller isn't
      created. "Created" is defined as at least 1 call to nvme_start_ctrl().
      
      This is problematic in error-injection testing.  If an error occurs on
      the initial attempt to create an association and the controller enters
      reconnect(s) attempts, the admin cannot delete the controller until
      either there is a successful association created or ctrl_loss_tmo
      times out.
      
      Where this issue is particularly hurtful is when the "admin" is the
      nvme-cli, it is performing a connection to a discovery controller, and
      it is initiated via auto-connect scripts.  With the FC transport, if the
      first connection attempt fails, the controller enters a normal reconnect
      state but returns control to the cli thread that created the controller.
      In this scenario, the cli attempts to read the discovery log via ioctl,
      which fails, causing the cli to see it as an empty log and then proceeds
      to delete the discovery controller. The delete is rejected and the
      controller is left live. If the discovery controller reconnect then
      succeeds, there is no action to delete it, and it sits live doing nothing.
      
      Cc: <stable@vger.kernel.org> # v5.7+
      Fixes: ce151813 ("nvme: Fix controller creation races with teardown flow")
      Signed-off-by: NJames Smart <james.smart@broadcom.com>
      CC: Israel Rukshin <israelr@mellanox.com>
      CC: Max Gurtovoy <maxg@mellanox.com>
      CC: Christoph Hellwig <hch@lst.de>
      CC: Keith Busch <kbusch@kernel.org>
      CC: Sagi Grimberg <sagi@grimberg.me>
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      b63de840
  6. 02 9月, 2020 2 次提交
  7. 29 8月, 2020 4 次提交
  8. 24 8月, 2020 1 次提交
  9. 22 8月, 2020 4 次提交
    • C
      nvme: redirect commands on dying queue · 5eac5f33
      Chao Leng 提交于
      If a command send through nvme-multipath failed on a dying queue, resend it
      on another path.
      Signed-off-by: NChao Leng <lengchao@huawei.com>
      [hch: rebased on top of the completion refactoring]
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NSagi Grimberg <sagi@grimberg.me>
      Reviewed-by: NMike Snitzer <snitzer@redhat.com>
      Signed-off-by: NSagi Grimberg <sagi@grimberg.me>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      5eac5f33
    • C
      nvme: refactor command completion · 5ddaabe8
      Christoph Hellwig 提交于
      Lift all the code to decide the dispostition of a completed command
      from nvme_complete_rq and nvme_failover_req into a new helper, which
      returns an emum of the potential actions.  nvme_complete_rq then
      just switches on those and calls the proper helper for the action.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NMike Snitzer <snitzer@redhat.com>
      Signed-off-by: NSagi Grimberg <sagi@grimberg.me>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      5ddaabe8
    • K
      nvme: skip noiob for zoned devices · c41ad98b
      Keith Busch 提交于
      Zoned block devices reuse the chunk_sectors queue limit to define zone
      boundaries. If a such a device happens to also report an optimal
      boundary, do not use that to define the chunk_sectors as that may
      intermittently interfere with io splitting and zone size queries.
      Signed-off-by: NKeith Busch <kbusch@kernel.org>
      Signed-off-by: NSagi Grimberg <sagi@grimberg.me>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      c41ad98b
    • L
      nvme: Use spin_lock_irq() when taking the ctrl->lock · ecbcdf0c
      Logan Gunthorpe 提交于
      When locking the ctrl->lock spinlock IRQs need to be disabled to avoid a
      dead lock. The new spin_lock() calls recently added produce the
      following lockdep warning when running the blktest nvme/003:
      
          ================================
          WARNING: inconsistent lock state
          --------------------------------
          inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
          ksoftirqd/2/22 [HC0[0]:SC1[1]:HE0:SE0] takes:
          ffff888276a8c4c0 (&ctrl->lock){+.?.}-{2:2}, at: nvme_keep_alive_end_io+0x50/0xc0
          {SOFTIRQ-ON-W} state was registered at:
            lock_acquire+0x164/0x500
            _raw_spin_lock+0x28/0x40
            nvme_get_effects_log+0x37/0x1c0
            nvme_init_identify+0x9e4/0x14f0
            nvme_reset_work+0xadd/0x2360
            process_one_work+0x66b/0xb70
            worker_thread+0x6e/0x6c0
            kthread+0x1e7/0x210
            ret_from_fork+0x22/0x30
          irq event stamp: 1449221
          hardirqs last  enabled at (1449220): [<ffffffff81c58e69>] ktime_get+0xf9/0x140
          hardirqs last disabled at (1449221): [<ffffffff83129665>] _raw_spin_lock_irqsave+0x25/0x60
          softirqs last  enabled at (1449210): [<ffffffff83400447>] __do_softirq+0x447/0x595
          softirqs last disabled at (1449215): [<ffffffff81b489b5>] run_ksoftirqd+0x35/0x50
      
          other info that might help us debug this:
           Possible unsafe locking scenario:
      
                 CPU0
                 ----
            lock(&ctrl->lock);
            <Interrupt>
              lock(&ctrl->lock);
      
           *** DEADLOCK ***
      
          no locks held by ksoftirqd/2/22.
      
          stack backtrace:
          CPU: 2 PID: 22 Comm: ksoftirqd/2 Not tainted 5.8.0-rc4-eid-vmlocalyes-dbg-00157-g7236657c #1450
          Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.12.0-1 04/01/2014
          Call Trace:
           dump_stack+0xc8/0x11a
           print_usage_bug.cold.63+0x235/0x23e
           mark_lock+0xa9c/0xcf0
           __lock_acquire+0xd9a/0x2b50
           lock_acquire+0x164/0x500
           _raw_spin_lock_irqsave+0x40/0x60
           nvme_keep_alive_end_io+0x50/0xc0
           blk_mq_end_request+0x158/0x210
           nvme_complete_rq+0x146/0x500
           nvme_loop_complete_rq+0x26/0x30 [nvme_loop]
           blk_done_softirq+0x187/0x1e0
           __do_softirq+0x118/0x595
           run_ksoftirqd+0x35/0x50
           smpboot_thread_fn+0x1d3/0x310
           kthread+0x1e7/0x210
           ret_from_fork+0x22/0x30
      
      Fixes: be93e87e ("nvme: support for multiple Command Sets Supported and Effects log pages")
      Signed-off-by: NLogan Gunthorpe <logang@deltatee.com>
      Reviewed-by: NKeith Busch <kbusch@kernel.org>
      Tested-by: NChaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
      Reviewed-by: NChaitanya Kulkarni <chaitanya.kulkarni@wdc.com>
      Signed-off-by: NSagi Grimberg <sagi@grimberg.me>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      ecbcdf0c
  10. 29 7月, 2020 3 次提交