1. 02 5月, 2017 9 次提交
  2. 25 1月, 2017 1 次提交
  3. 15 12月, 2016 2 次提交
  4. 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
  5. 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
  6. 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
  7. 23 12月, 2015 4 次提交
  8. 22 10月, 2015 4 次提交
  9. 31 8月, 2015 5 次提交
  10. 15 7月, 2015 1 次提交
  11. 13 6月, 2015 1 次提交
  12. 21 5月, 2015 1 次提交
    • T
      ib/cm: Change reject message type when destroying cm_id · c29ed5a4
      Ted Kim 提交于
      Problem reported by: Ted Kim <ted.h.kim@oracle.com>:
      
      We have a case where a Linux system and a non-Linux system are
      trying to interoperate.  The Linux host is the active side and
      starts the connection establishment, but later decides to not go
      through with the connection setup and does rdma_destroy_id().
      
      The rdma_destroy_id() eventually works its way down to cm_destroy_id()
      in core/cm.c, where a REJ is sent. The non-Linux system
      has some trouble recognizing the REJ because of:
      
      A. CM states which can't receive the REJ
      B. Some issues about REJ formatting (missing comm ID)
      
      ISSUE A: That part of the spec says, a Consumer Reject REJ can be
      sent for a connection abort, but it goes further
      and says: can send a REJ message with a "Consumer Reject"
      Reason code if they are in a CM state (i.e. REP
      Rcvd, MRA(REP) Sent, REQ Rcvd, MRA Sent) that allows
      a REJ to be sent (lines 35-38).
      
      Of the states listed there in that sentence, it would
      seem to limit the active side to using the Consumer Reject
      (for the abort case) in just the REP-Rcvd and MRA-REP-Sent
      states. That is basically only after the active side
      sees a REP (or alternatively goes down the state transitions
      to timeout in which case a Timeout REJ is sent).
      
      As a fix, in cm-destroy-id() move the IB-CM-MRA-REQ-RCVD case
      to the same as REQ-SENT.  Essentially, make a REJ sent after
      getting an MRA on active side a timeout rather than Consumer-
      Reject, which is arguably more correct with the CM state
      diagrams previous to getting a REP.
      Signed-off-by: NTed Kim <ted.h.kim@oracle.com>
      Signed-off-by: NSean Hefty <sean.hefty@intel.com>
      c29ed5a4
  13. 19 5月, 2015 2 次提交
  14. 06 5月, 2015 1 次提交
    • D
      IB/core: Fix unaligned accesses · 0d0f738f
      David Ahern 提交于
      Addresses the following kernel logs seen during boot of sparc systems:
      
      Kernel unaligned access at TPC[103bce50] cm_find_listen+0x34/0xf8 [ib_cm]
      Kernel unaligned access at TPC[103bce50] cm_find_listen+0x34/0xf8 [ib_cm]
      Kernel unaligned access at TPC[103bce50] cm_find_listen+0x34/0xf8 [ib_cm]
      Kernel unaligned access at TPC[103bce50] cm_find_listen+0x34/0xf8 [ib_cm]
      Kernel unaligned access at TPC[103bce50] cm_find_listen+0x34/0xf8 [ib_cm]
      Signed-off-by: NDavid Ahern <david.ahern@oracle.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      0d0f738f
  15. 11 8月, 2014 1 次提交
  16. 02 4月, 2014 1 次提交
  17. 20 1月, 2014 1 次提交
  18. 15 1月, 2014 1 次提交
    • M
      IB/core: Ethernet L2 attributes in verbs/cm structures · dd5f03be
      Matan Barak 提交于
      This patch add the support for Ethernet L2 attributes in the
      verbs/cm/cma structures.
      
      When dealing with L2 Ethernet, we should use smac, dmac, vlan ID and priority
      in a similar manner that the IB L2 (and the L4 PKEY) attributes are used.
      
      Thus, those attributes were added to the following structures:
      
      * ib_ah_attr - added dmac
      * ib_qp_attr - added smac and vlan_id, (sl remains vlan priority)
      * ib_wc - added smac, vlan_id
      * ib_sa_path_rec - added smac, dmac, vlan_id
      * cm_av - added smac and vlan_id
      
      For the path record structure, extra care was taken to avoid the new
      fields when packing it into wire format, so we don't break the IB CM
      and SA wire protocol.
      
      On the active side, the CM fills. its internal structures from the
      path provided by the ULP.  We add there taking the ETH L2 attributes
      and placing them into the CM Address Handle (struct cm_av).
      
      On the passive side, the CM fills its internal structures from the WC
      associated with the REQ message.  We add there taking the ETH L2
      attributes from the WC.
      
      When the HW driver provides the required ETH L2 attributes in the WC,
      they set the IB_WC_WITH_SMAC and IB_WC_WITH_VLAN flags. The IB core
      code checks for the presence of these flags, and in their absence does
      address resolution from the ib_init_ah_from_wc() helper function.
      
      ib_modify_qp_is_ok is also updated to consider the link layer. Some
      parameters are mandatory for Ethernet link layer, while they are
      irrelevant for IB.  Vendor drivers are modified to support the new
      function signature.
      Signed-off-by: NMatan Barak <matanb@mellanox.com>
      Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      dd5f03be