linux.git/drivers/infiniband/ulp, branch v2.6.16 Linux kernel source tree IB/srp: Don't send task management commands after target removal 2006-03-04T01:50:16+00:00 Roland Dreier rolandd@cisco.com 2006-03-03T23:47:25+00:00 1285b3a0b0aa2391ac6f6939e6737203c8220f68 Just fail abort and reset requests that come in after we've already decided to remove a target. Signed-off-by: Roland Dreier <rolandd@cisco.com> 
Just fail abort and reset requests that come in after we've already
decided to remove a target.

Signed-off-by: Roland Dreier <rolandd@cisco.com>
IPoIB: Yet another fix for send-only joins 2006-02-11T20:22:12+00:00 Roland Dreier rolandd@cisco.com 2006-02-11T20:22:12+00:00 20b83382d1c5d4d1a73fc5671261db5239d1dbb3 Even after the last fix, it's still possible for a send-only join to start before the join for the broadcast group has finished. This could cause us to create a multicast group using attributes from the broadcast group that haven't been initialized yet, so we would use garbage for the Q_Key, etc. Fix this by waiting until the broadcast group's attached flag is set before starting send-only joins. Signed-off-by: Roland Dreier <rolandd@cisco.com> 
Even after the last fix, it's still possible for a send-only join to
start before the join for the broadcast group has finished.  This
could cause us to create a multicast group using attributes from the
broadcast group that haven't been initialized yet, so we would use
garbage for the Q_Key, etc.  Fix this by waiting until the broadcast
group's attached flag is set before starting send-only joins.

Signed-off-by: Roland Dreier <rolandd@cisco.com>
IPoIB: Fix another send-only join race 2006-02-08T00:39:26+00:00 Michael S. Tsirkin mst@mellanox.co.il 2006-02-08T00:39:26+00:00 7bcb974ef6a0ae903888272c92c66ea779388c01 Further, there's an additional issue that I saw in testing: ipoib_mcast_send may get called when priv->broadcast is NULL (e.g. if the device was downed and then upped internally because of a port event). If this happends and the send-only join request gets completed before priv->broadcast is set, we get an oops. Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il> Signed-off-by: Roland Dreier <rolandd@cisco.com> 
Further, there's an additional issue that I saw in testing:
ipoib_mcast_send may get called when priv->broadcast is NULL (e.g. if
the device was downed and then upped internally because of a port
event).

If this happends and the send-only join request gets completed before
priv->broadcast is set, we get an oops.

Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
IPoIB: Don't start send-only joins while multicast thread is stopped 2006-02-08T00:37:08+00:00 Michael S. Tsirkin mst@mellanox.co.il 2006-02-08T00:37:08+00:00 479a079663bd4c5f3d2714643b1b8c406aaba3e0 Fix the following race scenario: - Device is up. - Port event or set mcast list triggers ipoib_mcast_stop_thread, this cancels the query and waits on mcast "done" completion. - Completion is called and "done" is set. - Meanwhile, ipoib_mcast_send arrives and starts a new query, re-initializing "done". Fix this by adding a "multicast started" bit and checking it before starting a send-only join. Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il> Signed-off-by: Roland Dreier <rolandd@cisco.com> 
Fix the following race scenario:
  - Device is up.
  - Port event or set mcast list triggers ipoib_mcast_stop_thread,
    this cancels the query and waits on mcast "done" completion.
  - Completion is called and "done" is set.
  - Meanwhile, ipoib_mcast_send arrives and starts a new query,
    re-initializing "done".

Fix this by adding a "multicast started" bit and checking it before
starting a send-only join.

Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
IB/srp: Semaphore to mutex conversion 2006-01-30T23:21:21+00:00 Ingo Molnar mingo@elte.hu 2006-01-30T23:21:21+00:00 8e9e5f4f5eb1d44ddabfd1ddea4ca4e4244a9ffb Convert srp_host->target_mutex from a semaphore to a mutex. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Roland Dreier <rolandd@cisco.com> 
Convert srp_host->target_mutex from a semaphore to a mutex.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
IPoIB: Lock accesses to multicast packet queues 2006-01-17T20:19:40+00:00 Michael S. Tsirkin mst@mellanox.co.il 2006-01-17T20:19:40+00:00 b36f170b617a7cd147b694dabf504e856a50ee9d Avoid corrupting mcast->pkt_queue by serializing access with priv->tx_lock. Also, update dropped packet statistics to count multicast packets removed from pkt_queue as dropped. Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il> Signed-off-by: Roland Dreier <rolandd@cisco.com> 
Avoid corrupting mcast->pkt_queue by serializing access with
priv->tx_lock.  Also, update dropped packet statistics to count
multicast packets removed from pkt_queue as dropped.

Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
IPoIB: Make sure path is fully initialized before using it 2006-01-17T17:22:05+00:00 Michael S. Tsirkin mst@mellanox.co.il 2006-01-17T17:22:05+00:00 47f7a0714b67b904a3a36e2f2d85904e8064219b The SA path record query completion can initialize path->pathrec.dlid before IPoIB's callback runs and initializes path->ah, so we must test ah rather than dlid. Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il> Signed-off-by: Roland Dreier <rolandd@cisco.com> 
The SA path record query completion can initialize path->pathrec.dlid
before IPoIB's callback runs and initializes path->ah, so we must test
ah rather than dlid.

Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
IB: convert from semaphores to mutexes 2006-01-13T22:51:39+00:00 Ingo Molnar mingo@elte.hu 2006-01-13T22:51:39+00:00 95ed644fd12f53c6fc778f3f246974e5fe3a9468 semaphore to mutex conversion by Ingo and Arjan's script. Signed-off-by: Ingo Molnar <mingo@elte.hu> [ Sanity-checked on real IB hardware ] Signed-off-by: Roland Dreier <rolandd@cisco.com> 
semaphore to mutex conversion by Ingo and Arjan's script.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
[ Sanity-checked on real IB hardware ]
Signed-off-by: Roland Dreier <rolandd@cisco.com>
IPoIB: Fix memory leak of multicast group structures 2006-01-12T22:32:20+00:00 Eli Cohen eli@mellanox.co.il 2006-01-12T22:32:20+00:00 988bd50300ef2e2d5cb8563e2ac99453dd9acd86 The current handling of multicast groups in IPoIB ends up never freeing send-only multicast groups. It turns out the logic was much more complicated than it needed to be; we can fix this bug and completely kill ipoib_mcast_dev_down() at the same time. Signed-off-by: Eli Cohen <eli@mellanox.co.il> Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il> Signed-off-by: Roland Dreier <rolandd@cisco.com> 
The current handling of multicast groups in IPoIB ends up never
freeing send-only multicast groups.  It turns out the logic was much
more complicated than it needed to be; we can fix this bug and
completely kill ipoib_mcast_dev_down() at the same time.

Signed-off-by: Eli Cohen <eli@mellanox.co.il>
Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
IPoIB: Take dev->xmit_lock around mc_list accesses 2006-01-11T19:47:34+00:00 Michael S. Tsirkin mst@mellanox.co.il 2006-01-11T19:47:34+00:00 78bfe0b5b67fe126ed98608e42e42fb6ed9aabd4 dev->mc_list accesses must be protected by dev->xmit_lock. Found by Eli Cohen <eli@mellanox.co.il>. Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il> Signed-off-by: Roland Dreier <rolandd@cisco.com> 
dev->mc_list accesses must be protected by dev->xmit_lock.
Found by Eli Cohen <eli@mellanox.co.il>.

Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il>
Signed-off-by: Roland Dreier <rolandd@cisco.com>