1. 26 4月, 2007 11 次提交
  2. 13 4月, 2007 1 次提交
  3. 13 2月, 2007 1 次提交
  4. 11 2月, 2007 1 次提交
  5. 04 1月, 2007 1 次提交
  6. 03 12月, 2006 1 次提交
  7. 06 11月, 2006 1 次提交
  8. 29 9月, 2006 2 次提交
  9. 23 9月, 2006 1 次提交
  10. 08 8月, 2006 2 次提交
  11. 18 6月, 2006 1 次提交
    • 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
  12. 23 3月, 2006 1 次提交
  13. 21 3月, 2006 10 次提交
  14. 19 1月, 2006 1 次提交
  15. 18 1月, 2006 1 次提交
  16. 12 1月, 2006 1 次提交
  17. 07 1月, 2006 1 次提交
  18. 04 1月, 2006 1 次提交
    • J
      [PKTGEN]: Deinitialise static variables. · f34fbb97
      Jaco Kroon 提交于
      static variables should not be explicitly initialised to 0.  This causes
      them to be placed in .data instead of .bss.  This patch de-initialises 3
      static variables in net/core/pktgen.c.
      
      There are approximately 800 more such variables in the source tree
      (2.6.15rc5).  If there is more interrest I'd be willing to track down the
      rest of these as well and de-initialise them as well.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f34fbb97
  19. 26 10月, 2005 1 次提交