1. 15 12月, 2018 2 次提交
  2. 11 12月, 2018 1 次提交
  3. 10 12月, 2018 1 次提交
  4. 04 12月, 2018 8 次提交
  5. 30 11月, 2018 4 次提交
  6. 27 11月, 2018 2 次提交
  7. 26 11月, 2018 1 次提交
    • E
      net: remove unsafe skb_insert() · 4bffc669
      Eric Dumazet 提交于
      I do not see how one can effectively use skb_insert() without holding
      some kind of lock. Otherwise other cpus could have changed the list
      right before we have a chance of acquiring list->lock.
      
      Only existing user is in drivers/infiniband/hw/nes/nes_mgt.c and this
      one probably meant to use __skb_insert() since it appears nesqp->pau_list
      is protected by nesqp->pau_lock. This looks like nesqp->pau_lock
      could be removed, since nesqp->pau_list.lock could be used instead.
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Faisal Latif <faisal.latif@intel.com>
      Cc: Doug Ledford <dledford@redhat.com>
      Cc: Jason Gunthorpe <jgg@ziepe.ca>
      Cc: linux-rdma <linux-rdma@vger.kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4bffc669
  8. 24 11月, 2018 2 次提交
  9. 23 11月, 2018 1 次提交
  10. 22 11月, 2018 5 次提交
    • M
      IB/mlx5: Avoid load failure due to unknown link width · db7a691a
      Michael Guralnik 提交于
      If the firmware reports a connection width that is not 1x, 4x, 8x or 12x
      it causes the driver to fail during initialization.
      
      To prevent this failure every time a new width is introduced to the RDMA
      stack, we will set a default 4x width for these widths which ar unknown to
      the driver.
      
      This is needed to allow to run old kernels with new firmware.
      
      Cc: <stable@vger.kernel.org> # 4.1
      Fixes: 1b5daf11 ("IB/mlx5: Avoid using the MAD_IFC command under ISSI > 0 mode")
      Signed-off-by: NMichael Guralnik <michaelgur@mellanox.com>
      Reviewed-by: NMajd Dibbiny <majd@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      db7a691a
    • Y
      IB/mlx5: Fix XRC QP support after introducing extended atomic · 13f8d9c1
      Yonatan Cohen 提交于
      Extended atomics are supported with RC and XRC QP types, but the commit
      citied in the Fixes line added an unneeded check to
      to_mlx5_access_flags. This broke XRC QPs.
      
      The following ib_atomic_bw invocation over XRC reproduces the issue:
         ib_atomic_bw -d mlx5_1 --connection=XRC --atomic_type=FETCH_AND_ADD
      
      It is safe to remove such checks because the QP type was already checked
      in ib_modify_qp_is_ok(), which was previously called from
      mlx5_ib_modify_qp.
      
      Fixes: a60109dc ("IB/mlx5: Add support for extended atomic operations")
      Signed-off-by: NYonatan Cohen <yonatanc@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      13f8d9c1
    • S
      RDMA/bnxt_re: Avoid accessing the device structure after it is freed · a6c66d6a
      Selvin Xavier 提交于
      When bnxt_re_ib_reg returns failure, the device structure gets
      freed. Driver tries to access the device pointer
      after it is freed.
      
      [ 4871.034744] Failed to register with netedev: 0xffffffa1
      [ 4871.034765] infiniband (null): Failed to register with IB: 0xffffffea
      [ 4871.046430] ==================================================================
      [ 4871.046437] BUG: KASAN: use-after-free in bnxt_re_task+0x63/0x180 [bnxt_re]
      [ 4871.046439] Write of size 4 at addr ffff880fa8406f48 by task kworker/u48:2/17813
      
      [ 4871.046443] CPU: 20 PID: 17813 Comm: kworker/u48:2 Kdump: loaded Tainted: G B OE  4.20.0-rc1+ #42
      [ 4871.046444] Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.0.4 08/28/2014
      [ 4871.046447] Workqueue: bnxt_re bnxt_re_task [bnxt_re]
      [ 4871.046449] Call Trace:
      [ 4871.046454]  dump_stack+0x91/0xeb
      [ 4871.046458]  print_address_description+0x6a/0x2a0
      [ 4871.046461]  kasan_report+0x176/0x2d0
      [ 4871.046463]  ? bnxt_re_task+0x63/0x180 [bnxt_re]
      [ 4871.046466]  bnxt_re_task+0x63/0x180 [bnxt_re]
      [ 4871.046470]  process_one_work+0x216/0x5b0
      [ 4871.046471]  ? process_one_work+0x189/0x5b0
      [ 4871.046475]  worker_thread+0x4e/0x3d0
      [ 4871.046479]  kthread+0x10e/0x140
      [ 4871.046480]  ? process_one_work+0x5b0/0x5b0
      [ 4871.046482]  ? kthread_stop+0x220/0x220
      [ 4871.046486]  ret_from_fork+0x3a/0x50
      
      [ 4871.046492] The buggy address belongs to the page:
      [ 4871.046494] page:ffffea003ea10180 count:0 mapcount:0 mapping:0000000000000000 index:0x0
      [ 4871.046495] flags: 0x57ffffc0000000()
      [ 4871.046498] raw: 0057ffffc0000000 0000000000000000 ffffea003ea10188 0000000000000000
      [ 4871.046500] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
      [ 4871.046501] page dumped because: kasan: bad access detected
      
      Avoid accessing the device structure once it is freed.
      
      Fixes: 497158aa ("RDMA/bnxt_re: Fix the ib_reg failure cleanup")
      Signed-off-by: NSelvin Xavier <selvin.xavier@broadcom.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      a6c66d6a
    • S
      RDMA/bnxt_re: Fix system hang when registration with L2 driver fails · 3c4b1419
      Selvin Xavier 提交于
      Driver doesn't release rtnl lock if registration with
      L2 driver (bnxt_re_register_netdev) fais and this causes
      hang while requesting for the next lock.
      
      [  371.635416] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      [  371.635417] kworker/u48:1   D    0   634      2 0x80000000
      [  371.635423] Workqueue: bnxt_re bnxt_re_task [bnxt_re]
      [  371.635424] Call Trace:
      [  371.635426]  ? __schedule+0x36b/0xbd0
      [  371.635429]  schedule+0x39/0x90
      [  371.635430]  schedule_preempt_disabled+0x11/0x20
      [  371.635431]  __mutex_lock+0x45b/0x9c0
      [  371.635433]  ? __mutex_lock+0x16d/0x9c0
      [  371.635435]  ? bnxt_re_ib_reg+0x2b/0xb30 [bnxt_re]
      [  371.635438]  ? wake_up_klogd+0x37/0x40
      [  371.635442]  bnxt_re_ib_reg+0x2b/0xb30 [bnxt_re]
      [  371.635447]  bnxt_re_task+0xfd/0x180 [bnxt_re]
      [  371.635449]  process_one_work+0x216/0x5b0
      [  371.635450]  ? process_one_work+0x189/0x5b0
      [  371.635453]  worker_thread+0x4e/0x3d0
      [  371.635455]  kthread+0x10e/0x140
      [  371.635456]  ? process_one_work+0x5b0/0x5b0
      [  371.635458]  ? kthread_stop+0x220/0x220
      [  371.635460]  ret_from_fork+0x3a/0x50
      [  371.635477] INFO: task NetworkManager:1228 blocked for more than 120 seconds.
      [  371.635478]       Tainted: G    B      OE     4.20.0-rc1+ #42
      [  371.635479] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      
      Release the rtnl_lock correctly in the failure path.
      
      Fixes: de5c95d0 ("RDMA/bnxt_re: Fix system crash during RDMA resource initialization")
      Signed-off-by: NSelvin Xavier <selvin.xavier@broadcom.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      3c4b1419
    • M
      RDMA/mlx5: Fix fence type for IB_WR_LOCAL_INV WR · 074fca3a
      Majd Dibbiny 提交于
      Currently, for IB_WR_LOCAL_INV WR, when the next fence is None, the
      current fence will be SMALL instead of Normal Fence.
      
      Without this patch krping doesn't work on CX-5 devices and throws
      following error:
      
      The error messages are from CX5 driver are: (from server side)
      [ 710.434014] mlx5_0:dump_cqe:278:(pid 2712): dump error cqe
      [ 710.434016] 00000000 00000000 00000000 00000000
      [ 710.434016] 00000000 00000000 00000000 00000000
      [ 710.434017] 00000000 00000000 00000000 00000000
      [ 710.434018] 00000000 93003204 100000b8 000524d2
      [ 710.434019] krping: cq completion failed with wr_id 0 status 4 opcode 128 vender_err 32
      
      Fixed the logic to set the correct fence type.
      
      Fixes: 6e8484c5 ("RDMA/mlx5: set UMR wqe fence according to HCA cap")
      Signed-off-by: NMajd Dibbiny <majd@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      074fca3a
  11. 21 11月, 2018 2 次提交
  12. 13 11月, 2018 2 次提交
  13. 10 11月, 2018 1 次提交
  14. 09 11月, 2018 2 次提交
  15. 27 10月, 2018 1 次提交
  16. 19 10月, 2018 1 次提交
    • T
      net/mlx5: Refactor fragmented buffer struct fields and init flow · 4972e6fa
      Tariq Toukan 提交于
      Take struct mlx5_frag_buf out of mlx5_frag_buf_ctrl, as it is not
      needed to manage and control the datapath of the fragmented buffers API.
      
      struct mlx5_frag_buf contains control info to manage the allocation
      and de-allocation of the fragmented buffer.
      Its fields are not relevant for datapath, so here I take them out of the
      struct mlx5_frag_buf_ctrl, except for the fragments array itself.
      
      In addition, modified mlx5_fill_fbc to initialise the frags pointers
      as well. This implies that the buffer must be allocated before the
      function is called.
      
      A set of type-specific *_get_byte_size() functions are replaced by
      a generic one.
      Signed-off-by: NTariq Toukan <tariqt@mellanox.com>
      Signed-off-by: NSaeed Mahameed <saeedm@mellanox.com>
      4972e6fa
  17. 18 10月, 2018 2 次提交
  18. 17 10月, 2018 2 次提交