Skip to content

L
linux
Switch branch/tag
  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
  3. 31 Oct, 2007 36 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7