1. 09 4月, 2009 1 次提交
    • Y
      RDMA/cma: Create cm id even when IB port is down · d2ca39f2
      Yossi Etigin 提交于
      When doing rdma_resolve_addr(), if the relevant IB port is down, the
      function fails and the cm_id is not bound to the correct device.
      Therefore, application does not have a device handle and cannot wait
      for the port to become active.  The function fails because the
      underlying IPoIB interface is not joined to the broadcast group and
      therefore the SA does not have a multicast record to take a Q_Key
      from.
      
      The fix is to use lazy Q_Key resolution - cma_set_qkey() will set
      id_priv->qkey if it was not set, and will be called just before the
      Q_Key is really required.
      Signed-off-by: NYossi Etigin <yosefe@voltaire.com>
      Acked-by: NSean Hefty <sean.hefty@intel.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      d2ca39f2
  2. 02 4月, 2009 1 次提交
  3. 27 3月, 2009 1 次提交
  4. 25 3月, 2009 1 次提交
    • S
      RDMA/cxgb3: Enforce required firmware · d1fbe04e
      Steve Wise 提交于
      The cxgb3 NIC driver can handle more firmware versions than iw_cxgb3,
      and since commit 8207befa ("cxgb3: untie strict FW matching") cxgb3
      will load with firmware versions that iw_cxgb3 can't handle.  The FW
      major number indicates a specific interface between the FW and
      iw_cxgb3.  Thus if the major number of the running firmware does not
      match the required version compiled into iw_cxgb3, then iw_cxgb3 must
      not register that device.
      Signed-off-by: NSteve Wise <swise@opengridcomputing.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      d1fbe04e
  5. 22 3月, 2009 3 次提交
  6. 19 3月, 2009 1 次提交
  7. 13 3月, 2009 1 次提交
    • F
      RDMA/nes: Don't allow userspace QPs to use STag zero · c12e56ef
      Faisal Latif 提交于
      STag zero is a special STag that allows consumers to access any bus
      address without registering memory.  The nes driver unfortunately
      allows STag zero to be used even with QPs created by unprivileged
      userspace consumers, which means that any process with direct verbs
      access to the nes device can read and write any memory accessible to
      the underlying PCI device (usually any memory in the system).  Such
      access is usually given for cluster software such as MPI to use, so
      this is a local privilege escalation bug on most systems running this
      driver.
      
      The driver was using STag zero to receive the last streaming mode
      data; to allow STag zero to be disabled for unprivileged QPs, the
      driver now registers a special MR for this data.
      
      Cc: <stable@kernel.org>
      Signed-off-by: NFaisal Latif <faisal.latif@intel.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c12e56ef
  8. 07 3月, 2009 8 次提交
  9. 05 3月, 2009 1 次提交
  10. 04 3月, 2009 2 次提交
    • J
      IB/sa_query: Fix AH leak due to update_sm_ah() race · 6b708b3d
      Jack Morgenstein 提交于
      Our testing uncovered a race condition in ib_sa_event():
      
      	spin_lock_irqsave(&port->ah_lock, flags);
      	if (port->sm_ah)
      		kref_put(&port->sm_ah->ref, free_sm_ah);
      	port->sm_ah = NULL;
      	spin_unlock_irqrestore(&port->ah_lock, flags);
      
      	schedule_work(&sa_dev->port[event->element.port_num -
      				    sa_dev->start_port].update_task);
      
      If two events occur back-to-back (e.g., client-reregister and LID
      change), both may pass the spinlock-protected code above before the
      scheduled work updates the port->sm_ah handle.  Then if the scheduled
      work ends up running twice, the second operation will then find a
      non-NULL port->sm_ah, and will simply overwrite it in update_sm_ah --
      resulting in an AH leak.
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      6b708b3d
    • R
      IB/mad: Fix ib_post_send_mad() returning 0 with no generate send comp · 4780c195
      Ralph Campbell 提交于
      If ib_post_send_mad() returns 0, the API guarantees that there will be
      a callback to send_buf->mad_agent->send_handler() so that the sender
      can call ib_free_send_mad().  Otherwise, the ib_mad_send_buf will be
      leaked and the mad_agent reference count will never go to zero and the
      IB device module cannot be unloaded.  The above can happen without
      this patch if process_mad() returns (IB_MAD_RESULT_SUCCESS |
      IB_MAD_RESULT_CONSUMED).
      
      If process_mad() returns IB_MAD_RESULT_SUCCESS and there is no agent
      registered to receive the mad being sent, handle_outgoing_dr_smp()
      returns zero which causes a MAD packet which is at the end of the
      directed route to be incorrectly sent on the wire but doesn't cause a
      hang since the HCA generates a send completion.
      Signed-off-by: NRalph Campbell <ralph.campbell@qlogic.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      4780c195
  11. 28 2月, 2009 3 次提交
  12. 26 2月, 2009 1 次提交
    • R
      IB: Remove sysfs files before unregistering device · 9206dff1
      Roland Dreier 提交于
      Move the ib_device_unregister_sysfs() call from ib_dealloc_device() to
      ib_unregister_device().  The old code allows device unregister to
      proceed even if some sysfs files are open, which leaves a window where
      userspace can open a file before a device is removed but then end up
      reading the file after the device is removed, which leads to various
      kernel crashes either because the device data structure is freed or
      because the low-level driver code is gone after module removal.
      
      By not returning from ib_unregister_device() until after all sysfs
      entries are removed, we make sure that data structures and/or module
      code is not freed until after all sysfs access is done.
      Reported-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      9206dff1
  13. 23 2月, 2009 2 次提交
  14. 19 2月, 2009 1 次提交
    • I
      timers: add mod_timer_pending() · 74019224
      Ingo Molnar 提交于
      Impact: new timer API
      
      Based on an idea from Martin Josefsson with the help of
      Patrick McHardy and Stephen Hemminger:
      
      introduce the mod_timer_pending() API which is a mod_timer()
      offspring that is an invariant on already removed timers.
      
      (regular mod_timer() re-activates non-pending timers.)
      
      This is useful for the networking code in that it can
      allow unserialized mod_timer_pending() timer-forwarding
      calls, but a single del_timer*() will stop the timer
      from being reactivated again.
      
      Also while at it:
      
      - optimize the regular mod_timer() path some more, the
        timer-stat and a debug check was needlessly duplicated
        in __mod_timer().
      
      - make the exports come straight after the function, as
        most other exports in timer.c already did.
      
      - eliminate __mod_timer() as an external API, change the
        users to mod_timer().
      
      The regular mod_timer() code path is not impacted
      significantly, due to inlining optimizations and due to
      the simplifications.
      
      Based-on-patch-from: Stephen Hemminger <shemminger@vyatta.com>
      Acked-by: NStephen Hemminger <shemminger@vyatta.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Patrick McHardy <kaber@trash.net>
      Cc: netdev@vger.kernel.org
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      74019224
  15. 18 2月, 2009 1 次提交
  16. 17 2月, 2009 1 次提交
  17. 11 2月, 2009 2 次提交
  18. 29 1月, 2009 2 次提交
    • M
      IB/mthca: Fix dispatch of IB_EVENT_LID_CHANGE event · 270b8b85
      Moni Shoua 提交于
      When snooping a PortInfo MAD, its client_reregister bit is checked.
      If the bit is ON then a CLIENT_REREGISTER event is dispatched,
      otherwise a LID_CHANGE event is dispatched.  This way of decision
      ignores the cases where the MAD changes the LID along with an
      instruction to reregister (so a necessary LID_CHANGE event won't be
      dispatched) or the MAD is neither of these (and an unnecessary
      LID_CHANGE event will be dispatched).
      
      This causes problems at least with IPoIB, which will do a "light"
      flush on reregister, rather than the "heavy" flush required due to a
      LID change.
      
      Fix this by dispatching a CLIENT_REREGISTER event if the
      client_reregister bit is set, but also compare the LID in the MAD to
      the current LID.  If and only if they are not identical then a
      LID_CHANGE event is dispatched.
      Signed-off-by: NMoni Shoua <monis@voltaire.com>
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NYossi Etigin <yosefe@voltaire.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      270b8b85
    • M
      IB/mlx4: Fix dispatch of IB_EVENT_LID_CHANGE event · f0f6f346
      Moni Shoua 提交于
      When snooping a PortInfo MAD, its client_reregister bit is checked.
      If the bit is ON then a CLIENT_REREGISTER event is dispatched,
      otherwise a LID_CHANGE event is dispatched.  This way of decision
      ignores the cases where the MAD changes the LID along with an
      instruction to reregister (so a necessary LID_CHANGE event won't be
      dispatched) or the MAD is neither of these (and an unnecessary
      LID_CHANGE event will be dispatched).
      
      This causes problems at least with IPoIB, which will do a "light"
      flush on reregister, rather than the "heavy" flush required due to a
      LID change.
      
      Fix this by dispatching a CLIENT_REREGISTER event if the
      client_reregister bit is set, but also compare the LID in the MAD to
      the current LID.  If and only if they are not identical then a
      LID_CHANGE event is dispatched.
      Signed-off-by: NMoni Shoua <monis@voltaire.com>
      Signed-off-by: NJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: NYossi Etigin <yosefe@voltaire.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      f0f6f346
  19. 27 1月, 2009 1 次提交
  20. 22 1月, 2009 1 次提交
  21. 18 1月, 2009 1 次提交
  22. 17 1月, 2009 4 次提交