Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 30 11月, 2006 15 次提交
  3. 14 11月, 2006 1 次提交
    • R
      IB/mad: Fix race between cancel and receive completion · 39798695
      由 Roland Dreier 提交于 
      When ib_cancel_mad() is called, it puts the canceled send on a list
and schedules a "flushed" callback from process context.  However,
this leaves a window where a receive completion could be processed
before the send is fully flushed.

This is fine, except that ib_find_send_mad() will find the MAD and
return it to the receive processing, which results in the sender
getting both a successful receive and a "flushed" send completion for
the same request.  Understandably, this confuses the sender, which is
expecting only one of these two callbacks, and leads to grief such as
a use-after-free in IPoIB.

Fix this by changing ib_find_send_mad() to return a send struct only
if the status is still successful (and not "flushed").  The search of
the send_list already had this check, so this patch just adds the same
check to the search of the wait_list.
Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      39798695
  5. 03 11月, 2006 1 次提交
  7. 31 10月, 2006 2 次提交
  9. 11 10月, 2006 2 次提交
    • S
      IB/cm: Send DREP in response to unmatched DREQ · 82a9c16a
      由 Sean Hefty 提交于 
      Currently a DREP is only sent in response to a DREQ if a connection
has been found matching the DREQ, and it is in the proper state.  Once
a DREP is sent, the local connection moves into timewait.  Duplicate
DREQs received while in this state result in re-sending the DREP.

However, it's likely that the local connection will enter and exit
timewait before the remote side times out a lost DREP and resends a DREQ.
To handle this, we send a DREP in response to a DREQ, even if a local
connection is not found.  This avoids maintaining disconnected
id's in timewait states for excessively long times, just to handle a
lost DREP.
Signed-off-by: NSean Hefty <sean.hefty@intel.com>
Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      82a9c16a
    • S
      IB/cm: Fix timewait crash after module unload · 8575329d
      由 Sean Hefty 提交于 
      If the ib_cm module is unloaded while id's are still in timewait, the
CM will destroy the work queue used to process timewait.  Once the
id's exit timewait, their timers will fire, leading to a crash trying
to access the destroyed work queue.

We need to track id's that are in timewait, and cancel their deferred
work on module unload.
Signed-off-by: NSean Hefty <sean.hefty@intel.com>
Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      8575329d
  11. 03 10月, 2006 5 次提交
  13. 29 9月, 2006 1 次提交
  15. 27 9月, 2006 1 次提交
  17. 24 9月, 2006 1 次提交
  19. 23 9月, 2006 11 次提交