1. 31 8月, 2017 1 次提交
    • R
      IB/cm: Fix sleeping in atomic when RoCE is used · c7616118
      Roland Dreier 提交于
      A couple of places in the CM do
      
          spin_lock_irq(&cm_id_priv->lock);
          ...
          if (cm_alloc_response_msg(work->port, work->mad_recv_wc, &msg))
      
      However when the underlying transport is RoCE, this leads to a sleeping function
      being called with the lock held - the callchain is
      
          cm_alloc_response_msg() ->
            ib_create_ah_from_wc() ->
              ib_init_ah_from_wc() ->
                rdma_addr_find_l2_eth_by_grh() ->
                  rdma_resolve_ip()
      
      and rdma_resolve_ip() starts out by doing
      
          req = kzalloc(sizeof *req, GFP_KERNEL);
      
      not to mention rdma_addr_find_l2_eth_by_grh() doing
      
          wait_for_completion(&ctx.comp);
      
      to wait for the task that rdma_resolve_ip() queues up.
      
      Fix this by moving the AH creation out of the lock.
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      Reviewed-by: NSean Hefty <sean.hefty@intel.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      c7616118
  2. 19 8月, 2017 1 次提交
  3. 18 8月, 2017 1 次提交
  4. 09 8月, 2017 4 次提交
  5. 02 6月, 2017 1 次提交
    • M
      RDMA/SA: Fix kernel panic in CMA request handler flow · d3957b86
      Majd Dibbiny 提交于
      Commit 9fdca4da (IB/SA: Split struct sa_path_rec based on IB and
      ROCE specific fields) moved the service_id to be specific attribute
      for IB and OPA SA Path Record, and thus wasn't assigned for RoCE.
      
      This caused to the following kernel panic in the CMA request handler flow:
      
      [   27.074594] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
      [   27.074731] IP: __radix_tree_lookup+0x1d/0xe0
      ...
      [   27.075356] Workqueue: ib_cm cm_work_handler [ib_cm]
      [   27.075401] task: ffff88022e3b8000 task.stack: ffffc90001298000
      [   27.075449] RIP: 0010:__radix_tree_lookup+0x1d/0xe0
      ...
      [   27.075979] Call Trace:
      [   27.076015]  radix_tree_lookup+0xd/0x10
      [   27.076055]  cma_ps_find+0x59/0x70 [rdma_cm]
      [   27.076097]  cma_id_from_event+0xd2/0x470 [rdma_cm]
      [   27.076144]  ? ib_init_ah_from_path+0x39a/0x590 [ib_core]
      [   27.076193]  cma_req_handler+0x25/0x480 [rdma_cm]
      [   27.076237]  cm_process_work+0x25/0x120 [ib_cm]
      [   27.076280]  ? cm_get_bth_pkey.isra.62+0x3c/0xa0 [ib_cm]
      [   27.076350]  cm_req_handler+0xb03/0xd40 [ib_cm]
      [   27.076430]  ? sched_clock_cpu+0x11/0xb0
      [   27.076478]  cm_work_handler+0x194/0x1588 [ib_cm]
      [   27.076525]  process_one_work+0x160/0x410
      [   27.076565]  worker_thread+0x137/0x4a0
      [   27.076614]  kthread+0x112/0x150
      [   27.076684]  ? max_active_store+0x60/0x60
      [   27.077642]  ? kthread_park+0x90/0x90
      [   27.078530]  ret_from_fork+0x2c/0x40
      
      This patch moves it back to the common SA Path Record structure
      and removes the redundant setter and getter.
      
      Tested on Connect-IB and Connect-X4 in Infiniband and RoCE respectively.
      
      Fixes: 9fdca4da (IB/SA: Split struct sa_path_rec based on IB ands
      	ROCE specific fields)
      Signed-off-by: NMajd Dibbiny <majd@mellanox.com>
      Reviewed-by: NParav Pandit <parav@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leon@kernel.org>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      d3957b86
  6. 02 5月, 2017 10 次提交
  7. 25 1月, 2017 1 次提交
  8. 15 12月, 2016 2 次提交
  9. 17 11月, 2016 1 次提交
    • M
      IB/cm: Mark stale CM id's whenever the mad agent was unregistered · 9db0ff53
      Mark Bloch 提交于
      When there is a CM id object that has port assigned to it, it means that
      the cm-id asked for the specific port that it should go by it, but if
      that port was removed (hot-unplug event) the cm-id was not updated.
      In order to fix that the port keeps a list of all the cm-id's that are
      planning to go by it, whenever the port is removed it marks all of them
      as invalid.
      
      This commit fixes a kernel panic which happens when running traffic between
      guests and we force reboot a guest mid traffic, it triggers a kernel panic:
      
       Call Trace:
        [<ffffffff815271fa>] ? panic+0xa7/0x16f
        [<ffffffff8152b534>] ? oops_end+0xe4/0x100
        [<ffffffff8104a00b>] ? no_context+0xfb/0x260
        [<ffffffff81084db2>] ? del_timer_sync+0x22/0x30
        [<ffffffff8104a295>] ? __bad_area_nosemaphore+0x125/0x1e0
        [<ffffffff81084240>] ? process_timeout+0x0/0x10
        [<ffffffff8104a363>] ? bad_area_nosemaphore+0x13/0x20
        [<ffffffff8104aabf>] ? __do_page_fault+0x31f/0x480
        [<ffffffff81065df0>] ? default_wake_function+0x0/0x20
        [<ffffffffa0752675>] ? free_msg+0x55/0x70 [mlx5_core]
        [<ffffffffa0753434>] ? cmd_exec+0x124/0x840 [mlx5_core]
        [<ffffffff8105a924>] ? find_busiest_group+0x244/0x9f0
        [<ffffffff8152d45e>] ? do_page_fault+0x3e/0xa0
        [<ffffffff8152a815>] ? page_fault+0x25/0x30
        [<ffffffffa024da25>] ? cm_alloc_msg+0x35/0xc0 [ib_cm]
        [<ffffffffa024e821>] ? ib_send_cm_dreq+0xb1/0x1e0 [ib_cm]
        [<ffffffffa024f836>] ? cm_destroy_id+0x176/0x320 [ib_cm]
        [<ffffffffa024fb00>] ? ib_destroy_cm_id+0x10/0x20 [ib_cm]
        [<ffffffffa034f527>] ? ipoib_cm_free_rx_reap_list+0xa7/0x110 [ib_ipoib]
        [<ffffffffa034f590>] ? ipoib_cm_rx_reap+0x0/0x20 [ib_ipoib]
        [<ffffffffa034f5a5>] ? ipoib_cm_rx_reap+0x15/0x20 [ib_ipoib]
        [<ffffffff81094d20>] ? worker_thread+0x170/0x2a0
        [<ffffffff8109b2a0>] ? autoremove_wake_function+0x0/0x40
        [<ffffffff81094bb0>] ? worker_thread+0x0/0x2a0
        [<ffffffff8109aef6>] ? kthread+0x96/0xa0
        [<ffffffff8100c20a>] ? child_rip+0xa/0x20
        [<ffffffff8109ae60>] ? kthread+0x0/0xa0
        [<ffffffff8100c200>] ? child_rip+0x0/0x20
      
      Fixes: a977049d ("[PATCH] IB: Add the kernel CM implementation")
      Signed-off-by: NMark Bloch <markb@mellanox.com>
      Signed-off-by: NErez Shitrit <erezsh@mellanox.com>
      Reviewed-by: NMaor Gottlieb <maorg@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leon@kernel.org>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      9db0ff53
  10. 07 6月, 2016 1 次提交
    • B
      IB/cm: Fix a recently introduced locking bug · 943f44d9
      Bart Van Assche 提交于
      ib_cm_notify() can be called from interrupt context. Hence do not
      reenable interrupts unconditionally in cm_establish().
      
      This patch avoids that lockdep reports the following warning:
      
      WARNING: CPU: 0 PID: 23317 at kernel/locking/lockdep.c:2624 trace _hardirqs_on_caller+0x112/0x1b0
      DEBUG_LOCKS_WARN_ON(current->hardirq_context)
      Call Trace:
       <IRQ>  [<ffffffff812bd0e5>] dump_stack+0x67/0x92
       [<ffffffff81056f21>] __warn+0xc1/0xe0
       [<ffffffff81056f8a>] warn_slowpath_fmt+0x4a/0x50
       [<ffffffff810a5932>] trace_hardirqs_on_caller+0x112/0x1b0
       [<ffffffff810a59dd>] trace_hardirqs_on+0xd/0x10
       [<ffffffff815992c7>] _raw_spin_unlock_irq+0x27/0x40
       [<ffffffffa0382e9c>] ib_cm_notify+0x25c/0x290 [ib_cm]
       [<ffffffffa068fbc1>] srpt_qp_event+0xa1/0xf0 [ib_srpt]
       [<ffffffffa04efb97>] mlx4_ib_qp_event+0x67/0xd0 [mlx4_ib]
       [<ffffffffa034ec0a>] mlx4_qp_event+0x5a/0xc0 [mlx4_core]
       [<ffffffffa03365f8>] mlx4_eq_int+0x3d8/0xcf0 [mlx4_core]
       [<ffffffffa0336f9c>] mlx4_msi_x_interrupt+0xc/0x20 [mlx4_core]
       [<ffffffff810b0914>] handle_irq_event_percpu+0x64/0x100
       [<ffffffff810b09e4>] handle_irq_event+0x34/0x60
       [<ffffffff810b3a6a>] handle_edge_irq+0x6a/0x150
       [<ffffffff8101ad05>] handle_irq+0x15/0x20
       [<ffffffff8101a66c>] do_IRQ+0x5c/0x110
       [<ffffffff8159a2c9>] common_interrupt+0x89/0x89
       [<ffffffff81297a17>] blk_run_queue_async+0x37/0x40
       [<ffffffffa0163e53>] rq_completed+0x43/0x70 [dm_mod]
       [<ffffffffa0164896>] dm_softirq_done+0x176/0x280 [dm_mod]
       [<ffffffff812a26c2>] blk_done_softirq+0x52/0x90
       [<ffffffff8105bc1f>] __do_softirq+0x10f/0x230
       [<ffffffff8105bec8>] irq_exit+0xa8/0xb0
       [<ffffffff8103653e>] smp_trace_call_function_single_interrupt+0x2e/0x30
       [<ffffffff81036549>] smp_call_function_single_interrupt+0x9/0x10
       [<ffffffff8159a959>] call_function_single_interrupt+0x89/0x90
       <EOI>
      
      Fixes: commit be4b4993 (IB/cm: Do not queue work to a device that's going away)
      Signed-off-by: NBart Van Assche <bart.vanassche@sandisk.com>
      Cc: Erez Shitrit <erezsh@mellanox.com>
      Cc: Sean Hefty <sean.hefty@intel.com>
      Cc: Nikolay Borisov <kernel@kyup.com>
      Cc: stable <stable@vger.kernel.org> # v4.2+
      Acked-by: NErez Shitrit <erezsh@mellanox.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      943f44d9
  11. 20 1月, 2016 3 次提交
    • M
      IB/core: Use hop-limit from IP stack for RoCE · c3efe750
      Matan Barak 提交于
      Previously, IPV6_DEFAULT_HOPLIMIT was used as the hop limit value for
      RoCE. Fixing that by taking ip4_dst_hoplimit and ip6_dst_hoplimit as
      hop limit values.
      Signed-off-by: NMatan Barak <matanb@mellanox.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      c3efe750
    • B
      IB/cm: Fix a recently introduced deadlock · 4bfdf635
      Bart Van Assche 提交于
      ib_send_cm_drep() calls cm_enter_timewait() while holding a spinlock
      that can be locked from inside an interrupt handler. Hence do not
      enable interrupts inside cm_enter_timewait() if called with interrupts
      disabled.
      
      This patch fixes e.g. the following deadlock:
      Acked-by: NErez Shitrit <erezsh@mellanox.com>
      
      =================================
      [ INFO: inconsistent lock state ]
      4.4.0-rc7+ #1 Tainted: G            E
      ---------------------------------
      inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
      swapper/8/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
      (&(&cm_id_priv->lock)->rlock){?.+...}, at: [<ffffffffa036eec4>] cm_establish+0x
      74/0x1b0 [ib_cm]
      {HARDIRQ-ON-W} state was registered at:
        [<ffffffff810a3c11>] mark_held_locks+0x71/0x90
        [<ffffffff810a3e87>] trace_hardirqs_on_caller+0xa7/0x1c0
        [<ffffffff810a3fad>] trace_hardirqs_on+0xd/0x10
        [<ffffffff8151c40b>] _raw_spin_unlock_irq+0x2b/0x40
        [<ffffffffa036ea8e>] cm_enter_timewait+0xae/0x100 [ib_cm]
        [<ffffffffa036ff76>] ib_send_cm_drep+0xb6/0x190 [ib_cm]
        [<ffffffffa052ed08>] srp_cm_handler+0x128/0x1a0 [ib_srp]
        [<ffffffffa0370340>] cm_process_work+0x20/0xf0 [ib_cm]
        [<ffffffffa0371335>] cm_dreq_handler+0x135/0x2c0 [ib_cm]
        [<ffffffffa03733c5>] cm_work_handler+0x75/0xd0 [ib_cm]
        [<ffffffff8107184d>] process_one_work+0x1bd/0x460
        [<ffffffff81073148>] worker_thread+0x118/0x420
        [<ffffffff81078454>] kthread+0xe4/0x100
        [<ffffffff8151cbbf>] ret_from_fork+0x3f/0x70
      irq event stamp: 1672286
      hardirqs last  enabled at (1672283): [<ffffffff81408ec0>] poll_idle+0x10/0x80
      hardirqs last disabled at (1672284): [<ffffffff8151d304>] common_interrupt+0x84/0x89
      softirqs last  enabled at (1672286): [<ffffffff8105b4dc>] _local_bh_enable+0x1c/0x50
      softirqs last disabled at (1672285): [<ffffffff8105b697>] irq_enter+0x47/0x70
      
      other info that might help us debug this:
       Possible unsafe locking scenario:
      
             CPU0
             ----
        lock(&(&cm_id_priv->lock)->rlock);
        <Interrupt>
          lock(&(&cm_id_priv->lock)->rlock);
      
       *** DEADLOCK ***
      
      no locks held by swapper/8/0.
      
      stack backtrace:
      CPU: 8 PID: 0 Comm: swapper/8 Tainted: G            E   4.4.0-rc7+ #1
      Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 1.0.2 11/17/2014
       ffff88045af5e950 ffff88046e503a88 ffffffff81251c1b 0000000000000007
       0000000000000006 0000000000000003 ffff88045af5ddc0 ffff88046e503ad8
       ffffffff810a32f4 0000000000000000 0000000000000000 0000000000000001
      Call Trace:
       <IRQ>  [<ffffffff81251c1b>] dump_stack+0x4f/0x74
       [<ffffffff810a32f4>] print_usage_bug+0x184/0x190
       [<ffffffff810a36e2>] mark_lock_irq+0xf2/0x290
       [<ffffffff810a3995>] mark_lock+0x115/0x1b0
       [<ffffffff810a3b8c>] mark_irqflags+0x15c/0x170
       [<ffffffff810a4fef>] __lock_acquire+0x1ef/0x560
       [<ffffffff810a53c2>] lock_acquire+0x62/0x80
       [<ffffffff8151bd33>] _raw_spin_lock_irqsave+0x43/0x60
       [<ffffffffa036eec4>] cm_establish+0x74/0x1b0 [ib_cm]
       [<ffffffffa036f031>] ib_cm_notify+0x31/0x100 [ib_cm]
       [<ffffffffa0637f24>] srpt_qp_event+0x54/0xd0 [ib_srpt]
       [<ffffffffa0196052>] mlx4_ib_qp_event+0x72/0xc0 [mlx4_ib]
       [<ffffffffa00775b9>] mlx4_qp_event+0x69/0xd0 [mlx4_core]
       [<ffffffffa006000e>] mlx4_eq_int+0x51e/0xd50 [mlx4_core]
       [<ffffffffa006084f>] mlx4_msi_x_interrupt+0xf/0x20 [mlx4_core]
       [<ffffffff810b67b0>] handle_irq_event_percpu+0x40/0x110
       [<ffffffff810b68bf>] handle_irq_event+0x3f/0x70
       [<ffffffff810ba7f9>] handle_edge_irq+0x79/0x120
       [<ffffffff81007f3d>] handle_irq+0x5d/0x130
       [<ffffffff810071fd>] do_IRQ+0x6d/0x130
       [<ffffffff8151d309>] common_interrupt+0x89/0x89
       <EOI>  [<ffffffff8140895f>] cpuidle_enter_state+0xcf/0x200
       [<ffffffff81408aa2>] cpuidle_enter+0x12/0x20
       [<ffffffff810990d6>] call_cpuidle+0x36/0x60
       [<ffffffff81099163>] cpuidle_idle_call+0x63/0x110
       [<ffffffff8109930a>] cpu_idle_loop+0xfa/0x130
       [<ffffffff8109934e>] cpu_startup_entry+0xe/0x10
       [<ffffffff8103c443>] start_secondary+0x83/0x90
      
      Fixes: commit be4b4993 ("IB/cm: Do not queue work to a device that's going away")
      Signed-off-by: NBart Van Assche <bart.vanassche@sandisk.com>
      Cc: Erez Shitrit <erezsh@mellanox.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      4bfdf635
    • C
      IB/mad: pass ib_mad_send_buf explicitly to the recv_handler · ca281265
      Christoph Hellwig 提交于
      Stop abusing wr_id and just pass the parameter explicitly.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NHal Rosenstock <hal@mellanox.com>
      Reviewed-by: NIra Weiny <ira.weiny@intel.com>
      Reviewed-by: NSagi Grimberg <sagig@mellanox.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      ca281265
  12. 23 12月, 2015 4 次提交
  13. 22 10月, 2015 4 次提交
  14. 31 8月, 2015 5 次提交
  15. 15 7月, 2015 1 次提交