1. 03 12月, 2006 9 次提交
  2. 08 11月, 2006 1 次提交
  3. 20 10月, 2006 1 次提交
  4. 23 9月, 2006 1 次提交
  5. 26 6月, 2006 2 次提交
  6. 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
  7. 21 3月, 2006 1 次提交
  8. 18 1月, 2006 1 次提交
  9. 04 1月, 2006 1 次提交
  10. 11 11月, 2005 1 次提交
    • H
      [NET]: Detect hardware rx checksum faults correctly · fb286bb2
      Herbert Xu 提交于
      Here is the patch that introduces the generic skb_checksum_complete
      which also checks for hardware RX checksum faults.  If that happens,
      it'll call netdev_rx_csum_fault which currently prints out a stack
      trace with the device name.  In future it can turn off RX checksum.
      
      I've converted every spot under net/ that does RX checksum checks to
      use skb_checksum_complete or __skb_checksum_complete with the
      exceptions of:
      
      * Those places where checksums are done bit by bit.  These will call
      netdev_rx_csum_fault directly.
      
      * The following have not been completely checked/converted:
      
      ipmr
      ip_vs
      netfilter
      dccp
      
      This patch is based on patches and suggestions from Stephen Hemminger
      and David S. Miller.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fb286bb2
  11. 04 10月, 2005 1 次提交
    • H
      [IPV4]: Replace __in_dev_get with __in_dev_get_rcu/rtnl · e5ed6399
      Herbert Xu 提交于
      The following patch renames __in_dev_get() to __in_dev_get_rtnl() and
      introduces __in_dev_get_rcu() to cover the second case.
      
      1) RCU with refcnt should use in_dev_get().
      2) RCU without refcnt should use __in_dev_get_rcu().
      3) All others must hold RTNL and use __in_dev_get_rtnl().
      
      There is one exception in net/ipv4/route.c which is in fact a pre-existing
      race condition.  I've marked it as such so that we remember to fix it.
      
      This patch is based on suggestions and prior work by Suzanne Wood and
      Paul McKenney.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e5ed6399
  12. 10 9月, 2005 1 次提交
  13. 12 8月, 2005 7 次提交
  14. 23 6月, 2005 2 次提交
    • J
      [NETPOLL]: allow multiple netpoll_clients to register against one interface · fbeec2e1
      Jeff Moyer 提交于
      This patch provides support for registering multiple netpoll clients to the
      same network device.  Only one of these clients may register an rx_hook,
      however.  In practice, this restriction has not been problematic.  It is
      worth mentioning, though, that the current design can be easily extended to
      allow for the registration of multiple rx_hooks.
      
      The basic idea of the patch is that the rx_np pointer in the netpoll_info
      structure points to the struct netpoll that has rx_hook filled in.  Aside
      from this one case, there is no need for a pointer from the struct
      net_device to an individual struct netpoll.
      
      A lock is introduced to protect the setting and clearing of the np_rx
      pointer.  The pointer will only be cleared upon netpoll client module
      removal, and the lock should be uncontested.
      Signed-off-by: NJeff Moyer <jmoyer@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fbeec2e1
    • J
      [NETPOLL]: Introduce a netpoll_info struct · 115c1d6e
      Jeff Moyer 提交于
      This patch introduces a netpoll_info structure, which the struct net_device
      will now point to instead of pointing to a struct netpoll.  The reason for
      this is two-fold: 1) fields such as the rx_flags, poll_owner, and poll_lock
      should be maintained per net_device, not per netpoll;  and 2) this is a first
      step in providing support for multiple netpoll clients to register against the
      same net_device.
      
      The struct netpoll is now pointed to by the netpoll_info structure.  As
      such, the previous behaviour of the code is preserved.
      Signed-off-by: NJeff Moyer <jmoyer@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      115c1d6e
  15. 17 4月, 2005 1 次提交
    • 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