1. 29 4月, 2016 1 次提交
    • E
      tcp: give prequeue mode some care · 0cef6a4c
      Eric Dumazet 提交于
      TCP prequeue goal is to defer processing of incoming packets
      to user space thread currently blocked in a recvmsg() system call.
      
      Intent is to spend less time processing these packets on behalf
      of softirq handler, as softirq handler is unfair to normal process
      scheduler decisions, as it might interrupt threads that do not
      even use networking.
      
      Current prequeue implementation has following issues :
      
      1) It only checks size of the prequeue against sk_rcvbuf
      
         It was fine 15 years ago when sk_rcvbuf was in the 64KB vicinity.
         But we now have ~8MB values to cope with modern networking needs.
         We have to add sk_rmem_alloc in the equation, since out of order
         packets can definitely use up to sk_rcvbuf memory themselves.
      
      2) Even with a fixed memory truesize check, prequeue can be filled
         by thousands of packets. When prequeue needs to be flushed, either
         from sofirq context (in tcp_prequeue() or timer code), or process
         context (in tcp_prequeue_process()), this adds a latency spike
         which is often not desirable.
         I added a fixed limit of 32 packets, as this translated to a max
         flush time of 60 us on my test hosts.
      
         Also note that all packets in prequeue are not accounted for tcp_mem,
         since they are not charged against sk_forward_alloc at this point.
         This is probably not a big deal.
      
      Note that this might increase LINUX_MIB_TCPPREQUEUEDROPPED counts,
      which is misnamed, as packets are not dropped at all, but rather pushed
      to the stack (where they can be either consumed or dropped)
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0cef6a4c
  2. 28 4月, 2016 3 次提交
  3. 16 4月, 2016 1 次提交
    • E
      tcp: do not mess with listener sk_wmem_alloc · b3d05147
      Eric Dumazet 提交于
      When removing sk_refcnt manipulation on synflood, I missed that
      using skb_set_owner_w() was racy, if sk->sk_wmem_alloc had already
      transitioned to 0.
      
      We should hold sk_refcnt instead, but this is a big deal under attack.
      (Doing so increase performance from 3.2 Mpps to 3.8 Mpps only)
      
      In this patch, I chose to not attach a socket to syncookies skb.
      
      Performance is now 5 Mpps instead of 3.2 Mpps.
      
      Following patch will remove last known false sharing in
      tcp_rcv_state_process()
      
      Fixes: 3b24d854 ("tcp/dccp: do not touch listener sk_refcnt under synflood")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b3d05147
  4. 08 4月, 2016 1 次提交
  5. 05 4月, 2016 4 次提交
  6. 18 3月, 2016 1 次提交
  7. 15 3月, 2016 1 次提交
    • M
      tcp: Add RFC4898 tcpEStatsPerfDataSegsOut/In · a44d6eac
      Martin KaFai Lau 提交于
      Per RFC4898, they count segments sent/received
      containing a positive length data segment (that includes
      retransmission segments carrying data).  Unlike
      tcpi_segs_out/in, tcpi_data_segs_out/in excludes segments
      carrying no data (e.g. pure ack).
      
      The patch also updates the segs_in in tcp_fastopen_add_skb()
      so that segs_in >= data_segs_in property is kept.
      
      Together with retransmission data, tcpi_data_segs_out
      gives a better signal on the rxmit rate.
      
      v6: Rebase on the latest net-next
      
      v5: Eric pointed out that checking skb->len is still needed in
      tcp_fastopen_add_skb() because skb can carry a FIN without data.
      Hence, instead of open coding segs_in and data_segs_in, tcp_segs_in()
      helper is used.  Comment is added to the fastopen case to explain why
      segs_in has to be reset and tcp_segs_in() has to be called before
      __skb_pull().
      
      v4: Add comment to the changes in tcp_fastopen_add_skb()
      and also add remark on this case in the commit message.
      
      v3: Add const modifier to the skb parameter in tcp_segs_in()
      
      v2: Rework based on recent fix by Eric:
      commit a9d99ce2 ("tcp: fix tcpi_segs_in after connection establishment")
      Signed-off-by: NMartin KaFai Lau <kafai@fb.com>
      Cc: Chris Rapier <rapier@psc.edu>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Marcelo Ricardo Leitner <mleitner@redhat.com>
      Cc: Neal Cardwell <ncardwell@google.com>
      Cc: Yuchung Cheng <ycheng@google.com>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a44d6eac
  8. 19 2月, 2016 1 次提交
    • E
      tcp/dccp: fix another race at listener dismantle · 7716682c
      Eric Dumazet 提交于
      Ilya reported following lockdep splat:
      
      kernel: =========================
      kernel: [ BUG: held lock freed! ]
      kernel: 4.5.0-rc1-ceph-00026-g5e0a311 #1 Not tainted
      kernel: -------------------------
      kernel: swapper/5/0 is freeing memory
      ffff880035c9d200-ffff880035c9dbff, with a lock still held there!
      kernel: (&(&queue->rskq_lock)->rlock){+.-...}, at:
      [<ffffffff816f6a88>] inet_csk_reqsk_queue_add+0x28/0xa0
      kernel: 4 locks held by swapper/5/0:
      kernel: #0:  (rcu_read_lock){......}, at: [<ffffffff8169ef6b>]
      netif_receive_skb_internal+0x4b/0x1f0
      kernel: #1:  (rcu_read_lock){......}, at: [<ffffffff816e977f>]
      ip_local_deliver_finish+0x3f/0x380
      kernel: #2:  (slock-AF_INET){+.-...}, at: [<ffffffff81685ffb>]
      sk_clone_lock+0x19b/0x440
      kernel: #3:  (&(&queue->rskq_lock)->rlock){+.-...}, at:
      [<ffffffff816f6a88>] inet_csk_reqsk_queue_add+0x28/0xa0
      
      To properly fix this issue, inet_csk_reqsk_queue_add() needs
      to return to its callers if the child as been queued
      into accept queue.
      
      We also need to make sure listener is still there before
      calling sk->sk_data_ready(), by holding a reference on it,
      since the reference carried by the child can disappear as
      soon as the child is put on accept queue.
      Reported-by: NIlya Dryomov <idryomov@gmail.com>
      Fixes: ebb516af ("tcp/dccp: fix race at listener dismantle phase")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7716682c
  9. 17 2月, 2016 2 次提交
  10. 11 2月, 2016 5 次提交
  11. 09 2月, 2016 1 次提交
  12. 08 2月, 2016 10 次提交
  13. 27 1月, 2016 1 次提交
  14. 22 1月, 2016 1 次提交
    • E
      tcp: fix NULL deref in tcp_v4_send_ack() · e62a123b
      Eric Dumazet 提交于
      Neal reported crashes with this stack trace :
      
       RIP: 0010:[<ffffffff8c57231b>] tcp_v4_send_ack+0x41/0x20f
      ...
       CR2: 0000000000000018 CR3: 000000044005c000 CR4: 00000000001427e0
      ...
        [<ffffffff8c57258e>] tcp_v4_reqsk_send_ack+0xa5/0xb4
        [<ffffffff8c1a7caa>] tcp_check_req+0x2ea/0x3e0
        [<ffffffff8c19e420>] tcp_rcv_state_process+0x850/0x2500
        [<ffffffff8c1a6d21>] tcp_v4_do_rcv+0x141/0x330
        [<ffffffff8c56cdb2>] sk_backlog_rcv+0x21/0x30
        [<ffffffff8c098bbd>] tcp_recvmsg+0x75d/0xf90
        [<ffffffff8c0a8700>] inet_recvmsg+0x80/0xa0
        [<ffffffff8c17623e>] sock_aio_read+0xee/0x110
        [<ffffffff8c066fcf>] do_sync_read+0x6f/0xa0
        [<ffffffff8c0673a1>] SyS_read+0x1e1/0x290
        [<ffffffff8c5ca262>] system_call_fastpath+0x16/0x1b
      
      The problem here is the skb we provide to tcp_v4_send_ack() had to
      be parked in the backlog of a new TCP fastopen child because this child
      was owned by the user at the time an out of window packet arrived.
      
      Before queuing a packet, TCP has to set skb->dev to NULL as the device
      could disappear before packet is removed from the queue.
      
      Fix this issue by using the net pointer provided by the socket (being a
      timewait or a request socket).
      
      IPv6 is immune to the bug : tcp_v6_send_response() already gets the net
      pointer from the socket if provided.
      
      Fixes: 168a8f58 ("tcp: TCP Fast Open Server - main code path")
      Reported-by: NNeal Cardwell <ncardwell@google.com>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Jerry Chu <hkchu@google.com>
      Cc: Yuchung Cheng <ycheng@google.com>
      Acked-by: NNeal Cardwell <ncardwell@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e62a123b
  15. 21 1月, 2016 1 次提交
  16. 15 1月, 2016 2 次提交
  17. 11 1月, 2016 3 次提交
  18. 23 12月, 2015 1 次提交
    • F
      tcp: honour SO_BINDTODEVICE for TW_RST case too · 271c3b9b
      Florian Westphal 提交于
      Hannes points out that when we generate tcp reset for timewait sockets we
      pretend we found no socket and pass NULL sk to tcp_vX_send_reset().
      
      Make it cope with inet tw sockets and then provide tw sk.
      
      This makes RSTs appear on correct interface when SO_BINDTODEVICE is used.
      
      Packetdrill test case:
      // want default route to be used, we rely on BINDTODEVICE
      `ip route del 192.0.2.0/24 via 192.168.0.2 dev tun0`
      
      0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
      // test case still works due to BINDTODEVICE
      0.001 setsockopt(3, SOL_SOCKET, SO_BINDTODEVICE, "tun0", 4) = 0
      0.100...0.200 connect(3, ..., ...) = 0
      
      0.100 > S 0:0(0) <mss 1460,sackOK,nop,nop>
      0.200 < S. 0:0(0) ack 1 win 32792 <mss 1460,sackOK,nop,nop>
      0.200 > . 1:1(0) ack 1
      
      0.210 close(3) = 0
      
      0.210 > F. 1:1(0) ack 1 win 29200
      0.300 < . 1:1(0) ack 2 win 46
      
      // more data while in FIN_WAIT2, expect RST
      1.300 < P. 1:1001(1000) ack 1 win 46
      
      // fails without this change -- default route is used
      1.301 > R 1:1(0) win 0
      Reported-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NFlorian Westphal <fw@strlen.de>
      Acked-by: NEric Dumazet <edumazet@google.com>
      Acked-by: NHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      271c3b9b