1. 07 4月, 2010 3 次提交
  2. 04 4月, 2010 9 次提交
  3. 03 4月, 2010 1 次提交
  4. 02 4月, 2010 2 次提交
    • Y
      ipv6 fib: Make rt6_info{} more cache-line aware. · bd2c77a0
      YOSHIFUJI Hideaki / 吉藤英明 提交于
      The head element of rt6_info{} is dst_entry{}, and
      IPv6 specific elements follow.
      
      Because elements at the end of dst_entry{} are frequently
      updated, it is not good to put frequently-used static
      elements, such as rt6i_idev, rt6i_dst or rt6i_flags in the
      same cache line.
      
      On the other hand, fib6_table, rt6i_node or rt6i_gateway are
      rarely used, so it is okay to stay in the same cache line.
      
      Let's rearrange rt6_info{}.
      Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bd2c77a0
    • E
      gen_estimator: deadlock fix · 5d944c64
      Eric Dumazet 提交于
      One of my test machine got a deadlock during "tc" sessions,
      adding/deleting classes & filters, using traffic estimators.
      
      After some analysis, I believe we have a potential use after free case
      in est_timer() :
      
      spin_lock(e->stats_lock); << HERE >>
      read_lock(&est_lock);
      if (e->bstats == NULL)   << TEST >>
      	goto skip;
      
      Test is done a bit late, because after estimator is killed, and before
      rcu grace period elapsed, we might already have freed/reuse memory where
      e->stats_locks points to (some qdisc->q.lock)
      
      A possible fix is to respect a rcu grace period at Qdisc dismantle time.
      
      On 64bit, sizeof(struct Qdisc) is exactly 192 bytes. Adding 16 bytes to
      it (for struct rcu_head) is a problem because it might change
      performance, given QDISC_ALIGNTO is 32 bytes.
      
      This is why I also change QDISC_ALIGNTO to 64 bytes, to satisfy most
      current alignment requirements.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5d944c64
  5. 31 3月, 2010 8 次提交
  6. 28 3月, 2010 1 次提交
  7. 27 3月, 2010 1 次提交
  8. 26 3月, 2010 1 次提交
  9. 25 3月, 2010 5 次提交
  10. 24 3月, 2010 3 次提交
  11. 23 3月, 2010 1 次提交
  12. 22 3月, 2010 5 次提交