1. 19 1月, 2021 2 次提交
  2. 08 12月, 2020 1 次提交
  3. 27 11月, 2020 1 次提交
  4. 17 11月, 2020 1 次提交
  5. 13 11月, 2020 2 次提交
  6. 03 11月, 2020 4 次提交
  7. 17 7月, 2020 1 次提交
  8. 08 7月, 2020 2 次提交
  9. 28 5月, 2020 1 次提交
  10. 22 5月, 2020 1 次提交
  11. 20 5月, 2020 1 次提交
  12. 29 4月, 2020 1 次提交
  13. 19 4月, 2020 1 次提交
  14. 13 2月, 2020 1 次提交
  15. 16 1月, 2020 1 次提交
  16. 14 1月, 2020 3 次提交
  17. 17 11月, 2019 1 次提交
  18. 14 11月, 2019 1 次提交
  19. 29 10月, 2019 1 次提交
    • J
      RDMA/mlx5: Use a dedicated mkey xarray for ODP · 806b101b
      Jason Gunthorpe 提交于
      There is a per device xarray storing mkeys that is used to store every
      mkey in the system. However, this xarray is now only read by ODP for
      certain ODP designated MRs (ODP, implicit ODP, MW, DEVX_INDIRECT).
      
      Create an xarray only for use by ODP, that only contains ODP related
      MKeys. This xarray is protected by SRCU and all erases are protected by a
      synchronize.
      
      This improves performance:
      
       - All MRs in the odp_mkeys xarray are ODP MRs, so some tests for is_odp()
         can be deleted. The xarray will also consume fewer nodes.
      
       - normal MR's are never mixed with ODP MRs in a SRCU data structure so
         performance sucking synchronize_srcu() on every MR destruction is not
         needed.
      
       - No smp_load_acquire(live) and xa_load() double barrier on read
      
      Due to the SRCU locking scheme care must be taken with the placement of
      the xa_store(). Once it completes the MR is immediately visible to other
      threads and only through a xa_erase() & synchronize_srcu() cycle could it
      be destroyed.
      
      Link: https://lore.kernel.org/r/20191009160934.3143-4-jgg@ziepe.caReviewed-by: NArtemy Kovalyov <artemyko@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      806b101b
  20. 05 10月, 2019 1 次提交
  21. 14 8月, 2019 2 次提交
  22. 12 8月, 2019 1 次提交
    • Y
      IB/mlx5: Fix use-after-free error while accessing ev_file pointer · e9eec6a5
      Yishai Hadas 提交于
      Call to uverbs_close_fd() releases file pointer to 'ev_file' and
      mlx5_ib_dev is going to be inaccessible. Cache pointer prior cleaning
      resources to solve the KASAN warning below.
      
      BUG: KASAN: use-after-free in devx_async_event_close+0x391/0x480 [mlx5_ib]
      Read of size 8 at addr ffff888301e3cec0 by task devx_direct_tes/4631
      CPU: 1 PID: 4631 Comm: devx_direct_tes Tainted: G OE 5.3.0-rc1-for-upstream-dbg-2019-07-26_01-19-56-93 #1
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu2 04/01/2014
      Call Trace:
      dump_stack+0x9a/0xeb
      print_address_description+0x1e2/0x400
      ? devx_async_event_close+0x391/0x480 [mlx5_ib]
      __kasan_report+0x15c/0x1df
      ? devx_async_event_close+0x391/0x480 [mlx5_ib]
      kasan_report+0xe/0x20
      devx_async_event_close+0x391/0x480 [mlx5_ib]
      __fput+0x26a/0x7b0
      task_work_run+0x10d/0x180
      exit_to_usermode_loop+0x137/0x160
      do_syscall_64+0x3c7/0x490
      entry_SYSCALL_64_after_hwframe+0x49/0xbe
      RIP: 0033:0x7f5df907d664
      Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f
      80 00 00 00 00 8b 05 6a cd 20 00 48 63 ff 85 c0 75 13 b8
      03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 44 f3 c3 66 90
      48 83 ec 18 48 89 7c 24 08 e8
      RSP: 002b:00007ffd353cb958 EFLAGS: 00000246 ORIG_RAX: 0000000000000003
      RAX: 0000000000000000 RBX: 000056017a88c348 RCX: 00007f5df907d664
      RDX: 00007f5df969d400 RSI: 00007f5de8f1ec90 RDI: 0000000000000006
      RBP: 00007f5df9681dc0 R08: 00007f5de8736410 R09: 000056017a9d2dd0
      R10: 000000000000000b R11: 0000000000000246 R12: 00007f5de899d7d0
      R13: 00007f5df96c4248 R14: 00007f5de8f1ecb0 R15: 000056017ae41308
      
      Allocated by task 4631:
      save_stack+0x19/0x80
      kasan_kmalloc.constprop.3+0xa0/0xd0
      alloc_uobj+0x71/0x230 [ib_uverbs]
      alloc_begin_fd_uobject+0x2e/0xc0 [ib_uverbs]
      rdma_alloc_begin_uobject+0x96/0x140 [ib_uverbs]
      ib_uverbs_run_method+0xdf0/0x1940 [ib_uverbs]
      ib_uverbs_cmd_verbs+0x57e/0xdb0 [ib_uverbs]
      ib_uverbs_ioctl+0x177/0x260 [ib_uverbs]
      do_vfs_ioctl+0x18f/0x1010
      ksys_ioctl+0x70/0x80
      __x64_sys_ioctl+0x6f/0xb0
      do_syscall_64+0x95/0x490
      entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Freed by task 4631:
      save_stack+0x19/0x80
      __kasan_slab_free+0x11d/0x160
      slab_free_freelist_hook+0x67/0x1a0
      kfree+0xb9/0x2a0
      uverbs_close_fd+0x118/0x1c0 [ib_uverbs]
      devx_async_event_close+0x28a/0x480 [mlx5_ib]
      __fput+0x26a/0x7b0
      task_work_run+0x10d/0x180
      exit_to_usermode_loop+0x137/0x160
      do_syscall_64+0x3c7/0x490
      entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      The buggy address belongs to the object at ffff888301e3cda8
      which belongs to the cache kmalloc-512 of size 512
      The buggy address is located 280 bytes inside of 512-byte region
      [ffff888301e3cda8, ffff888301e3cfa8)
      The buggy address belongs to the page:
      page:ffffea000c078e00 refcount:1 mapcount:0
      mapping:ffff888352811300 index:0x0 compound_mapcount: 0
      flags: 0x2fffff80010200(slab|head)
      raw: 002fffff80010200 ffffea000d152608 ffffea000c077808 ffff888352811300
      raw: 0000000000000000 0000000000250025 00000001ffffffff 0000000000000000
      page dumped because: kasan: bad access detected
      Memory state around the buggy address:
      ffff888301e3cd80: fc fc fc fc fc fb fb fb fb fb fb fb fb fb fb fb
      ffff888301e3ce00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      ffff888301e3ce80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      ffff888301e3cf00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      ffff888301e3cf80: fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc
      Disabling lock debugging due to kernel taint
      
      Cc: <stable@vger.kernel.org> # 5.2
      Fixes: 75973853 ("IB/mlx5: Enable subscription for device events over DEVX")
      Signed-off-by: NYishai Hadas <yishaih@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Reviewed-by: NJason Gunthorpe <jgg@mellanox.com>
      Link: https://lore.kernel.org/r/20190808081538.28772-1-leon@kernel.orgSigned-off-by: NDoug Ledford <dledford@redhat.com>
      e9eec6a5
  23. 08 8月, 2019 1 次提交
  24. 04 8月, 2019 1 次提交
  25. 26 7月, 2019 1 次提交
  26. 09 7月, 2019 1 次提交
    • M
      IB/mlx5: Implement VHCA tunnel mechanism in DEVX · b6142608
      Max Gurtovoy 提交于
      This mechanism will allow function-A to perform operations "on behalf" of
      function-B via tunnel object. Function-A will have privileges for creating
      and using this tunnel object.
      
      For example, in the device emulation feature presented in Bluefield-1 SoC,
      using device emulation capability, one can present NVMe function to the
      host OS.
      
      Since the NVMe function doesn't have a normal command interface to the HCA
      HW, here is a need to create a channel that will be able to issue commands
      "on behalf" of this function.
      
      This channel is the VHCA_TUNNEL general object. The emulation software
      will create this tunnel for every managed function and issue commands via
      devx general cmd interface using the appropriate tunnel ID. When devX
      context will receive a command with non-zero vhca_tunnel_id, it will pass
      the command as-is down to the HCA.
      
      All the validation, security and resource tracking of the commands and the
      created tunneled objects is in the responsibility of the HCA FW. When a
      VHCA_TUNNEL object destroyed, the device will issue an internal
      FLR (function level reset) to the emulated function associated with this
      tunnel. This will destroy all the created resources using the tunnel
      mechanism.
      Signed-off-by: NMax Gurtovoy <maxg@mellanox.com>
      Reviewed-by: NYishai Hadas <yishaih@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      b6142608
  27. 04 7月, 2019 5 次提交