1. 16 9月, 2009 1 次提交
    • R
      tcp: fix CONFIG_TCP_MD5SIG + CONFIG_PREEMPT timer BUG() · 657e9649
      Robert Varga 提交于
      I have recently came across a preemption imbalance detected by:
      
      <4>huh, entered ffffffff80644630 with preempt_count 00000102, exited with 00000101?
      <0>------------[ cut here ]------------
      <2>kernel BUG at /usr/src/linux/kernel/timer.c:664!
      <0>invalid opcode: 0000 [1] PREEMPT SMP
      
      with ffffffff80644630 being inet_twdr_hangman().
      
      This appeared after I enabled CONFIG_TCP_MD5SIG and played with it a
      bit, so I looked at what might have caused it.
      
      One thing that struck me as strange is tcp_twsk_destructor(), as it
      calls tcp_put_md5sig_pool() -- which entails a put_cpu(), causing the
      detected imbalance. Found on 2.6.23.9, but 2.6.31 is affected as well,
      as far as I can tell.
      Signed-off-by: NRobert Varga <nite@hq.alert.sk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      657e9649
  2. 15 9月, 2009 1 次提交
  3. 03 9月, 2009 1 次提交
    • W
      tcp: replace hard coded GFP_KERNEL with sk_allocation · aa133076
      Wu Fengguang 提交于
      This fixed a lockdep warning which appeared when doing stress
      memory tests over NFS:
      
      	inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage.
      
      	page reclaim => nfs_writepage => tcp_sendmsg => lock sk_lock
      
      	mount_root => nfs_root_data => tcp_close => lock sk_lock =>
      			tcp_send_fin => alloc_skb_fclone => page reclaim
      
      David raised a concern that if the allocation fails in tcp_send_fin(), and it's
      GFP_ATOMIC, we are going to yield() (which sleeps) and loop endlessly waiting
      for the allocation to succeed.
      
      But fact is, the original GFP_KERNEL also sleeps. GFP_ATOMIC+yield() looks
      weird, but it is no worse the implicit sleep inside GFP_KERNEL. Both could
      loop endlessly under memory pressure.
      
      CC: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
      CC: David S. Miller <davem@davemloft.net>
      CC: Herbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      aa133076
  4. 29 8月, 2009 1 次提交
  5. 26 6月, 2009 1 次提交
    • W
      tcp: missing check ACK flag of received segment in FIN-WAIT-2 state · 1ac530b3
      Wei Yongjun 提交于
      RFC0793 defined that in FIN-WAIT-2 state if the ACK bit is off drop
      the segment and return[Page 72]. But this check is missing in function
      tcp_timewait_state_process(). This cause the segment with FIN flag but
      no ACK has two diffent action:
      
      Case 1:
          Node A                      Node B
                    <-------------    FIN,ACK
                                      (enter FIN-WAIT-1)
          ACK       ------------->
                                      (enter FIN-WAIT-2)
          FIN       ------------->    discard
                                      (move sk to tw list)
      
      Case 2:
          Node A                      Node B
                    <-------------    FIN,ACK
                                      (enter FIN-WAIT-1)
          ACK       ------------->
                                      (enter FIN-WAIT-2)
                                      (move sk to tw list)
          FIN       ------------->
      
                    <-------------    ACK
      
      This patch fixed the problem.
      Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1ac530b3
  6. 16 3月, 2009 1 次提交
    • I
      tcp: consolidate paws check · c887e6d2
      Ilpo Järvinen 提交于
      Wow, it was quite tricky to merge that stream of negations
      but I think I finally got it right:
      
      check & replace_ts_recent:
      (s32)(rcv_tsval - ts_recent) >= 0                  => 0
      (s32)(ts_recent - rcv_tsval) <= 0                  => 0
      
      discard:
      (s32)(ts_recent - rcv_tsval)  > TCP_PAWS_WINDOW    => 1
      (s32)(ts_recent - rcv_tsval) <= TCP_PAWS_WINDOW    => 0
      
      I toggled the return values of tcp_paws_check around since
      the old encoding added yet-another negation making tracking
      of truth-values really complicated.
      Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c887e6d2
  7. 03 3月, 2009 1 次提交
  8. 02 3月, 2009 1 次提交
  9. 03 11月, 2008 1 次提交
  10. 08 10月, 2008 1 次提交
    • I
      tcp: kill pointless urg_mode · 33f5f57e
      Ilpo Järvinen 提交于
      It all started from me noticing that this urgent check in
      tcp_clean_rtx_queue is unnecessarily inside the loop. Then
      I took a longer look to it and found out that the users of
      urg_mode can trivially do without, well almost, there was
      one gotcha.
      
      Bonus: those funny people who use urg with >= 2^31 write_seq -
      snd_una could now rejoice too (that's the only purpose for the
      between being there, otherwise a simple compare would have done
      the thing). Not that I assume that the rest of the tcp code
      happily lives with such mind-boggling numbers :-). Alas, it
      turned out to be impossible to set wmem to such numbers anyway,
      yes I really tried a big sendfile after setting some wmem but
      nothing happened :-). ...Tcp_wmem is int and so is sk_sndbuf...
      So I hacked a bit variable to long and found out that it seems
      to work... :-)
      Signed-off-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      33f5f57e
  11. 08 8月, 2008 1 次提交
  12. 07 8月, 2008 1 次提交
    • G
      tcp: Fix kernel panic when calling tcp_v(4/6)_md5_do_lookup · 6edafaaf
      Gui Jianfeng 提交于
      If the following packet flow happen, kernel will panic.
      MathineA			MathineB
      		SYN
      	---------------------->    
              	SYN+ACK
      	<----------------------
      		ACK(bad seq)
      	---------------------->
      When a bad seq ACK is received, tcp_v4_md5_do_lookup(skb->sk, ip_hdr(skb)->daddr))
      is finally called by tcp_v4_reqsk_send_ack(), but the first parameter(skb->sk) is 
      NULL at that moment, so kernel panic happens.
      This patch fixes this bug.
      
      OOPS output is as following:
      [  302.812793] IP: [<c05cfaa6>] tcp_v4_md5_do_lookup+0x12/0x42
      [  302.817075] Oops: 0000 [#1] SMP 
      [  302.819815] Modules linked in: ipv6 loop dm_multipath rtc_cmos rtc_core rtc_lib pcspkr pcnet32 mii i2c_piix4 parport_pc i2c_core parport ac button ata_piix libata dm_mod mptspi mptscsih mptbase scsi_transport_spi sd_mod scsi_mod crc_t10dif ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd [last unloaded: scsi_wait_scan]
      [  302.849946] 
      [  302.851198] Pid: 0, comm: swapper Not tainted (2.6.27-rc1-guijf #5)
      [  302.855184] EIP: 0060:[<c05cfaa6>] EFLAGS: 00010296 CPU: 0
      [  302.858296] EIP is at tcp_v4_md5_do_lookup+0x12/0x42
      [  302.861027] EAX: 0000001e EBX: 00000000 ECX: 00000046 EDX: 00000046
      [  302.864867] ESI: ceb69e00 EDI: 1467a8c0 EBP: cf75f180 ESP: c0792e54
      [  302.868333]  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
      [  302.871287] Process swapper (pid: 0, ti=c0792000 task=c0712340 task.ti=c0746000)
      [  302.875592] Stack: c06f413a 00000000 cf75f180 ceb69e00 00000000 c05d0d86 000016d0 ceac5400 
      [  302.883275]        c05d28f8 000016d0 ceb69e00 ceb69e20 681bf6e3 00001000 00000000 0a67a8c0 
      [  302.890971]        ceac5400 c04250a3 c06f413a c0792eb0 c0792edc cf59a620 cf59a620 cf59a634 
      [  302.900140] Call Trace:
      [  302.902392]  [<c05d0d86>] tcp_v4_reqsk_send_ack+0x17/0x35
      [  302.907060]  [<c05d28f8>] tcp_check_req+0x156/0x372
      [  302.910082]  [<c04250a3>] printk+0x14/0x18
      [  302.912868]  [<c05d0aa1>] tcp_v4_do_rcv+0x1d3/0x2bf
      [  302.917423]  [<c05d26be>] tcp_v4_rcv+0x563/0x5b9
      [  302.920453]  [<c05bb20f>] ip_local_deliver_finish+0xe8/0x183
      [  302.923865]  [<c05bb10a>] ip_rcv_finish+0x286/0x2a3
      [  302.928569]  [<c059e438>] dev_alloc_skb+0x11/0x25
      [  302.931563]  [<c05a211f>] netif_receive_skb+0x2d6/0x33a
      [  302.934914]  [<d0917941>] pcnet32_poll+0x333/0x680 [pcnet32]
      [  302.938735]  [<c05a3b48>] net_rx_action+0x5c/0xfe
      [  302.941792]  [<c042856b>] __do_softirq+0x5d/0xc1
      [  302.944788]  [<c042850e>] __do_softirq+0x0/0xc1
      [  302.948999]  [<c040564b>] do_softirq+0x55/0x88
      [  302.951870]  [<c04501b1>] handle_fasteoi_irq+0x0/0xa4
      [  302.954986]  [<c04284da>] irq_exit+0x35/0x69
      [  302.959081]  [<c0405717>] do_IRQ+0x99/0xae
      [  302.961896]  [<c040422b>] common_interrupt+0x23/0x28
      [  302.966279]  [<c040819d>] default_idle+0x2a/0x3d
      [  302.969212]  [<c0402552>] cpu_idle+0xb2/0xd2
      [  302.972169]  =======================
      [  302.974274] Code: fc ff 84 d2 0f 84 df fd ff ff e9 34 fe ff ff 83 c4 0c 5b 5e 5f 5d c3 90 90 57 89 d7 56 53 89 c3 50 68 3a 41 6f c0 e8 e9 55 e5 ff <8b> 93 9c 04 00 00 58 85 d2 59 74 1e 8b 72 10 31 db 31 c9 85 f6 
      [  303.011610] EIP: [<c05cfaa6>] tcp_v4_md5_do_lookup+0x12/0x42 SS:ESP 0068:c0792e54
      [  303.018360] Kernel panic - not syncing: Fatal exception in interrupt
      Signed-off-by: NGui Jianfeng <guijianfeng@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6edafaaf
  13. 17 7月, 2008 2 次提交
  14. 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
  15. 12 6月, 2008 1 次提交
  16. 22 3月, 2008 1 次提交
    • P
      [TCP]: TCP_DEFER_ACCEPT updates - process as established · ec3c0982
      Patrick McManus 提交于
      Change TCP_DEFER_ACCEPT implementation so that it transitions a
      connection to ESTABLISHED after handshake is complete instead of
      leaving it in SYN-RECV until some data arrvies. Place connection in
      accept queue when first data packet arrives from slow path.
      
      Benefits:
        - established connection is now reset if it never makes it
         to the accept queue
      
       - diagnostic state of established matches with the packet traces
         showing completed handshake
      
       - TCP_DEFER_ACCEPT timeouts are expressed in seconds and can now be
         enforced with reasonable accuracy instead of rounding up to next
         exponential back-off of syn-ack retry.
      Signed-off-by: NPatrick McManus <mcmanus@ducksong.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ec3c0982
  17. 04 3月, 2008 1 次提交
  18. 01 3月, 2008 1 次提交
  19. 11 10月, 2007 3 次提交
  20. 26 4月, 2007 4 次提交
  21. 01 3月, 2007 1 次提交
    • A
      [TCP]: Fix minisock tcp_create_openreq_child() typo. · a9948a7e
      Arnaldo Carvalho de Melo 提交于
      On 2/28/07, KOVACS Krisztian <hidden@balabit.hu> wrote:
      >
      >   Hi,
      >
      >   While reading TCP minisock code I've found this suspiciously looking
      > code fragment:
      >
      > - 8< -
      > struct sock *tcp_create_openreq_child(struct sock *sk, struct request_sock *req, struct sk_buff *skb)
      > {
      >         struct sock *newsk = inet_csk_clone(sk, req, GFP_ATOMIC);
      >
      >         if (newsk != NULL) {
      >                 const struct inet_request_sock *ireq = inet_rsk(req);
      >                 struct tcp_request_sock *treq = tcp_rsk(req);
      >                 struct inet_connection_sock *newicsk = inet_csk(sk);
      >                 struct tcp_sock *newtp;
      > - 8< -
      >
      >   The above code initializes newicsk to inet_csk(sk), isn't that supposed
      > to be inet_csk(newsk)?  As far as I can tell this might leave
      > icsk_ack.last_seg_size zero even if we do have received data.
      
      Good catch!
      
      David, please apply the attached patch.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a9948a7e
  22. 11 2月, 2007 1 次提交
  23. 03 12月, 2006 4 次提交
  24. 22 11月, 2006 1 次提交
    • D
      WorkStruct: Pass the work_struct pointer instead of context data · 65f27f38
      David Howells 提交于
      Pass the work_struct pointer to the work function rather than context data.
      The work function can use container_of() to work out the data.
      
      For the cases where the container of the work_struct may go away the moment the
      pending bit is cleared, it is made possible to defer the release of the
      structure by deferring the clearing of the pending bit.
      
      To make this work, an extra flag is introduced into the management side of the
      work_struct.  This governs auto-release of the structure upon execution.
      
      Ordinarily, the work queue executor would release the work_struct for further
      scheduling or deallocation by clearing the pending bit prior to jumping to the
      work function.  This means that, unless the driver makes some guarantee itself
      that the work_struct won't go away, the work function may not access anything
      else in the work_struct or its container lest they be deallocated..  This is a
      problem if the auxiliary data is taken away (as done by the last patch).
      
      However, if the pending bit is *not* cleared before jumping to the work
      function, then the work function *may* access the work_struct and its container
      with no problems.  But then the work function must itself release the
      work_struct by calling work_release().
      
      In most cases, automatic release is fine, so this is the default.  Special
      initiators exist for the non-auto-release case (ending in _NAR).
      Signed-Off-By: NDavid Howells <dhowells@redhat.com>
      65f27f38
  25. 23 9月, 2006 1 次提交
  26. 03 8月, 2006 1 次提交
    • W
      [TCP]: SNMPv2 tcpAttemptFails counter error · 3687b1dc
      Wei Yongjun 提交于
      Refer to RFC2012, tcpAttemptFails is defined as following:
        tcpAttemptFails OBJECT-TYPE
            SYNTAX      Counter32
            MAX-ACCESS  read-only
            STATUS      current
            DESCRIPTION
                    "The number of times TCP connections have made a direct
                    transition to the CLOSED state from either the SYN-SENT
                    state or the SYN-RCVD state, plus the number of times TCP
                    connections have made a direct transition to the LISTEN
                    state from the SYN-RCVD state."
            ::= { tcp 7 }
      
      When I lookup into RFC793, I found that the state change should occured
      under following condition:
        1. SYN-SENT -> CLOSED
           a) Received ACK,RST segment when SYN-SENT state.
      
        2. SYN-RCVD -> CLOSED
           b) Received SYN segment when SYN-RCVD state(came from LISTEN).
           c) Received RST segment when SYN-RCVD state(came from SYN-SENT).
           d) Received SYN segment when SYN-RCVD state(came from SYN-SENT).
      
        3. SYN-RCVD -> LISTEN
           e) Received RST segment when SYN-RCVD state(came from LISTEN).
      
      In my test, those direct state transition can not be counted to
      tcpAttemptFails.
      Signed-off-by: NWei Yongjun <yjwei@nanjing-fnst.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3687b1dc
  27. 04 7月, 2006 1 次提交
  28. 01 7月, 2006 1 次提交
  29. 30 6月, 2006 1 次提交
    • M
      [NET]: Add ECN support for TSO · b0da8537
      Michael Chan 提交于
      In the current TSO implementation, NETIF_F_TSO and ECN cannot be
      turned on together in a TCP connection.  The problem is that most
      hardware that supports TSO does not handle CWR correctly if it is set
      in the TSO packet.  Correct handling requires CWR to be set in the
      first packet only if it is set in the TSO header.
      
      This patch adds the ability to turn on NETIF_F_TSO and ECN using
      GSO if necessary to handle TSO packets with CWR set.  Hardware
      that handles CWR correctly can turn on NETIF_F_TSO_ECN in the dev->
      features flag.
      
      All TSO packets with CWR set will have the SKB_GSO_TCPV4_ECN set.  If
      the output device does not have the NETIF_F_TSO_ECN feature set, GSO
      will split the packet up correctly with CWR only set in the first
      segment.
      
      With help from Herbert Xu <herbert@gondor.apana.org.au>.
      
      Since ECN can always be enabled with TSO, the SOCK_NO_LARGESEND sock
      flag is completely removed.
      Signed-off-by: NMichael Chan <mchan@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b0da8537
  30. 04 1月, 2006 2 次提交