1. 23 5月, 2006 1 次提交
  2. 19 5月, 2006 4 次提交
  3. 17 5月, 2006 1 次提交
    • A
      [TCP]: reno sacked_out count fix · 8872d8e1
      Angelo P. Castellani 提交于
      From: "Angelo P. Castellani" <angelo.castellani+lkml@gmail.com>
      
      Using NewReno, if a sk_buff is timed out and is accounted as lost_out,
      it should also be removed from the sacked_out.
      
      This is necessary because recovery using NewReno fast retransmit could
      take up to a lot RTTs and the sk_buff RTO can expire without actually
      being really lost.
      
      left_out = sacked_out + lost_out
      in_flight = packets_out - left_out + retrans_out
      
      Using NewReno without this patch, on very large network losses,
      left_out becames bigger than packets_out + retrans_out (!!).
      
      For this reason unsigned integer in_flight overflows to 2^32 - something.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8872d8e1
  4. 10 5月, 2006 1 次提交
  5. 07 5月, 2006 1 次提交
  6. 06 5月, 2006 1 次提交
    • J
      [TCP]: Fix snd_cwnd adjustments in tcp_highspeed.c · 5528e568
      John Heffner 提交于
      Xiaoliang (David) Wei wrote:
      > Hi gurus,
      > 
      >    I am reading the code of tcp_highspeed.c in the kernel and have a
      > question on the hstcp_cong_avoid function, specifically the following
      > AI part (line 136~143 in net/ipv4/tcp_highspeed.c ):
      > 
      >                /* Do additive increase */
      >                if (tp->snd_cwnd < tp->snd_cwnd_clamp) {
      >                        tp->snd_cwnd_cnt += ca->ai;
      >                        if (tp->snd_cwnd_cnt >= tp->snd_cwnd) {
      >                                tp->snd_cwnd++;
      >                                tp->snd_cwnd_cnt -= tp->snd_cwnd;
      >                        }
      >                }
      > 
      >    In this part, when (tp->snd_cwnd_cnt == tp->snd_cwnd),
      > snd_cwnd_cnt will be -1... snd_cwnd_cnt is defined as u16, will this
      > small chance of getting -1 becomes a problem?
      > Shall we change it by reversing the order of the cwnd++ and cwnd_cnt -= 
      > cwnd?
      
      Absolutely correct.  Thanks.
      Signed-off-by: NJohn Heffner <jheffner@psc.edu>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5528e568
  7. 04 5月, 2006 6 次提交
    • H
      [TCP]: Fix sock_orphan dead lock · 75c2d907
      Herbert Xu 提交于
      Calling sock_orphan inside bh_lock_sock in tcp_close can lead to dead
      locks.  For example, the inet_diag code holds sk_callback_lock without
      disabling BH.  If an inbound packet arrives during that admittedly tiny
      window, it will cause a dead lock on bh_lock_sock.  Another possible
      path would be through sock_wfree if the network device driver frees the
      tx skb in process context with BH enabled.
      
      We can fix this by moving sock_orphan out of bh_lock_sock.
      
      The tricky bit is to work out when we need to destroy the socket
      ourselves and when it has already been destroyed by someone else.
      
      By moving sock_orphan before the release_sock we can solve this
      problem.  This is because as long as we own the socket lock its
      state cannot change.
      
      So we simply record the socket state before the release_sock
      and then check the state again after we regain the socket lock.
      If the socket state has transitioned to TCP_CLOSE in the time being,
      we know that the socket has been destroyed.  Otherwise the socket is
      still ours to keep.
      
      Note that I've also moved the increment on the orphan count forward.
      This may look like a problem as we're increasing it even if the socket
      is just about to be destroyed where it'll be decreased again.  However,
      this simply enlarges a window that already exists.  This also changes
      the orphan count test by one.
      
      Considering what the orphan count is meant to do this is no big deal.
      
      This problem was discoverd by Ingo Molnar using his lock validator.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      75c2d907
    • P
      [NETFILTER]: x_tables: don't use __copy_{from,to}_user on unchecked memory in compat layer · 7800007c
      Patrick McHardy 提交于
      Noticed by Linus Torvalds <torvalds@osdl.org>
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7800007c
    • J
    • P
      [NETFILTER]: NAT: silence unused variable warnings with CONFIG_XFRM=n · 2354feae
      Patrick McHardy 提交于
      net/ipv4/netfilter/ip_nat_standalone.c: In function 'ip_nat_out':
      net/ipv4/netfilter/ip_nat_standalone.c:223: warning: unused variable 'ctinfo'
      net/ipv4/netfilter/ip_nat_standalone.c:222: warning: unused variable 'ct'
      
      Surprisingly no complaints so far ..
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2354feae
    • P
      [NETFILTER]: H.323 helper: fix use of uninitialized data · 4228e2a9
      Patrick McHardy 提交于
      When a Choice element contains an unsupported choice no error is returned
      and parsing continues normally, but the choice value is not set and
      contains data from the last parsed message. This may in turn lead to
      parsing of more stale data and following crashes.
      
      Fixes a crash triggered by testcase 0003243 from the PROTOS c07-h2250v4
      testsuite following random other testcases:
      
      CPU:    0
      EIP:    0060:[<c01a9554>]    Not tainted VLI
      EFLAGS: 00210646   (2.6.17-rc2 #3)
      EIP is at memmove+0x19/0x22
      eax: d7be0307   ebx: d7be0307   ecx: e841fcf9   edx: d7be0307
      esi: bfffffff   edi: bfffffff   ebp: da5eb980   esp: c0347e2c
      ds: 007b   es: 007b   ss: 0068
      Process events/0 (pid: 4, threadinfo=c0347000 task=dff86a90)
      Stack: <0>00000006 c0347ea6 d7be0301 e09a6b2c 00000006 da5eb980 d7be003e d7be0052
             c0347f6c e09a6d9c 00000006 c0347ea6 00000006 00000000 d7b9a548 00000000
             c0347f6c d7b9a548 00000004 e0a1a119 0000028f 00000006 c0347ea6 00000006
      Call Trace:
       [<e09a6b2c>] mangle_contents+0x40/0xd8 [ip_nat]
       [<e09a6d9c>] ip_nat_mangle_tcp_packet+0xa1/0x191 [ip_nat]
       [<e0a1a119>] set_addr+0x60/0x14d [ip_nat_h323]
       [<e0ab6e66>] q931_help+0x2da/0x71a [ip_conntrack_h323]
       [<e0ab6e98>] q931_help+0x30c/0x71a [ip_conntrack_h323]
       [<e09af242>] ip_conntrack_help+0x22/0x2f [ip_conntrack]
       [<c022934a>] nf_iterate+0x2e/0x5f
       [<c025d357>] xfrm4_output_finish+0x0/0x39f
       [<c02294ce>] nf_hook_slow+0x42/0xb0
       [<c025d357>] xfrm4_output_finish+0x0/0x39f
       [<c025d732>] xfrm4_output+0x3c/0x4e
       [<c025d357>] xfrm4_output_finish+0x0/0x39f
       [<c0230370>] ip_forward+0x1c2/0x1fa
       [<c022f417>] ip_rcv+0x388/0x3b5
       [<c02188f9>] netif_receive_skb+0x2bc/0x2ec
       [<c0218994>] process_backlog+0x6b/0xd0
       [<c021675a>] net_rx_action+0x4b/0xb7
       [<c0115606>] __do_softirq+0x35/0x7d
       [<c0104294>] do_softirq+0x38/0x3f
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4228e2a9
    • P
      [NETFILTER]: H.323 helper: fix endless loop caused by invalid TPKT len · 6fd73703
      Patrick McHardy 提交于
      When the TPKT len included in the packet is below the lowest valid value
      of 4 an underflow occurs which results in an endless loop.
      
      Found by testcase 0000058 from the PROTOS c07-h2250v4 testsuite.
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6fd73703
  8. 03 5月, 2006 1 次提交
  9. 02 5月, 2006 1 次提交
    • P
      [NETFILTER] x_tables: fix compat related crash on non-x86 · 46c5ea3c
      Patrick McHardy 提交于
      When iptables userspace adds an ipt_standard_target, it calculates the size
      of the entire entry as:
      
      sizeof(struct ipt_entry) + XT_ALIGN(sizeof(struct ipt_standard_target))
      
      ipt_standard_target looks like this:
      
        struct xt_standard_target
        {
              struct xt_entry_target target;
              int verdict;
        };
      
      xt_entry_target contains a pointer, so when compiled for 64 bit the
      structure gets an extra 4 byte of padding at the end. On 32 bit
      architectures where iptables aligns to 8 byte it will also have 4
      byte padding at the end because it is only 36 bytes large.
      
      The compat_ipt_standard_fn in the kernel adjusts the offsets by
      
        sizeof(struct ipt_standard_target) - sizeof(struct compat_ipt_standard_target),
      
      which will always result in 4, even if the structure from userspace
      was already padded to a multiple of 8. On x86 this works out by
      accident because userspace only aligns to 4, on all other
      architectures this is broken and causes incorrect adjustments to
      the size and following offsets.
      
      Thanks to Linus for lots of debugging help and testing.
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      46c5ea3c
  10. 30 4月, 2006 3 次提交
  11. 25 4月, 2006 1 次提交
  12. 20 4月, 2006 1 次提交
  13. 19 4月, 2006 2 次提交
  14. 18 4月, 2006 1 次提交
  15. 15 4月, 2006 2 次提交
  16. 11 4月, 2006 1 次提交
  17. 10 4月, 2006 12 次提交