1. 20 7月, 2021 19 次提交
  2. 14 7月, 2021 1 次提交
  3. 03 7月, 2021 3 次提交
    • A
      IB/mlx5: Fix initializing CQ fragments buffer · 8594ce6b
      Alaa Hleihel 提交于
      stable inclusion
      from stable-5.10.44
      commit 91f7fdc4cc10542ca1045c06aad23365f0d067e0
      bugzilla: 109295
      CVE: NA
      
      --------------------------------
      
      commit 2ba0aa2f upstream.
      
      The function init_cq_frag_buf() can be called to initialize the current CQ
      fragments buffer cq->buf, or the temporary cq->resize_buf that is filled
      during CQ resize operation.
      
      However, the offending commit started to use function get_cqe() for
      getting the CQEs, the issue with this change is that get_cqe() always
      returns CQEs from cq->buf, which leads us to initialize the wrong buffer,
      and in case of enlarging the CQ we try to access elements beyond the size
      of the current cq->buf and eventually hit a kernel panic.
      
       [exception RIP: init_cq_frag_buf+103]
        [ffff9f799ddcbcd8] mlx5_ib_resize_cq at ffffffffc0835d60 [mlx5_ib]
        [ffff9f799ddcbdb0] ib_resize_cq at ffffffffc05270df [ib_core]
        [ffff9f799ddcbdc0] llt_rdma_setup_qp at ffffffffc0a6a712 [llt]
        [ffff9f799ddcbe10] llt_rdma_cc_event_action at ffffffffc0a6b411 [llt]
        [ffff9f799ddcbe98] llt_rdma_client_conn_thread at ffffffffc0a6bb75 [llt]
        [ffff9f799ddcbec8] kthread at ffffffffa66c5da1
        [ffff9f799ddcbf50] ret_from_fork_nospec_begin at ffffffffa6d95ddd
      
      Fix it by getting the needed CQE by calling mlx5_frag_buf_get_wqe() that
      takes the correct source buffer as a parameter.
      
      Fixes: 388ca8be ("IB/mlx5: Implement fragmented completion queue (CQ)")
      Link: https://lore.kernel.org/r/90a0e8c924093cfa50a482880ad7e7edb73dc19a.1623309971.git.leonro@nvidia.comSigned-off-by: NAlaa Hleihel <alaa@nvidia.com>
      Signed-off-by: NLeon Romanovsky <leonro@nvidia.com>
      Signed-off-by: NJason Gunthorpe <jgg@nvidia.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NChen Jun <chenjun102@huawei.com>
      Acked-by: NWeilong Chen <chenweilong@huawei.com>
      Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      8594ce6b
    • S
      RDMA/mlx4: Do not map the core_clock page to user space unless enabled · e4f418ff
      Shay Drory 提交于
      stable inclusion
      from stable-5.10.44
      commit cb1aa1da04882d1860f733e24aeebdbbc85724d7
      bugzilla: 109295
      CVE: NA
      
      --------------------------------
      
      commit 404e5a12 upstream.
      
      Currently when mlx4 maps the hca_core_clock page to the user space there
      are read-modifiable registers, one of which is semaphore, on this page as
      well as the clock counter. If user reads the wrong offset, it can modify
      the semaphore and hang the device.
      
      Do not map the hca_core_clock page to the user space unless the device has
      been put in a backwards compatibility mode to support this feature.
      
      After this patch, mlx4 core_clock won't be mapped to user space on the
      majority of existing devices and the uverbs device time feature in
      ibv_query_rt_values_ex() will be disabled.
      
      Fixes: 52033cfb ("IB/mlx4: Add mmap call to map the hardware clock")
      Link: https://lore.kernel.org/r/9632304e0d6790af84b3b706d8c18732bc0d5e27.1622726305.git.leonro@nvidia.comSigned-off-by: NShay Drory <shayd@nvidia.com>
      Signed-off-by: NLeon Romanovsky <leonro@nvidia.com>
      Signed-off-by: NJason Gunthorpe <jgg@nvidia.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NChen Jun <chenjun102@huawei.com>
      Acked-by: NWeilong Chen <chenweilong@huawei.com>
      Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      e4f418ff
    • K
      RDMA/ipoib: Fix warning caused by destroying non-initial netns · b4ae54c6
      Kamal Heib 提交于
      stable inclusion
      from stable-5.10.44
      commit 67cf4e447b5e5e9e94996cb6812ae2828e0e0e27
      bugzilla: 109295
      CVE: NA
      
      --------------------------------
      
      commit a3e74fb9 upstream.
      
      After the commit 5ce2dced ("RDMA/ipoib: Set rtnl_link_ops for ipoib
      interfaces"), if the IPoIB device is moved to non-initial netns,
      destroying that netns lets the device vanish instead of moving it back to
      the initial netns, This is happening because default_device_exit() skips
      the interfaces due to having rtnl_link_ops set.
      
      Steps to reporoduce:
        ip netns add foo
        ip link set mlx5_ib0 netns foo
        ip netns delete foo
      
      WARNING: CPU: 1 PID: 704 at net/core/dev.c:11435 netdev_exit+0x3f/0x50
      Modules linked in: xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT
      nf_reject_ipv4 nft_compat nft_counter nft_chain_nat nf_nat nf_conntrack
      nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink tun d
       fuse
      CPU: 1 PID: 704 Comm: kworker/u64:3 Tainted: G S      W  5.13.0-rc1+ #1
      Hardware name: Dell Inc. PowerEdge R630/02C2CP, BIOS 2.1.5 04/11/2016
      Workqueue: netns cleanup_net
      RIP: 0010:netdev_exit+0x3f/0x50
      Code: 48 8b bb 30 01 00 00 e8 ef 81 b1 ff 48 81 fb c0 3a 54 a1 74 13 48
      8b 83 90 00 00 00 48 81 c3 90 00 00 00 48 39 d8 75 02 5b c3 <0f> 0b 5b
      c3 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 0f 1f 44 00
      RSP: 0018:ffffb297079d7e08 EFLAGS: 00010206
      RAX: ffff8eb542c00040 RBX: ffff8eb541333150 RCX: 000000008010000d
      RDX: 000000008010000e RSI: 000000008010000d RDI: ffff8eb440042c00
      RBP: ffffb297079d7e48 R08: 0000000000000001 R09: ffffffff9fdeac00
      R10: ffff8eb5003be000 R11: 0000000000000001 R12: ffffffffa1545620
      R13: ffffffffa1545628 R14: 0000000000000000 R15: ffffffffa1543b20
      FS:  0000000000000000(0000) GS:ffff8ed37fa00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00005601b5f4c2e8 CR3: 0000001fc8c10002 CR4: 00000000003706e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       ops_exit_list.isra.9+0x36/0x70
       cleanup_net+0x234/0x390
       process_one_work+0x1cb/0x360
       ? process_one_work+0x360/0x360
       worker_thread+0x30/0x370
       ? process_one_work+0x360/0x360
       kthread+0x116/0x130
       ? kthread_park+0x80/0x80
       ret_from_fork+0x22/0x30
      
      To avoid the above warning and later on the kernel panic that could happen
      on shutdown due to a NULL pointer dereference, make sure to set the
      netns_refund flag that was introduced by commit 3a5ca857 ("can: dev:
      Move device back to init netns on owning netns delete") to properly
      restore the IPoIB interfaces to the initial netns.
      
      Fixes: 5ce2dced ("RDMA/ipoib: Set rtnl_link_ops for ipoib interfaces")
      Link: https://lore.kernel.org/r/20210525150134.139342-1-kamalheib1@gmail.comSigned-off-by: NKamal Heib <kamalheib1@gmail.com>
      Reviewed-by: NLeon Romanovsky <leonro@nvidia.com>
      Signed-off-by: NJason Gunthorpe <jgg@nvidia.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NChen Jun <chenjun102@huawei.com>
      Acked-by: NWeilong Chen <chenweilong@huawei.com>
      Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      b4ae54c6
  4. 03 6月, 2021 17 次提交