1. 17 6月, 2008 4 次提交
  2. 15 6月, 2008 1 次提交
  3. 13 6月, 2008 1 次提交
    • D
      tcp: Revert 'process defer accept as established' changes. · ec0a1966
      David S. Miller 提交于
      This reverts two changesets, ec3c0982
      ("[TCP]: TCP_DEFER_ACCEPT updates - process as established") and
      the follow-on bug fix 9ae27e0a
      ("tcp: Fix slab corruption with ipv6 and tcp6fuzz").
      
      This change causes several problems, first reported by Ingo Molnar
      as a distcc-over-loopback regression where connections were getting
      stuck.
      
      Ilpo Järvinen first spotted the locking problems.  The new function
      added by this code, tcp_defer_accept_check(), only has the
      child socket locked, yet it is modifying state of the parent
      listening socket.
      
      Fixing that is non-trivial at best, because we can't simply just grab
      the parent listening socket lock at this point, because it would
      create an ABBA deadlock.  The normal ordering is parent listening
      socket --> child socket, but this code path would require the
      reverse lock ordering.
      
      Next is a problem noticed by Vitaliy Gusev, he noted:
      
      ----------------------------------------
      >--- a/net/ipv4/tcp_timer.c
      >+++ b/net/ipv4/tcp_timer.c
      >@@ -481,6 +481,11 @@ static void tcp_keepalive_timer (unsigned long data)
      > 		goto death;
      > 	}
      >
      >+	if (tp->defer_tcp_accept.request && sk->sk_state == TCP_ESTABLISHED) {
      >+		tcp_send_active_reset(sk, GFP_ATOMIC);
      >+		goto death;
      
      Here socket sk is not attached to listening socket's request queue. tcp_done()
      will not call inet_csk_destroy_sock() (and tcp_v4_destroy_sock() which should
      release this sk) as socket is not DEAD. Therefore socket sk will be lost for
      freeing.
      ----------------------------------------
      
      Finally, Alexey Kuznetsov argues that there might not even be any
      real value or advantage to these new semantics even if we fix all
      of the bugs:
      
      ----------------------------------------
      Hiding from accept() sockets with only out-of-order data only
      is the only thing which is impossible with old approach. Is this really
      so valuable? My opinion: no, this is nothing but a new loophole
      to consume memory without control.
      ----------------------------------------
      
      So revert this thing for now.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ec0a1966
  4. 12 6月, 2008 5 次提交
  5. 11 6月, 2008 3 次提交
  6. 10 6月, 2008 4 次提交
  7. 06 6月, 2008 1 次提交
  8. 05 6月, 2008 7 次提交
    • O
      tcp: Fix for race due to temporary drop of the socket lock in skb_splice_bits. · 293ad604
      Octavian Purdila 提交于
      skb_splice_bits temporary drops the socket lock while iterating over
      the socket queue in order to break a reverse locking condition which
      happens with sendfile. This, however, opens a window of opportunity
      for tcp_collapse() to aggregate skbs and thus potentially free the
      current skb used in skb_splice_bits and tcp_read_sock.
      
      This patch fixes the problem by (re-)getting the same "logical skb"
      after the lock has been temporary dropped.
      
      Based on idea and initial patch from Evgeniy Polyakov.
      Signed-off-by: NOctavian Purdila <opurdila@ixiacom.com>
      Acked-by: NEvgeniy Polyakov <johnpol@2ka.mipt.ru>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      293ad604
    • S
      tcp: Increment OUTRSTS in tcp_send_active_reset() · 26af65cb
      Sridhar Samudrala 提交于
      TCP "resets sent" counter is not incremented when a TCP Reset is 
      sent via tcp_send_active_reset().
      Signed-off-by: NSridhar Samudrala <sri@us.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      26af65cb
    • D
      raw: Raw socket leak. · 22dd4850
      Denis V. Lunev 提交于
      The program below just leaks the raw kernel socket
      
      int main() {
              int fd = socket(PF_INET, SOCK_RAW, IPPROTO_UDP);
              struct sockaddr_in addr;
      
              memset(&addr, 0, sizeof(addr));
              inet_aton("127.0.0.1", &addr.sin_addr);
              addr.sin_family = AF_INET;
              addr.sin_port = htons(2048);
              sendto(fd,  "a", 1, MSG_MORE, &addr, sizeof(addr));
              return 0;
      }
      
      Corked packet is allocated via sock_wmalloc which holds the owner socket,
      so one should uncork it and flush all pending data on close. Do this in the
      same way as in UDP.
      Signed-off-by: NDenis V. Lunev <den@openvz.org>
      Acked-by: NAlexey Kuznetsov <kuznet@ms2.inr.ac.ru>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      22dd4850
    • I
      tcp: fix skb vs fack_count out-of-sync condition · a6604471
      Ilpo Järvinen 提交于
      This bug is able to corrupt fackets_out in very rare cases.
      In order for this to cause corruption:
        1) DSACK in the middle of previous SACK block must be generated.
        2) In order to take that particular branch, part or all of the
           DSACKed segment must already be SACKed so that we have that
           in cache in the first place.
        3) The new info must be top enough so that fackets_out will be
           updated on this iteration.
      ...then fack_count is updated while skb wasn't, then we walk again
      that particular segment thus updating fack_count twice for
      a single skb and finally that value is assigned to fackets_out
      by tcp_sacktag_one.
      
      It is safe to call tcp_sacktag_one just once for a segment (at
      DSACK), no need to call again for plain SACK.
      
      Potential problem of the miscount are limited to premature entry
      to recovery and to inflated reordering metric (which could even
      cancel each other out in the most the luckiest scenarios :-)).
      Both are quite insignificant in worst case too and there exists
      also code to reset them (fackets_out once sacked_out becomes zero
      and reordering metric on RTO).
      
      This has been reported by a number of people, because it occurred
      quite rarely, it has been very evasive. Andy Furniss was able to
      get it to occur couple of times so that a bit more info was
      collected about the problem using a debug patch, though it still
      required lot of checking around. Thanks also to others who have
      tried to help here.
      
      This is listed as Bugzilla #10346. The bug was introduced by
      me in commit 68f8353b ([TCP]: Rewrite SACK block processing & 
      sack_recv_cache use), I probably thought back then that there's
      need to scan that entry twice or didn't dare to make it go
      through it just once there. Going through twice would have
      required restoring fack_count after the walk but as noted above,
      I chose to drop the additional walk step altogether here.
      Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a6604471
    • D
      [IPV6]: inet_sk(sk)->cork.opt leak · 36d926b9
      Denis V. Lunev 提交于
      IPv6 UDP sockets wth IPv4 mapped address use udp_sendmsg to send the data
      actually. In this case ip_flush_pending_frames should be called instead
      of ip6_flush_pending_frames.
      Signed-off-by: NDenis V. Lunev <den@openvz.org>
      Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      36d926b9
    • Y
    • I
      tcp: Fix inconsistency source (CA_Open only when !tcp_left_out(tp)) · 8aca6cb1
      Ilpo Järvinen 提交于
      It is possible that this skip path causes TCP to end up into an
      invalid state where ca_state was left to CA_Open while some
      segments already came into sacked_out. If next valid ACK doesn't
      contain new SACK information TCP fails to enter into
      tcp_fastretrans_alert(). Thus at least high_seq is set
      incorrectly to a too high seqno because some new data segments
      could be sent in between (and also, limited transmit is not
      being correctly invoked there). Reordering in both directions
      can easily cause this situation to occur.
      
      I guess we would want to use tcp_moderate_cwnd(tp) there as well
      as it may be possible to use this to trigger oversized burst to
      network by sending an old ACK with huge amount of SACK info, but
      I'm a bit unsure about its effects (mainly to FlightSize), so to
      be on the safe side I just currently fixed it minimally to keep
      TCP's state consistent (obviously, such nasty ACKs have been
      possible this far). Though it seems that FlightSize is already
      underestimated by some amount, so probably on the long term we
      might want to trigger recovery there too, if appropriate, to make
      FlightSize calculation to resemble reality at the time when the
      losses where discovered (but such change scares me too much now
      and requires some more thinking anyway how to do that as it
      likely involves some code shuffling).
      
      This bug was found by Brian Vowell while running my TCP debug
      patch to find cause of another TCP issue (fackets_out
      miscount).
      Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8aca6cb1
  9. 04 6月, 2008 3 次提交
  10. 22 5月, 2008 7 次提交
  11. 21 5月, 2008 1 次提交
    • H
      ipsec: Use the correct ip_local_out function · 1ac06e03
      Herbert Xu 提交于
      Because the IPsec output function xfrm_output_resume does its
      own dst_output call it should always call __ip_local_output
      instead of ip_local_output as the latter may invoke dst_output
      directly.  Otherwise the return values from nf_hook and dst_output
      may clash as they both use the value 1 but for different purposes.
      
      When that clash occurs this can cause a packet to be used after
      it has been freed which usually leads to a crash.  Because the
      offending value is only returned from dst_output with qdiscs
      such as HTB, this bug is normally not visible.
      
      Thanks to Marco Berizzi for his perseverance in tracking this
      down.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1ac06e03
  12. 20 5月, 2008 2 次提交
  13. 14 5月, 2008 1 次提交