1. 26 Dec, 2004 5 commits
  2. 25 Dec, 2004 1 commit
  3. 24 Dec, 2004 6 commits
  4. 23 Dec, 2004 3 commits
  5. 22 Dec, 2004 8 commits
  6. 21 Dec, 2004 12 commits
  7. 20 Dec, 2004 5 commits
    • Andi Kleen's avatar
      [PATCH] x86_64: fix syscall/signal restart bug · 0233f53f
      Andi Kleen authored
      Fix a pretty bad bug that caused sometimes signals on x86-64
      to be restarted like system calls. This corrupted the RIP and
      in general caused undesirable effects.
      
      The problem happens because orig_rax is unsigned on x86-64,
      but it originally was signed when the signal code was written.
      And the if (orig_rax >= 0) ended up always true.
      And gcc didn't warn about this, because the warning is only in 
      -Wextra. 
      
      In 2.4 we still had a cast for it, but somehow it got dropped
      in 2.5.
      
      Credit goes to John Slice for tracking it down and Erich Boleyn
      for the original fix. All blame to me. I fixed it at another
      place too.
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      0233f53f
    • David S. Miller's avatar
      Merge nuts.davemloft.net:/disk1/BK/network-2.6.11 · 87203e63
      David S. Miller authored
      into nuts.davemloft.net:/disk1/BK/net-2.6.11
      87203e63
    • Thomas Graf's avatar
      [PKT_SCHED]: Provide compat policer stats in action policer · 59b17c27
      Thomas Graf authored
      This should go in before 2.6.10. It fixes a forgotten case to provide
      police backward compatibility statistics for old iproute2 versions
      running on a new kernel with actions enabled. Should make distributions
      happy with older iproute2 versions and all-included kernel configs
      since they probably favour actions over plain policer.
      
      Testing results:
        iproute2-2.4.7 on 2.6.10-rc3-bk8:
        cls-police: police creation succeeded
        cls-police: Sending 10 ICMP echo requests
        cls-police: police dumping succeeded with output:
        filter protocol ip pref 10 u32 
        filter protocol ip pref 10 u32 fh 800: ht divisor 1 
        filter protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 10:12 
        police 3 action drop rate 2Kbit burst 10Kb mtu 2Kb 
          match 00010000/00ff0000 at 8
         Sent 420 bytes 10 pkts (dropped 0, overlimits 0)  <-- This would have been missing
        cls-police: police deletion succeeded
      
       iproute2-2.6.9 on 2.6.10-rc3-bk8:
       ...
        filter protocol ip pref 10 u32 
        filter protocol ip pref 10 u32 fh 800: ht divisor 1 
        filter protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 10:12  (rule hit 10 success 10)
          match 00010000/00ff0000 at 8 (success 10 ) 
         police 0x4 rate 2000bit burst 10Kb mtu 2Kb action drop 
        ref 1 bind 1
         Sent 420 bytes 10 pkts (dropped 0, overlimits 0) 
       ...
      
       (Same results for fw classifier)
      Signed-off-by: default avatarThomas Graf <tgraf@suug.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      59b17c27
    • Stephen Hemminger's avatar
      [TCP]: Efficient port randomization (rev 3) · cceae0d3
      Stephen Hemminger authored
      okay, here is the revised version. Testing shows that it
      is more consistent, and just as fast as existing code,
      probably because of the getting rid of portalloc_lock and
      better distribution.
      Signed-off-by: default avatarStephen Hemminger <shemminger@osdl.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cceae0d3
    • Thomas Graf's avatar
      [PKT_SCHED]: Fix double locking in tcindex destroy path. · ee6fa69b
      Thomas Graf authored
      tcindex's destroy uses its own delete functions to destroy its
      configuration. The delete function (correctly) takes the qdisc_tree_lock
      to prevent list walkings from happening while removing from the list.
      The qdisc_tree_lock is already held if we're comming via the destroy
      path and thus a double locking takes place.
      Signed-off-by: default avatarThomas Graf <tgraf@suug.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ee6fa69b