1. 10 11月, 2020 1 次提交
  2. 03 11月, 2020 1 次提交
  3. 27 10月, 2020 1 次提交
  4. 14 10月, 2020 1 次提交
  5. 07 10月, 2020 22 次提交
  6. 27 9月, 2020 2 次提交
  7. 25 9月, 2020 2 次提交
  8. 24 9月, 2020 1 次提交
  9. 22 9月, 2020 1 次提交
  10. 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
  11. 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
  12. 02 9月, 2020 2 次提交
  13. 29 8月, 2020 4 次提交