1. 26 1月, 2011 2 次提交
    • J
      TCP: fix a bug that triggers large number of TCP RST by mistake · 44f5324b
      Jerry Chu 提交于
      This patch fixes a bug that causes TCP RST packets to be generated
      on otherwise correctly behaved applications, e.g., no unread data
      on close,..., etc. To trigger the bug, at least two conditions must
      be met:
      
      1. The FIN flag is set on the last data packet, i.e., it's not on a
      separate, FIN only packet.
      2. The size of the last data chunk on the receive side matches
      exactly with the size of buffer posted by the receiver, and the
      receiver closes the socket without any further read attempt.
      
      This bug was first noticed on our netperf based testbed for our IW10
      proposal to IETF where a large number of RST packets were observed.
      netperf's read side code meets the condition 2 above 100%.
      
      Before the fix, tcp_data_queue() will queue the last skb that meets
      condition 1 to sk_receive_queue even though it has fully copied out
      (skb_copy_datagram_iovec()) the data. Then if condition 2 is also met,
      tcp_recvmsg() often returns all the copied out data successfully
      without actually consuming the skb, due to a check
      "if ((chunk = len - tp->ucopy.len) != 0) {"
      and
      "len -= chunk;"
      after tcp_prequeue_process() that causes "len" to become 0 and an
      early exit from the big while loop.
      
      I don't see any reason not to free the skb whose data have been fully
      consumed in tcp_data_queue(), regardless of the FIN flag.  We won't
      get there if MSG_PEEK is on. Am I missing some arcane cases related
      to urgent data?
      Signed-off-by: NH.K. Jerry Chu <hkchu@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      44f5324b
    • D
      ipv6: Revert 'administrative down' address handling changes. · 73a8bd74
      David S. Miller 提交于
      This reverts the following set of commits:
      
      d1ed113f ("ipv6: remove duplicate neigh_ifdown")
      29ba5fed ("ipv6: don't flush routes when setting loopback down")
      9d82ca98 ("ipv6: fix missing in6_ifa_put in addrconf")
      2de79570 ("ipv6: addrconf: don't remove address state on ifdown if the address is being kept")
      8595805a ("IPv6: only notify protocols if address is compeletely gone")
      27bdb2ab ("IPv6: keep tentative addresses in hash table")
      93fa159a ("IPv6: keep route for tentative address")
      8f37ada5 ("IPv6: fix race between cleanup and add/delete address")
      84e8b803 ("IPv6: addrconf notify when address is unavailable")
      dc2b99f7 ("IPv6: keep permanent addresses on admin down")
      
      because the core semantic change to ipv6 address handling on ifdown
      has broken some things, in particular "disable_ipv6" sysctl handling.
      
      Stephen has made several attempts to get things back in working order,
      but nothing has restored disable_ipv6 fully yet.
      Reported-by: NEric W. Biederman <ebiederm@xmission.com>
      Tested-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      73a8bd74
  2. 25 1月, 2011 19 次提交
  3. 24 1月, 2011 19 次提交