1. 03 12月, 2006 1 次提交
  2. 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
  3. 01 7月, 2006 1 次提交
  4. 30 8月, 2005 1 次提交
  5. 29 6月, 2005 1 次提交
  6. 19 6月, 2005 1 次提交
  7. 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