1. 15 9月, 2006 1 次提交
  2. 25 7月, 2006 1 次提交
  3. 27 6月, 2006 1 次提交
  4. 18 6月, 2006 2 次提交
    • H
      [NET]: Add netif_tx_lock · 932ff279
      Herbert Xu 提交于
      Various drivers use xmit_lock internally to synchronise with their
      transmission routines.  They do so without setting xmit_lock_owner.
      This is fine as long as netpoll is not in use.
      
      With netpoll it is possible for deadlocks to occur if xmit_lock_owner
      isn't set.  This is because if a printk occurs while xmit_lock is held
      and xmit_lock_owner is not set can cause netpoll to attempt to take
      xmit_lock recursively.
      
      While it is possible to resolve this by getting netpoll to use
      trylock, it is suboptimal because netpoll's sole objective is to
      maximise the chance of getting the printk out on the wire.  So
      delaying or dropping the message is to be avoided as much as possible.
      
      So the only alternative is to always set xmit_lock_owner.  The
      following patch does this by introducing the netif_tx_lock family of
      functions that take care of setting/unsetting xmit_lock_owner.
      
      I renamed xmit_lock to _xmit_lock to indicate that it should not be
      used directly.  I didn't provide irq versions of the netif_tx_lock
      functions since xmit_lock is meant to be a BH-disabling lock.
      
      This is pretty much a straight text substitution except for a small
      bug fix in winbond.  It currently uses
      netif_stop_queue/spin_unlock_wait to stop transmission.  This is
      unsafe as an IRQ can potentially wake up the queue.  So it is safer to
      use netif_tx_disable.
      
      The hamradio bits used spin_lock_irq but it is unnecessary as
      xmit_lock must never be taken in an IRQ handler.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      932ff279
    • J
      IPoIB: Fix kernel unaligned access on ia64 · 37c22a77
      Jack Morgenstein 提交于
      Fix misaligned access faults on ia64: never cast a misaligned
      neighbour->ha + 4 pointer to union ib_gid type; pass a void * pointer
      instead.  The memcpy was being optimized to use full word accesses
      because the compiler thought that union ib_gid is always aligned.
      
      The cast in IPOIB_GID_ARG is safe, since it is fixed to access each
      byte separately.
      Signed-off-by: NJack Morgenstein <jackm@mellanox.co.il>
      Signed-off-by: NMichael S. Tsirkin <mst@mellanox.co.il>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      37c22a77
  5. 11 4月, 2006 2 次提交
    • E
      IPoIB: Wait for join to finish before freeing mcast struct · f2de3b06
      Eli Cohen 提交于
      ipoib_mcast_restart_task() might free an mcast object while a join
      request is still outstanding, leading to an oops when the query
      completes.  Fix this by waiting for query to complete, similar to what
      ipoib_stop_thread() is doing.  The wait for mcast completion code is
      consolidated in wait_for_mcast_join().
      Signed-off-by: NEli Cohen <eli@mellanox.co.il>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      f2de3b06
    • J
      IB: simplify static rate encoding · bf6a9e31
      Jack Morgenstein 提交于
      Push translation of static rate to HCA format into low-level drivers,
      where it belongs.  For static rate encoding, use encoding of rate
      field from IB standard PathRecord, with addition of value 0, for
      backwards compatibility with current usage.  The changes are:
      
       - Add enum ib_rate to midlayer includes.
       - Get rid of static rate translation in IPoIB; just use static rate
         directly from Path and MulticastGroup records.
       - Update mthca driver to translate absolute static rate into the
         format used by hardware.  This also fixes mthca's static rate
         handling for HCAs that are capable of 4X DDR.
      Signed-off-by: NJack Morgenstein <jackm@mellanox.co.il>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      bf6a9e31
  6. 05 4月, 2006 1 次提交
    • M
      IPoIB: Consolidate private neighbour data handling · d2e0655e
      Michael S. Tsirkin 提交于
      Consolidate IPoIB's private neighbour data handling into
      ipoib_neigh_alloc() and ipoib_neigh_free().  This will make it easier
      to keep track of the neighbour structures that IPoIB is handling, and
      is a nice cleanup of the code:
      
      add/remove: 2/1 grow/shrink: 1/8 up/down: 100/-178 (-78)
      function                                     old     new   delta
      ipoib_neigh_alloc                              -      61     +61
      ipoib_neigh_free                               -      36     +36
      ipoib_mcast_join_finish                     1288    1291      +3
      path_rec_completion                          575     573      -2
      ipoib_mcast_join_task                        664     660      -4
      ipoib_neigh_destructor                       101      92      -9
      ipoib_neigh_setup_dev                         14       3     -11
      ipoib_neigh_setup                             17       -     -17
      path_free                                    238     215     -23
      ipoib_mcast_free                             329     306     -23
      ipoib_mcast_send                             718     684     -34
      neigh_add_path                               705     650     -55
      Signed-off-by: NMichael S. Tsirkin <mst@mellanox.co.il>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      d2e0655e
  7. 21 3月, 2006 4 次提交
  8. 12 2月, 2006 1 次提交
    • R
      IPoIB: Yet another fix for send-only joins · 20b83382
      Roland Dreier 提交于
      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: NRoland Dreier <rolandd@cisco.com>
      20b83382
  9. 08 2月, 2006 2 次提交
  10. 18 1月, 2006 1 次提交
  11. 14 1月, 2006 1 次提交
  12. 13 1月, 2006 1 次提交
  13. 12 1月, 2006 1 次提交
  14. 10 1月, 2006 2 次提交
  15. 04 1月, 2006 1 次提交
  16. 30 11月, 2005 2 次提交
  17. 11 11月, 2005 2 次提交
  18. 03 11月, 2005 1 次提交
  19. 02 11月, 2005 1 次提交
  20. 21 9月, 2005 1 次提交
    • R
      [PATCH] IPoIB: Don't flush workqueue from within workqueue · 8d2cae06
      Roland Dreier 提交于
      ipoib_mcast_restart_task() is always called from within the
      single-threaded IPoIB workqueue, so flushing the workqueue from within
      the function can lead to a recursion overflow.  But since we're
      running in a single-threaded workqueue, we're already synchronized
      against other items in the workqueue, so just get rid of the flush in
      ipoib_mcast_restart_task().
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      8d2cae06
  21. 19 9月, 2005 1 次提交
  22. 27 8月, 2005 2 次提交
  23. 17 4月, 2005 2 次提交
    • R
      [PATCH] IPoIB: fix static rate calculation · e6ded99c
      Roland Dreier 提交于
      Correct and simplify calculation of static rate.  We need to round up the
      quotient of (local_rate - path_rate) / path_rate.  To round up we add
      (path_rate - 1) to the numerator, so the quotient simplifies to (local_rate -
      1) / path_rate.
      
      No idea how I came up with the old formula.
      Signed-off-by: NRoland Dreier <roland@topspin.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e6ded99c
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4