1. 01 Nov, 2007 4 commits
    • Pavel Emelyanov's avatar
      [NET]: Move the get_net() from sock_copy() · 1e2e6b89
      Pavel Emelyanov authored
      The sock_copy() is supposed to just clone the socket. In a perfect
      world it has to be just memcpy, but we have to handle the security
      mark correctly. All the extra setup must be performed in sk_clone() 
      call, so move the get_net() into more proper place.
      Signed-off-by: default avatarPavel Emelyanov <xemul@openvz.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1e2e6b89
    • Pavel Emelyanov's avatar
      [NET]: Move the sock_copy() from the header · f1a6c4da
      Pavel Emelyanov authored
      The sock_copy() call is not used outside the sock.c file,
      so just move it into a sock.c
      Signed-off-by: default avatarPavel Emelyanov <xemul@openvz.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f1a6c4da
    • Ilpo Jrvinen's avatar
      [TCP]: Another TAGBITS -> SACKED_ACKED|LOST conversion · 261ab365
      Ilpo Jrvinen authored
      Similar to commit 3eec0047, point of this is to avoid
      skipping R-bit skbs.
      Signed-off-by: default avatarIlpo Jrvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      261ab365
    • Ilpo Jrvinen's avatar
      [TCP]: Process DSACKs that reside within a SACK block · e56d6cd6
      Ilpo Jrvinen authored
      DSACK inside another SACK block were missed if start_seq of DSACK
      was larger than SACK block's because sorting prioritizes full
      processing of the SACK block before DSACK. After SACK block
      sorting situation is like this:
      
                   SSSSSSSSS
                        D
                              SSSSSS
                                     SSSSSSS
      
      Because write_queue is walked in-order, when the first SACK block
      has been processed, TCP is already past the skb for which the
      DSACK arrived and we haven't taught it to backtrack (nor should
      we), so TCP just continues processing by going to the next SACK
      block after the DSACK (if any).
      
      Whenever such DSACK is present, do an embedded checking during
      the previous SACK block.
      
      If the DSACK is below snd_una, there won't be overlapping SACK
      block, and thus no problem in that case. Also if start_seq of
      the DSACK is equal to the actual block, it will be processed
      first.
      
      Tested this by using netem to duplicate 15% of packets, and
      by printing SACK block when found_dup_sack is true and the 
      selected skb in the dup_sack = 1 branch (if taken):
      
        SACK block 0: 4344-5792 (relative to snd_una 2019137317)
        SACK block 1: 4344-5792 (relative to snd_una 2019137317) 
      
      equal start seqnos => next_dup = 0, dup_sack = 1 won't occur...
      
        SACK block 0: 5792-7240 (relative to snd_una 2019214061)
        SACK block 1: 2896-7240 (relative to snd_una 2019214061)
        DSACK skb match 5792-7240 (relative to snd_una)
      
      ...and next_dup = 1 case (after the not shown start_seq sort),
      went to dup_sack = 1 branch.
      Signed-off-by: default avatarIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e56d6cd6
  2. 31 Oct, 2007 36 commits