1. 19 4月, 2007 25 次提交
  2. 17 4月, 2007 1 次提交
    • M
      IB/mthca: Fix data corruption after FMR unmap on Sinai · 608d8268
      Michael S. Tsirkin 提交于
      In mthca_arbel_fmr_unmap(), the high bits of the key are masked off.
      This gets rid of the effect of adjust_key(), which makes sure that
      bits 3 and 23 of the key are equal when the Sinai throughput
      optimization is enabled, and so it may happen that an FMR will end up
      with bits 3 and 23 in the key being different.  This causes data
      corruption, because when enabling the throughput optimization, the
      driver promises the HCA firmware that bits 3 and 23 of all memory keys
      will always be equal.
      
      Fix by re-applying adjust_key() after masking the key.
      
      Thanks to Or Gerlitz for reproducing the problem, and Ariel Shahar for
      help in debug.
      Signed-off-by: NMichael S. Tsirkin <mst@dev.mellanox.co.il>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      608d8268
  3. 13 4月, 2007 1 次提交
  4. 10 4月, 2007 1 次提交
  5. 06 4月, 2007 1 次提交
    • E
      IB/iser: Don't defer connection failure notification to workqueue · 1d426d64
      Erez Zilber 提交于
      When a connection is terminated asynchronously from the iSCSI layer's
      perspective, iSER needs to notify the iSCSI layer that the connection
      has failed.  This is done using a workqueue (switched to from the iSER
      tasklet context).  Meanwhile, the connection object (that holds the
      work struct) is released.  If the workqueue function wasn't called
      yet, it will be called later with a NULL pointer, which will crash the
      kernel.
      
      The context switch (tasklet to workqueue) is not required, and
      everything can be done from the iSER tasklet. This eliminates the NULL
      work struct bug (and simplifies the code).
      Signed-off-by: NErez Zilber <erezz@voltaire.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      1d426d64
  6. 27 3月, 2007 3 次提交
  7. 26 3月, 2007 1 次提交
    • A
      [NET]: Fix neighbour destructor handling. · ecbb4169
      Alexey Kuznetsov 提交于
      ->neigh_destructor() is killed (not used), replaced with
      ->neigh_cleanup(), which is called when neighbor entry goes to dead
      state. At this point everything is still valid: neigh->dev,
      neigh->parms etc.
      
      The device should guarantee that dead neighbor entries (neigh->dead !=
      0) do not get private part initialized, otherwise nobody will cleanup
      it.
      
      I think this is enough for ipoib which is the only user of this thing.
      Initialization private part of neighbor entries happens in ipib
      start_xmit routine, which is not reached when device is down.  But it
      would be better to add explicit test for neigh->dead in any case.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ecbb4169
  8. 23 3月, 2007 7 次提交