1. 28 Aug, 2019 1 commit
  2. 23 Aug, 2019 1 commit
  3. 22 Aug, 2019 2 commits
    • Bernard Metzler's avatar
      RDMA/siw: Fix SGL mapping issues · fab4f97e
      Bernard Metzler authored
      All user level and most in-kernel applications submit WQEs
      where the SG list entries are all of a single type.
      iSER in particular, however, will send us WQEs with mixed SG
      types: sge[0] = kernel buffer, sge[1] = PBL region.
      Check and set is_kva on each SG entry individually instead of
      assuming the first SGE type carries through to the last.
      This fixes iSER over siw.
      
      Fixes: b9be6f18 ("rdma/siw: transmit path")
      Reported-by: default avatarKrishnamraju Eraparaju <krishna2@chelsio.com>
      Tested-by: default avatarKrishnamraju Eraparaju <krishna2@chelsio.com>
      Signed-off-by: default avatarBernard Metzler <bmt@zurich.ibm.com>
      Link: https://lore.kernel.org/r/20190822150741.21871-1-bmt@zurich.ibm.comSigned-off-by: default avatarDoug Ledford <dledford@redhat.com>
      fab4f97e
    • Selvin Xavier's avatar
      RDMA/bnxt_re: Fix stack-out-of-bounds in bnxt_qplib_rcfw_send_message · d37b1e53
      Selvin Xavier authored
      Driver copies FW commands to the HW queue as  units of 16 bytes. Some
      of the command structures are not exact multiple of 16. So while copying
      the data from those structures, the stack out of bounds messages are
      reported by KASAN. The following error is reported.
      
      [ 1337.530155] ==================================================================
      [ 1337.530277] BUG: KASAN: stack-out-of-bounds in bnxt_qplib_rcfw_send_message+0x40a/0x850 [bnxt_re]
      [ 1337.530413] Read of size 16 at addr ffff888725477a48 by task rmmod/2785
      
      [ 1337.530540] CPU: 5 PID: 2785 Comm: rmmod Tainted: G           OE     5.2.0-rc6+ #75
      [ 1337.530541] Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.0.4 08/28/2014
      [ 1337.530542] Call Trace:
      [ 1337.530548]  dump_stack+0x5b/0x90
      [ 1337.530556]  ? bnxt_qplib_rcfw_send_message+0x40a/0x850 [bnxt_re]
      [ 1337.530560]  print_address_description+0x65/0x22e
      [ 1337.530568]  ? bnxt_qplib_rcfw_send_message+0x40a/0x850 [bnxt_re]
      [ 1337.530575]  ? bnxt_qplib_rcfw_send_message+0x40a/0x850 [bnxt_re]
      [ 1337.530577]  __kasan_report.cold.3+0x37/0x77
      [ 1337.530581]  ? _raw_write_trylock+0x10/0xe0
      [ 1337.530588]  ? bnxt_qplib_rcfw_send_message+0x40a/0x850 [bnxt_re]
      [ 1337.530590]  kasan_report+0xe/0x20
      [ 1337.530592]  memcpy+0x1f/0x50
      [ 1337.530600]  bnxt_qplib_rcfw_send_message+0x40a/0x850 [bnxt_re]
      [ 1337.530608]  ? bnxt_qplib_creq_irq+0xa0/0xa0 [bnxt_re]
      [ 1337.530611]  ? xas_create+0x3aa/0x5f0
      [ 1337.530613]  ? xas_start+0x77/0x110
      [ 1337.530615]  ? xas_clear_mark+0x34/0xd0
      [ 1337.530623]  bnxt_qplib_free_mrw+0x104/0x1a0 [bnxt_re]
      [ 1337.530631]  ? bnxt_qplib_destroy_ah+0x110/0x110 [bnxt_re]
      [ 1337.530633]  ? bit_wait_io_timeout+0xc0/0xc0
      [ 1337.530641]  bnxt_re_dealloc_mw+0x2c/0x60 [bnxt_re]
      [ 1337.530648]  bnxt_re_destroy_fence_mr+0x77/0x1d0 [bnxt_re]
      [ 1337.530655]  bnxt_re_dealloc_pd+0x25/0x60 [bnxt_re]
      [ 1337.530677]  ib_dealloc_pd_user+0xbe/0xe0 [ib_core]
      [ 1337.530683]  srpt_remove_one+0x5de/0x690 [ib_srpt]
      [ 1337.530689]  ? __srpt_close_all_ch+0xc0/0xc0 [ib_srpt]
      [ 1337.530692]  ? xa_load+0x87/0xe0
      ...
      [ 1337.530840]  do_syscall_64+0x6d/0x1f0
      [ 1337.530843]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      [ 1337.530845] RIP: 0033:0x7ff5b389035b
      [ 1337.530848] Code: 73 01 c3 48 8b 0d 2d 0b 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d fd 0a 2c 00 f7 d8 64 89 01 48
      [ 1337.530849] RSP: 002b:00007fff83425c28 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
      [ 1337.530852] RAX: ffffffffffffffda RBX: 00005596443e6750 RCX: 00007ff5b389035b
      [ 1337.530853] RDX: 000000000000000a RSI: 0000000000000800 RDI: 00005596443e67b8
      [ 1337.530854] RBP: 0000000000000000 R08: 00007fff83424ba1 R09: 0000000000000000
      [ 1337.530856] R10: 00007ff5b3902960 R11: 0000000000000206 R12: 00007fff83425e50
      [ 1337.530857] R13: 00007fff8342673c R14: 00005596443e6260 R15: 00005596443e6750
      
      [ 1337.530885] The buggy address belongs to the page:
      [ 1337.530962] page:ffffea001c951dc0 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0
      [ 1337.530964] flags: 0x57ffffc0000000()
      [ 1337.530967] raw: 0057ffffc0000000 0000000000000000 ffffffff1c950101 0000000000000000
      [ 1337.530970] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
      [ 1337.530970] page dumped because: kasan: bad access detected
      
      [ 1337.530996] Memory state around the buggy address:
      [ 1337.531072]  ffff888725477900: 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 f2 f2 f2
      [ 1337.531180]  ffff888725477980: 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00
      [ 1337.531288] >ffff888725477a00: 00 f2 f2 f2 f2 f2 f2 00 00 00 f2 00 00 00 00 00
      [ 1337.531393]                                                  ^
      [ 1337.531478]  ffff888725477a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [ 1337.531585]  ffff888725477b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      [ 1337.531691] ==================================================================
      
      Fix this by passing the exact size of each FW command to
      bnxt_qplib_rcfw_send_message as req->cmd_size. Before sending
      the command to HW, modify the req->cmd_size to number of 16 byte units.
      
      Fixes: 1ac5a404 ("RDMA/bnxt_re: Add bnxt_re RoCE driver")
      Signed-off-by: default avatarSelvin Xavier <selvin.xavier@broadcom.com>
      Link: https://lore.kernel.org/r/1566468170-489-1-git-send-email-selvin.xavier@broadcom.comSigned-off-by: default avatarDoug Ledford <dledford@redhat.com>
      d37b1e53
  4. 20 Aug, 2019 18 commits
  5. 13 Aug, 2019 1 commit
  6. 12 Aug, 2019 3 commits
    • Dan Carpenter's avatar
      RDMA/core: Fix error code in stat_get_doit_qp() · 932727c5
      Dan Carpenter authored
      We need to set the error codes on these paths.  Currently the only
      possible error code is -EMSGSIZE so that's what the patch uses.
      
      Fixes: 83c2c1fc ("RDMA/nldev: Allow get counter mode through RDMA netlink")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Reviewed-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Link: https://lore.kernel.org/r/20190809101311.GA17867@mwandaSigned-off-by: default avatarDoug Ledford <dledford@redhat.com>
      932727c5
    • Dan Carpenter's avatar
      RDMA/siw: Fix a memory leak in siw_init_cpulist() · 17c19287
      Dan Carpenter authored
      The error handling code doesn't free siw_cpu_info.tx_valid_cpus[0].  The
      first iteration through the loop is a no-op so this is sort of an off
      by one bug.  Also Bernard pointed out that we can remove the NULL
      assignment and simplify the code a bit.
      
      Fixes: bdcf26bf ("rdma/siw: network and RDMA core interface")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Reviewed-by: default avatarBernard Metzler <bmt@zurich.ibm.com>
      Reviewed-by: default avatarBernard Metzler <bmt@zurich.ibm.com>
      Link: https://lore.kernel.org/r/20190809140904.GB3552@mwandaSigned-off-by: default avatarDoug Ledford <dledford@redhat.com>
      17c19287
    • Yishai Hadas's avatar
      IB/mlx5: Fix use-after-free error while accessing ev_file pointer · e9eec6a5
      Yishai Hadas authored
      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: default avatarYishai Hadas <yishaih@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Reviewed-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      Link: https://lore.kernel.org/r/20190808081538.28772-1-leon@kernel.orgSigned-off-by: default avatarDoug Ledford <dledford@redhat.com>
      e9eec6a5
  7. 07 Aug, 2019 3 commits
  8. 01 Aug, 2019 9 commits
    • Wei Yongjun's avatar
      RDMA/hns: Fix error return code in hns_roce_v1_rsv_lp_qp() · 020fb3be
      Wei Yongjun authored
      Fix to return error code -ENOMEM from the rdma_zalloc_drv_obj() error
      handling case instead of 0, as done elsewhere in this function.
      
      Fixes: e8ac9389 ("RDMA: Fix allocation failure on pointer pd")
      Fixes: 21a428a0 ("RDMA: Handle PD allocations by IB/core")
      Signed-off-by: default avatarWei Yongjun <weiyongjun1@huawei.com>
      Reviewed-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Link: https://lore.kernel.org/r/20190801012725.150493-1-weiyongjun1@huawei.comSigned-off-by: default avatarDoug Ledford <dledford@redhat.com>
      020fb3be
    • Leon Romanovsky's avatar
      RDMA/mlx5: Release locks during notifier unregister · 23eaf3b5
      Leon Romanovsky authored
      The below kernel panic was observed when created bond mode LACP
      with GRE tunnel on top. The reason to it was not released spinlock
      during mlx5 notify unregsiter sequence.
      
      [  234.562007] BUG: scheduling while atomic: sh/10900/0x00000002
      [  234.563005] Preemption disabled at:
      [  234.566864] ------------[ cut here ]------------
      [  234.567120] DEBUG_LOCKS_WARN_ON(val > preempt_count())
      [  234.567139] WARNING: CPU: 16 PID: 10900 at kernel/sched/core.c:3203 preempt_count_sub+0xca/0x170
      [  234.569550] CPU: 16 PID: 10900 Comm: sh Tainted: G        W 5.2.0-rc1-for-linust-dbg-2019-05-25_04-57-33-60 #1
      [  234.569886] Hardware name: Dell Inc. PowerEdge R720/0X3D66, BIOS 2.6.1 02/12/2018
      [  234.570183] RIP: 0010:preempt_count_sub+0xca/0x170
      [  234.570404] Code: 03 38
      d0 7c 08 84 d2 0f 85 b0 00 00 00 8b 15 dd 02 03 04 85 d2 75 ba 48 c7 c6
      00 e1 88 83 48 c7 c7 40 e1 88 83 e8 76 11 f7 ff <0f> 0b 5b c3 65 8b 05
      d3 1f d8 7e 84 c0 75 82 e8 62 c3 c3 00 85 c0
      [  234.570911] RSP: 0018:ffff888b94477b08 EFLAGS: 00010286
      [  234.571133] RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000
      [  234.571391] RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000246
      [  234.571648] RBP: ffff888ba5560000 R08: fffffbfff08962d5 R09: fffffbfff08962d5
      [  234.571902] R10: 0000000000000001 R11: fffffbfff08962d4 R12: ffff888bac6e9548
      [  234.572157] R13: ffff888babfaf728 R14: ffff888bac6e9568 R15: ffff888babfaf750
      [  234.572412] FS: 00007fcafa59b740(0000) GS:ffff888bed200000(0000) knlGS:0000000000000000
      [  234.572686] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  234.572914] CR2: 00007f984f16b140 CR3: 0000000b2bf0a001 CR4: 00000000001606e0
      [  234.573172] Call Trace:
      [  234.573336] _raw_spin_unlock+0x2e/0x50
      [  234.573542] mlx5_ib_unbind_slave_port+0x1bc/0x690 [mlx5_ib]
      [  234.573793] mlx5_ib_cleanup_multiport_master+0x1d3/0x660 [mlx5_ib]
      [  234.574039] mlx5_ib_stage_init_cleanup+0x4c/0x360 [mlx5_ib]
      [  234.574271]  ? kfree+0xf5/0x2f0
      [  234.574465] __mlx5_ib_remove+0x61/0xd0 [mlx5_ib]
      [  234.574688]  ? __mlx5_ib_remove+0xd0/0xd0 [mlx5_ib]
      [  234.574951] mlx5_remove_device+0x234/0x300 [mlx5_core]
      [  234.575224] mlx5_unregister_device+0x4d/0x1e0 [mlx5_core]
      [  234.575493] remove_one+0x4f/0x160 [mlx5_core]
      [  234.575704] pci_device_remove+0xef/0x2a0
      [  234.581407]  ? pcibios_free_irq+0x10/0x10
      [  234.587143]  ? up_read+0xc1/0x260
      [  234.592785] device_release_driver_internal+0x1ab/0x430
      [  234.598442] unbind_store+0x152/0x200
      [  234.604064]  ? sysfs_kf_write+0x3b/0x180
      [  234.609441]  ? sysfs_file_ops+0x160/0x160
      [  234.615021] kernfs_fop_write+0x277/0x440
      [  234.620288]  ? __sb_start_write+0x1ef/0x2c0
      [  234.625512] vfs_write+0x15e/0x460
      [  234.630786] ksys_write+0x156/0x1e0
      [  234.635988]  ? __ia32_sys_read+0xb0/0xb0
      [  234.641120]  ? trace_hardirqs_off_thunk+0x1a/0x1c
      [  234.646163] do_syscall_64+0x95/0x470
      [  234.651106] entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [  234.656004] RIP: 0033:0x7fcaf9c9cfd0
      [  234.660686] Code: 73 01
      c3 48 8b 0d c0 6e 2d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00
      83 3d cd cf 2d 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73
      31 c3 48 83 ec 08 e8 ee cb 01 00 48 89 04 24
      [  234.670128] RSP: 002b:00007ffd3b01ddd8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
      [  234.674811] RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fcaf9c9cfd0
      [  234.679387] RDX: 000000000000000d RSI: 00007fcafa5c1000 RDI: 0000000000000001
      [  234.683848] RBP: 00007fcafa5c1000 R08: 000000000000000a R09: 00007fcafa59b740
      [  234.688167] R10: 00007ffd3b01d8e0 R11: 0000000000000246 R12: 00007fcaf9f75400
      [  234.692386] R13: 000000000000000d R14: 0000000000000001 R15: 0000000000000000
      [  234.696495] irq event stamp: 153067
      [  234.700525] hardirqs last enabled at (153067): [<ffffffff83258c39>] _raw_spin_unlock_irqrestore+0x59/0x70
      [  234.704665] hardirqs last disabled at (153066): [<ffffffff83259382>] _raw_spin_lock_irqsave+0x22/0x90
      [  234.708722] softirqs last enabled at (153058): [<ffffffff836006c5>] __do_softirq+0x6c5/0xb4e
      [  234.712673] softirqs last disabled at (153051): [<ffffffff81227c1d>] irq_exit+0x17d/0x1d0
      [  234.716601] ---[ end trace 5dbf096843ee9ce6 ]---
      
      Fixes: df097a27 ("IB/mlx5: Use the new mlx5 core notifier API")
      Signed-off-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Link: https://lore.kernel.org/r/20190731083852.584-1-leon@kernel.orgSigned-off-by: default avatarDoug Ledford <dledford@redhat.com>
      23eaf3b5
    • Gustavo A. R. Silva's avatar
      IB/hfi1: Fix Spectre v1 vulnerability · 6497d0a9
      Gustavo A. R. Silva authored
      sl is controlled by user-space, hence leading to a potential
      exploitation of the Spectre variant 1 vulnerability.
      
      Fix this by sanitizing sl before using it to index ibp->sl_to_sc.
      
      Notice that given that speculation windows are large, the policy is
      to kill the speculation on the first load and not worry if it can be
      completed with a dependent load/store [1].
      
      [1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGustavo A. R. Silva <gustavo@embeddedor.com>
      Link: https://lore.kernel.org/r/20190731175428.GA16736@embeddedorSigned-off-by: default avatarDoug Ledford <dledford@redhat.com>
      6497d0a9
    • Jack Morgenstein's avatar
      IB/mad: Fix use-after-free in ib mad completion handling · 770b7d96
      Jack Morgenstein authored
      We encountered a use-after-free bug when unloading the driver:
      
      [ 3562.116059] BUG: KASAN: use-after-free in ib_mad_post_receive_mads+0xddc/0xed0 [ib_core]
      [ 3562.117233] Read of size 4 at addr ffff8882ca5aa868 by task kworker/u13:2/23862
      [ 3562.118385]
      [ 3562.119519] CPU: 2 PID: 23862 Comm: kworker/u13:2 Tainted: G           OE     5.1.0-for-upstream-dbg-2019-05-19_16-44-30-13 #1
      [ 3562.121806] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu2 04/01/2014
      [ 3562.123075] Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core]
      [ 3562.124383] Call Trace:
      [ 3562.125640]  dump_stack+0x9a/0xeb
      [ 3562.126911]  print_address_description+0xe3/0x2e0
      [ 3562.128223]  ? ib_mad_post_receive_mads+0xddc/0xed0 [ib_core]
      [ 3562.129545]  __kasan_report+0x15c/0x1df
      [ 3562.130866]  ? ib_mad_post_receive_mads+0xddc/0xed0 [ib_core]
      [ 3562.132174]  kasan_report+0xe/0x20
      [ 3562.133514]  ib_mad_post_receive_mads+0xddc/0xed0 [ib_core]
      [ 3562.134835]  ? find_mad_agent+0xa00/0xa00 [ib_core]
      [ 3562.136158]  ? qlist_free_all+0x51/0xb0
      [ 3562.137498]  ? mlx4_ib_sqp_comp_worker+0x1970/0x1970 [mlx4_ib]
      [ 3562.138833]  ? quarantine_reduce+0x1fa/0x270
      [ 3562.140171]  ? kasan_unpoison_shadow+0x30/0x40
      [ 3562.141522]  ib_mad_recv_done+0xdf6/0x3000 [ib_core]
      [ 3562.142880]  ? _raw_spin_unlock_irqrestore+0x46/0x70
      [ 3562.144277]  ? ib_mad_send_done+0x1810/0x1810 [ib_core]
      [ 3562.145649]  ? mlx4_ib_destroy_cq+0x2a0/0x2a0 [mlx4_ib]
      [ 3562.147008]  ? _raw_spin_unlock_irqrestore+0x46/0x70
      [ 3562.148380]  ? debug_object_deactivate+0x2b9/0x4a0
      [ 3562.149814]  __ib_process_cq+0xe2/0x1d0 [ib_core]
      [ 3562.151195]  ib_cq_poll_work+0x45/0xf0 [ib_core]
      [ 3562.152577]  process_one_work+0x90c/0x1860
      [ 3562.153959]  ? pwq_dec_nr_in_flight+0x320/0x320
      [ 3562.155320]  worker_thread+0x87/0xbb0
      [ 3562.156687]  ? __kthread_parkme+0xb6/0x180
      [ 3562.158058]  ? process_one_work+0x1860/0x1860
      [ 3562.159429]  kthread+0x320/0x3e0
      [ 3562.161391]  ? kthread_park+0x120/0x120
      [ 3562.162744]  ret_from_fork+0x24/0x30
      ...
      [ 3562.187615] Freed by task 31682:
      [ 3562.188602]  save_stack+0x19/0x80
      [ 3562.189586]  __kasan_slab_free+0x11d/0x160
      [ 3562.190571]  kfree+0xf5/0x2f0
      [ 3562.191552]  ib_mad_port_close+0x200/0x380 [ib_core]
      [ 3562.192538]  ib_mad_remove_device+0xf0/0x230 [ib_core]
      [ 3562.193538]  remove_client_context+0xa6/0xe0 [ib_core]
      [ 3562.194514]  disable_device+0x14e/0x260 [ib_core]
      [ 3562.195488]  __ib_unregister_device+0x79/0x150 [ib_core]
      [ 3562.196462]  ib_unregister_device+0x21/0x30 [ib_core]
      [ 3562.197439]  mlx4_ib_remove+0x162/0x690 [mlx4_ib]
      [ 3562.198408]  mlx4_remove_device+0x204/0x2c0 [mlx4_core]
      [ 3562.199381]  mlx4_unregister_interface+0x49/0x1d0 [mlx4_core]
      [ 3562.200356]  mlx4_ib_cleanup+0xc/0x1d [mlx4_ib]
      [ 3562.201329]  __x64_sys_delete_module+0x2d2/0x400
      [ 3562.202288]  do_syscall_64+0x95/0x470
      [ 3562.203277]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      The problem was that the MAD PD was deallocated before the MAD CQ.
      There was completion work pending for the CQ when the PD got deallocated.
      When the mad completion handling reached procedure
      ib_mad_post_receive_mads(), we got a use-after-free bug in the following
      line of code in that procedure:
         sg_list.lkey = qp_info->port_priv->pd->local_dma_lkey;
      (the pd pointer in the above line is no longer valid, because the
      pd has been deallocated).
      
      We fix this by allocating the PD before the CQ in procedure
      ib_mad_port_open(), and deallocating the PD after freeing the CQ
      in procedure ib_mad_port_close().
      
      Since the CQ completion work queue is flushed during ib_free_cq(),
      no completions will be pending for that CQ when the PD is later
      deallocated.
      
      Note that freeing the CQ before deallocating the PD is the practice
      in the ULPs.
      
      Fixes: 4be90bc6 ("IB/mad: Remove ib_get_dma_mr calls")
      Signed-off-by: default avatarJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Link: https://lore.kernel.org/r/20190801121449.24973-1-leon@kernel.orgSigned-off-by: default avatarDoug Ledford <dledford@redhat.com>
      770b7d96
    • Gal Pressman's avatar
      RDMA/restrack: Track driver QP types in resource tracker · 52e0a118
      Gal Pressman authored
      The check for QP type different than XRC has excluded driver QP
      types from the resource tracker.
      As a result, "rdma resource show" user command would not show opened
      driver QPs which does not reflect the real state of the system.
      
      Check QP type explicitly instead of assuming enum values/ordering.
      
      Fixes: 40909f66 ("RDMA/efa: Add EFA verbs implementation")
      Signed-off-by: default avatarGal Pressman <galpress@amazon.com>
      Reviewed-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Link: https://lore.kernel.org/r/20190801104354.11417-1-galpress@amazon.comSigned-off-by: default avatarDoug Ledford <dledford@redhat.com>
      52e0a118
    • Guy Levi's avatar
      IB/mlx5: Fix MR registration flow to use UMR properly · e5366d30
      Guy Levi authored
      Driver shouldn't allow to use UMR to register a MR when
      umr_modify_atomic_disabled is set. Otherwise it will always end up with a
      failure in the post send flow which sets the UMR WQE to modify atomic access
      right.
      
      Fixes: c8d75a98 ("IB/mlx5: Respect new UMR capabilities")
      Signed-off-by: default avatarGuy Levi <guyle@mellanox.com>
      Reviewed-by: default avatarMoni Shoua <monis@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Link: https://lore.kernel.org/r/20190731081929.32559-1-leon@kernel.orgSigned-off-by: default avatarDoug Ledford <dledford@redhat.com>
      e5366d30
    • Jason Gunthorpe's avatar
      RDMA/devices: Remove the lock around remove_client_context · 9cd58817
      Jason Gunthorpe authored
      Due to the complexity of client->remove() callbacks it is desirable to not
      hold any locks while calling them. Remove the last one by tracking only
      the highest client ID and running backwards from there over the xarray.
      
      Since the only purpose of that lock was to protect the linked list, we can
      drop the lock.
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Link: https://lore.kernel.org/r/20190731081841.32345-3-leon@kernel.orgSigned-off-by: default avatarDoug Ledford <dledford@redhat.com>
      9cd58817
    • Jason Gunthorpe's avatar
      RDMA/devices: Do not deadlock during client removal · 621e55ff
      Jason Gunthorpe authored
      lockdep reports:
      
         WARNING: possible circular locking dependency detected
      
         modprobe/302 is trying to acquire lock:
         0000000007c8919c ((wq_completion)ib_cm){+.+.}, at: flush_workqueue+0xdf/0x990
      
         but task is already holding lock:
         000000002d3d2ca9 (&device->client_data_rwsem){++++}, at: remove_client_context+0x79/0xd0 [ib_core]
      
         which lock already depends on the new lock.
      
         the existing dependency chain (in reverse order) is:
      
         -> #2 (&device->client_data_rwsem){++++}:
                down_read+0x3f/0x160
                ib_get_net_dev_by_params+0xd5/0x200 [ib_core]
                cma_ib_req_handler+0x5f6/0x2090 [rdma_cm]
                cm_process_work+0x29/0x110 [ib_cm]
                cm_req_handler+0x10f5/0x1c00 [ib_cm]
                cm_work_handler+0x54c/0x311d [ib_cm]
                process_one_work+0x4aa/0xa30
                worker_thread+0x62/0x5b0
                kthread+0x1ca/0x1f0
                ret_from_fork+0x24/0x30
      
         -> #1 ((work_completion)(&(&work->work)->work)){+.+.}:
                process_one_work+0x45f/0xa30
                worker_thread+0x62/0x5b0
                kthread+0x1ca/0x1f0
                ret_from_fork+0x24/0x30
      
         -> #0 ((wq_completion)ib_cm){+.+.}:
                lock_acquire+0xc8/0x1d0
                flush_workqueue+0x102/0x990
                cm_remove_one+0x30e/0x3c0 [ib_cm]
                remove_client_context+0x94/0xd0 [ib_core]
                disable_device+0x10a/0x1f0 [ib_core]
                __ib_unregister_device+0x5a/0xe0 [ib_core]
                ib_unregister_device+0x21/0x30 [ib_core]
                mlx5_ib_stage_ib_reg_cleanup+0x9/0x10 [mlx5_ib]
                __mlx5_ib_remove+0x3d/0x70 [mlx5_ib]
                mlx5_ib_remove+0x12e/0x140 [mlx5_ib]
                mlx5_remove_device+0x144/0x150 [mlx5_core]
                mlx5_unregister_interface+0x3f/0xf0 [mlx5_core]
                mlx5_ib_cleanup+0x10/0x3a [mlx5_ib]
                __x64_sys_delete_module+0x227/0x350
                do_syscall_64+0xc3/0x6a4
                entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Which is due to the read side of the client_data_rwsem being obtained
      recursively through a work queue flush during cm client removal.
      
      The lock is being held across the remove in remove_client_context() so
      that the function is a fence, once it returns the client is removed. This
      is required so that the two callers do not proceed with destruction until
      the client completes removal.
      
      Instead of using client_data_rwsem use the existing device unregistration
      refcount and add a similar client unregistration (client->uses) refcount.
      
      This will fence the two unregistration paths without holding any locks.
      
      Cc: <stable@vger.kernel.org>
      Fixes: 921eab11 ("RDMA/devices: Re-organize device.c locking")
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Link: https://lore.kernel.org/r/20190731081841.32345-2-leon@kernel.orgSigned-off-by: default avatarDoug Ledford <dledford@redhat.com>
      621e55ff
    • Luck, Tony's avatar
      IB/core: Add mitigation for Spectre V1 · 61f25982
      Luck, Tony authored
      Some processors may mispredict an array bounds check and
      speculatively access memory that they should not. With
      a user supplied array index we like to play things safe
      by masking the value with the array size before it is
      used as an index.
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      Link: https://lore.kernel.org/r/20190731043957.GA1600@agluck-desk2.amr.corp.intel.comSigned-off-by: default avatarDoug Ledford <dledford@redhat.com>
      61f25982
  9. 29 Jul, 2019 2 commits