1. 05 10月, 2011 2 次提交
    • Y
      tcp: properly update lost_cnt_hint during shifting · 1e5289e1
      Yan, Zheng 提交于
      lost_skb_hint is used by tcp_mark_head_lost() to mark the first unhandled skb.
      lost_cnt_hint is the number of packets or sacked packets before the lost_skb_hint;
      When shifting a skb that is before the lost_skb_hint, if tcp_is_fack() is ture,
      the skb has already been counted in the lost_cnt_hint; if tcp_is_fack() is false,
      tcp_sacktag_one() will increase the lost_cnt_hint. So tcp_shifted_skb() does not
      need to adjust the lost_cnt_hint by itself. When shifting a skb that is equal to
      lost_skb_hint, the shifted packets will not be counted by tcp_mark_head_lost().
      So tcp_shifted_skb() should adjust the lost_cnt_hint even tcp_is_fack(tp) is true.
      Signed-off-by: NZheng Yan <zheng.z.yan@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1e5289e1
    • Y
      tcp: properly handle md5sig_pool references · 260fcbeb
      Yan, Zheng 提交于
      tcp_v4_clear_md5_list() assumes that multiple tcp md5sig peers
      only hold one reference to md5sig_pool. but tcp_v4_md5_do_add()
      increases use count of md5sig_pool for each peer. This patch
      makes tcp_v4_md5_do_add() only increases use count for the first
      tcp md5sig peer.
      Signed-off-by: NZheng Yan <zheng.z.yan@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      260fcbeb
  2. 19 9月, 2011 1 次提交
  3. 17 9月, 2011 1 次提交
  4. 16 9月, 2011 1 次提交
    • E
      tcp: Change possible SYN flooding messages · 946cedcc
      Eric Dumazet 提交于
      "Possible SYN flooding on port xxxx " messages can fill logs on servers.
      
      Change logic to log the message only once per listener, and add two new
      SNMP counters to track :
      
      TCPReqQFullDoCookies : number of times a SYNCOOKIE was replied to client
      
      TCPReqQFullDrop : number of times a SYN request was dropped because
      syncookies were not enabled.
      
      Based on a prior patch from Tom Herbert, and suggestions from David.
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      CC: Tom Herbert <therbert@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      946cedcc
  5. 31 8月, 2011 1 次提交
  6. 30 8月, 2011 1 次提交
  7. 25 8月, 2011 1 次提交
  8. 11 8月, 2011 2 次提交
    • J
      ipv4: some rt_iif -> rt_route_iif conversions · 97a80410
      Julian Anastasov 提交于
      As rt_iif represents input device even for packets
      coming from loopback with output route, it is not an unique
      key specific to input routes. Now rt_route_iif has such role,
      it was fl.iif in 2.6.38, so better to change the checks at
      some places to save CPU cycles and to restore 2.6.38 semantics.
      
      compare_keys:
      	- input routes: only rt_route_iif matters, rt_iif is same
      	- output routes: only rt_oif matters, rt_iif is not
      		used for matching in __ip_route_output_key
      	- now we are back to 2.6.38 state
      
      ip_route_input_common:
      	- matching rt_route_iif implies input route
      	- compared to 2.6.38 we eliminated one rth->fl.oif check
      	because it was not needed even for 2.6.38
      
      compare_hash_inputs:
      	Only the change here is not an optimization, it has
      	effect only for output routes. I assume I'm restoring
      	the original intention to ignore oif, it was using fl.iif
      	- now we are back to 2.6.38 state
      Signed-off-by: NJulian Anastasov <ja@ssi.bg>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      97a80410
    • M
      tcp: initialize variable ecn_ok in syncookies path · f0e3d068
      Mike Waychison 提交于
      Using a gcc 4.4.3, warnings are emitted for a possibly uninitialized use
      of ecn_ok.
      
      This can happen if cookie_check_timestamp() returns due to not having
      seen a timestamp.  Defaulting to ecn off seems like a reasonable thing
      to do in this case, so initialized ecn_ok to false.
      Signed-off-by: NMike Waychison <mikew@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f0e3d068
  9. 08 8月, 2011 5 次提交
  10. 07 8月, 2011 1 次提交
    • D
      net: Compute protocol sequence numbers and fragment IDs using MD5. · 6e5714ea
      David S. Miller 提交于
      Computers have become a lot faster since we compromised on the
      partial MD4 hash which we use currently for performance reasons.
      
      MD5 is a much safer choice, and is inline with both RFC1948 and
      other ISS generators (OpenBSD, Solaris, etc.)
      
      Furthermore, only having 24-bits of the sequence number be truly
      unpredictable is a very serious limitation.  So the periodic
      regeneration and 8-bit counter have been removed.  We compute and
      use a full 32-bit sequence number.
      
      For ipv6, DCCP was found to use a 32-bit truncated initial sequence
      number (it needs 43-bits) and that is fixed here as well.
      Reported-by: NDan Kaminsky <dan@doxpara.com>
      Tested-by: NWilly Tarreau <w@1wt.eu>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6e5714ea
  11. 03 8月, 2011 1 次提交
  12. 01 8月, 2011 1 次提交
  13. 29 7月, 2011 1 次提交
    • J
      netfilter: ip_queue: Fix small leak in ipq_build_packet_message() · 91c66c68
      Jesper Juhl 提交于
      ipq_build_packet_message() in net/ipv4/netfilter/ip_queue.c and
      net/ipv6/netfilter/ip6_queue.c contain a small potential mem leak as
      far as I can tell.
      
      We allocate memory for 'skb' with alloc_skb() annd then call
       nlh = NLMSG_PUT(skb, 0, 0, IPQM_PACKET, size - sizeof(*nlh));
      
      NLMSG_PUT is a macro
       NLMSG_PUT(skb, pid, seq, type, len) \
        		NLMSG_NEW(skb, pid, seq, type, len, 0)
      
      that expands to NLMSG_NEW, which is also a macro which expands to:
       NLMSG_NEW(skb, pid, seq, type, len, flags) \
        	({	if (unlikely(skb_tailroom(skb) < (int)NLMSG_SPACE(len))) \
        			goto nlmsg_failure; \
        		__nlmsg_put(skb, pid, seq, type, len, flags); })
      
      If we take the true branch of the 'if' statement and 'goto
      nlmsg_failure', then we'll, at that point, return from
      ipq_build_packet_message() without having assigned 'skb' to anything
      and we'll leak the memory we allocated for it when it goes out of
      scope.
      
      Fix this by placing a 'kfree(skb)' at 'nlmsg_failure'.
      
      I admit that I do not know how likely this to actually happen or even
      if there's something that guarantees that it will never happen - I'm
      not that familiar with this code, but if that is so, I've not been
      able to spot it.
      Signed-off-by: NJesper Juhl <jj@chaosbits.net>
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      91c66c68
  14. 27 7月, 2011 1 次提交
  15. 26 7月, 2011 1 次提交
  16. 24 7月, 2011 2 次提交
  17. 22 7月, 2011 6 次提交
  18. 19 7月, 2011 1 次提交
  19. 18 7月, 2011 3 次提交
  20. 17 7月, 2011 5 次提交
  21. 14 7月, 2011 1 次提交
    • D
      net: Embed hh_cache inside of struct neighbour. · f6b72b62
      David S. Miller 提交于
      Now that there is a one-to-one correspondance between neighbour
      and hh_cache entries, we no longer need:
      
      1) dynamic allocation
      2) attachment to dst->hh
      3) refcounting
      
      Initialization of the hh_cache entry is indicated by hh_len
      being non-zero, and such initialization is always done with
      the neighbour's lock held as a writer.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f6b72b62
  22. 13 7月, 2011 1 次提交
    • D
      ipv4: Inline neigh binding. · 3769cffb
      David Miller 提交于
      Get rid of all of the useless and costly indirection
      by doing the neigh hash table lookup directly inside
      of the neighbour binding.
      
      Rename from arp_bind_neighbour to rt_bind_neighbour.
      
      Use new helpers {__,}ipv4_neigh_lookup()
      
      In rt_bind_neighbour() get rid of useless tests which
      are never true in the context this function is called,
      namely dev is never NULL and the dst->neighbour is
      always NULL.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3769cffb
新手
引导
客服 返回
顶部