1. 26 4月, 2007 1 次提交
  2. 11 2月, 2007 1 次提交
  3. 09 2月, 2007 1 次提交
    • A
      [NET]: user of the jiffies rounding code: Networking · f5a6e01c
      Arjan van de Ven 提交于
      This patch introduces users of the round_jiffies() function in the
      networking code.
      
      These timers all were of the "about once a second" or "about once
      every X seconds" variety and several showed up in the "what wakes the
      cpu up" profiles that the tickless patches provide.  Some timers are
      highly dynamic based on network load; but even on low activity systems
      they still show up so the rounding is done only in cases of low
      activity, allowing higher frequency timers in the high activity case.
      
      The various hardware watchdogs are an obvious case; they run every 2
      seconds but aren't otherwise specific of exactly when they need to
      run.
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f5a6e01c
  4. 03 12月, 2006 2 次提交
  5. 29 9月, 2006 1 次提交
    • P
      [NET_SCHED]: Fix fallout from dev->qdisc RCU change · 85670cc1
      Patrick McHardy 提交于
      The move of qdisc destruction to a rcu callback broke locking in the
      entire qdisc layer by invalidating previously valid assumptions about
      the context in which changes to the qdisc tree occur.
      
      The two assumptions were:
      
      - since changes only happen in process context, read_lock doesn't need
        bottem half protection. Now invalid since destruction of inner qdiscs,
        classifiers, actions and estimators happens in the RCU callback unless
        they're manually deleted, resulting in dead-locks when read_lock in
        process context is interrupted by write_lock_bh in bottem half context.
      
      - since changes only happen under the RTNL, no additional locking is
        necessary for data not used during packet processing (f.e. u32_list).
        Again, since destruction now happens in the RCU callback, this assumption
        is not valid anymore, causing races while using this data, which can
        result in corruption or use-after-free.
      
      Instead of "fixing" this by disabling bottem halfs everywhere and adding
      new locks/refcounting, this patch makes these assumptions valid again by
      moving destruction back to process context. Since only the dev->qdisc
      pointer is protected by RCU, but ->enqueue and the qdisc tree are still
      protected by dev->qdisc_lock, destruction of the tree can be performed
      immediately and only the final free needs to happen in the rcu callback
      to make sure dev_queue_xmit doesn't access already freed memory.
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      85670cc1
  6. 18 9月, 2006 1 次提交
    • H
      [NET]: Drop tx lock in dev_watchdog_up · d7811e62
      Herbert Xu 提交于
      Fix lockdep warning with GRE, iptables and Speedtouch ADSL, PPP over ATM.
      
      On Sat, Sep 02, 2006 at 08:39:28PM +0000, Krzysztof Halasa wrote:
      > 
      > =======================================================
      > [ INFO: possible circular locking dependency detected ]
      > -------------------------------------------------------
      > swapper/0 is trying to acquire lock:
      >  (&dev->queue_lock){-+..}, at: [<c02c8c46>] dev_queue_xmit+0x56/0x290
      > 
      > but task is already holding lock:
      >  (&dev->_xmit_lock){-+..}, at: [<c02c8e14>] dev_queue_xmit+0x224/0x290
      > 
      > which lock already depends on the new lock.
      
      This turns out to be a genuine bug.  The queue lock and xmit lock are
      intentionally taken out of order.  Two things are supposed to prevent
      dead-locks from occuring:
      
      1) When we hold the queue_lock we're supposed to only do try_lock on the
      tx_lock.
      
      2) We always drop the queue_lock after taking the tx_lock and before doing
      anything else.
      
      > 
      > the existing dependency chain (in reverse order) is:
      > 
      > -> #1 (&dev->_xmit_lock){-+..}:
      >        [<c012e7b6>] lock_acquire+0x76/0xa0
      >        [<c0336241>] _spin_lock_bh+0x31/0x40
      >        [<c02d25a9>] dev_activate+0x69/0x120
      
      This path obviously breaks assumption 1) and therefore can lead to ABBA
      dead-locks.
      
      I've looked at the history and there seems to be no reason for the lock
      to be held at all in dev_watchdog_up.  The lock appeared in day one and
      even there it was unnecessary.  In fact, people added __dev_watchdog_up
      precisely in order to get around the tx lock there.
      
      The function dev_watchdog_up is already serialised by rtnl_lock since
      its only caller dev_activate is always called under it.
      
      So here is a simple patch to remove the tx lock from dev_watchdog_up.
      In 2.6.19 we can eliminate the unnecessary __dev_watchdog_up and
      replace it with dev_watchdog_up.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d7811e62
  7. 22 7月, 2006 1 次提交
  8. 01 7月, 2006 1 次提交
  9. 23 6月, 2006 2 次提交
    • H
      [NET]: Add generic segmentation offload · f6a78bfc
      Herbert Xu 提交于
      This patch adds the infrastructure for generic segmentation offload.
      The idea is to tap into the potential savings of TSO without hardware
      support by postponing the allocation of segmented skb's until just
      before the entry point into the NIC driver.
      
      The same structure can be used to support software IPv6 TSO, as well as
      UFO and segmentation offload for other relevant protocols, e.g., DCCP.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f6a78bfc
    • H
      [NET]: Prevent transmission after dev_deactivate · d4828d85
      Herbert Xu 提交于
      The dev_deactivate function has bit-rotted since the introduction of
      lockless drivers.  In particular, the spin_unlock_wait call at the end
      has no effect on the xmit routine of lockless drivers.
      
      With a little bit of work, we can make it much more useful by providing
      the guarantee that when it returns, no more calls to the xmit routine
      of the underlying driver will be made.
      
      The idea is simple.  There are two entry points in to the xmit routine.
      The first comes from dev_queue_xmit.  That one is easily stopped by
      using synchronize_rcu.  This works because we set the qdisc to noop_qdisc
      before the synchronize_rcu call.  That in turn causes all subsequent
      packets sent to dev_queue_xmit to be dropped.  The synchronize_rcu call
      also ensures all outstanding calls leave their critical section.
      
      The other entry point is from qdisc_run.  Since we now have a bit that
      indicates whether it's running, all we have to do is to wait until the
      bit is off.
      
      I've removed the loop to wait for __LINK_STATE_SCHED to clear.  This is
      useless because netif_wake_queue can cause it to be set again.  It is
      also harmless because we've disarmed qdisc_run.
      
      I've also removed the spin_unlock_wait on xmit_lock because its only
      purpose of making sure that all outstanding xmit_lock holders have
      exited is also given by dev_watchdog_down.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d4828d85
  10. 20 6月, 2006 1 次提交
    • H
      [NET]: Prevent multiple qdisc runs · 48d83325
      Herbert Xu 提交于
      Having two or more qdisc_run's contend against each other is bad because
      it can induce packet reordering if the packets have to be requeued.  It
      appears that this is an unintended consequence of relinquinshing the queue
      lock while transmitting.  That in turn is needed for devices that spend a
      lot of time in their transmit routine.
      
      There are no advantages to be had as devices with queues are inherently
      single-threaded (the loopback device is not but then it doesn't have a
      queue).
      
      Even if you were to add a queue to a parallel virtual device (e.g., bolt
      a tbf filter in front of an ipip tunnel device), you would still want to
      process the queue in sequence to ensure that the packets are ordered
      correctly.
      
      The solution here is to steal a bit from net_device to prevent this.
      
      BTW, as qdisc_restart is no longer used by anyone as a module inside the
      kernel (IIRC it used to with netif_wake_queue), I have not exported the
      new __qdisc_run function.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      48d83325
  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. 17 5月, 2006 1 次提交
  13. 21 3月, 2006 1 次提交
  14. 30 8月, 2005 1 次提交
  15. 24 8月, 2005 1 次提交
    • T
      [PKT_SCHED]: Fix missing qdisc_destroy() in qdisc_create_dflt() · 0fbbeb1b
      Thomas Graf 提交于
      qdisc_create_dflt() is missing to destroy the newly allocated
      default qdisc if the initialization fails resulting in leaks
      of all kinds. The only caller in mainline which may trigger
      this bug is sch_tbf.c in tbf_create_dflt_qdisc().
      
      Note: qdisc_create_dflt() doesn't fulfill the official locking
            requirements of qdisc_destroy() but since the qdisc could
            never be seen by the outside world this doesn't matter
            and it can stay as-is until the locking of pkt_sched
            is cleaned up.
      Signed-off-by: NThomas Graf <tgraf@suug.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0fbbeb1b
  16. 19 7月, 2005 1 次提交
  17. 06 7月, 2005 1 次提交
  18. 19 6月, 2005 4 次提交
  19. 04 5月, 2005 2 次提交
  20. 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