1. 09 2月, 2012 1 次提交
    • E
      ipv4: Implement IP_UNICAST_IF socket option. · 76e21053
      Erich E. Hoover 提交于
      The IP_UNICAST_IF feature is needed by the Wine project.  This patch
      implements the feature by setting the outgoing interface in a similar
      fashion to that of IP_MULTICAST_IF.  A separate option is needed to
      handle this feature since the existing options do not provide all of
      the characteristics required by IP_UNICAST_IF, a summary is provided
      below.
      
      SO_BINDTODEVICE:
      * SO_BINDTODEVICE requires administrative privileges, IP_UNICAST_IF
      does not.  From reading some old mailing list articles my
      understanding is that SO_BINDTODEVICE requires administrative
      privileges because it can override the administrator's routing
      settings.
      * The SO_BINDTODEVICE option restricts both outbound and inbound
      traffic, IP_UNICAST_IF only impacts outbound traffic.
      
      IP_PKTINFO:
      * Since IP_PKTINFO and IP_UNICAST_IF are independent options,
      implementing IP_UNICAST_IF with IP_PKTINFO will likely break some
      applications.
      * Implementing IP_UNICAST_IF on top of IP_PKTINFO significantly
      complicates the Wine codebase and reduces the socket performance
      (doing this requires a lot of extra communication between the
      "server" and "user" layers).
      
      bind():
      * bind() does not work on broadcast packets, IP_UNICAST_IF is
      specifically intended to work with broadcast packets.
      * Like SO_BINDTODEVICE, bind() restricts both outbound and inbound
      traffic.
      Signed-off-by: NErich E. Hoover <ehoover@mines.edu>
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      76e21053
  2. 03 2月, 2012 1 次提交
  3. 02 2月, 2012 2 次提交
    • A
      net: Disambiguate kernel message · efcdbf24
      Arun Sharma 提交于
      Some of our machines were reporting:
      
      TCP: too many of orphaned sockets
      
      even when the number of orphaned sockets was well below the
      limit.
      
      We print a different message depending on whether we're out
      of TCP memory or there are too many orphaned sockets.
      
      Also move the check out of line and cleanup the messages
      that were printed.
      Signed-off-by: NArun Sharma <asharma@fb.com>
      Suggested-by: NMohan Srinivasan <mohan@fb.com>
      Cc: netdev@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: David Miller <davem@davemloft.net>
      Cc: Glauber Costa <glommer@parallels.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Joe Perches <joe@perches.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      efcdbf24
    • S
      tcp: md5: RST: getting md5 key from listener · 658ddaaf
      Shawn Lu 提交于
      TCP RST mechanism is broken in TCP md5(RFC2385). When
      connection is gone, md5 key is lost, sending RST
      without md5 hash is deem to ignored by peer. This can
      be a problem since RST help protocal like bgp to fast
      recove from peer crash.
      
      In most case, users of tcp md5, such as bgp and ldp,
      have listener on both sides to accept connection from peer.
      md5 keys for peers are saved in listening socket.
      
      There are two cases in finding md5 key when connection is
      lost:
      1.Passive receive RST: The message is send to well known port,
      tcp will associate it with listner. md5 key is gotten from
      listener.
      
      2.Active receive RST (no sock): The message is send to ative
      side, there is no socket associated with the message. In this
      case, finding listener from source port, then find md5 key from
      listener.
      
      we are not loosing sercuriy here:
      packet is checked with md5 hash. No RST is generated
      if md5 hash doesn't match or no md5 key can be found.
      Signed-off-by: NShawn Lu <shawn.lu@ericsson.com>
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      658ddaaf
  4. 01 2月, 2012 4 次提交
  5. 31 1月, 2012 2 次提交
    • N
      tcp: fix tcp_trim_head() to adjust segment count with skb MSS · 5b35e1e6
      Neal Cardwell 提交于
      This commit fixes tcp_trim_head() to recalculate the number of
      segments in the skb with the skb's existing MSS, so trimming the head
      causes the skb segment count to be monotonically non-increasing - it
      should stay the same or go down, but not increase.
      
      Previously tcp_trim_head() used the current MSS of the connection. But
      if there was a decrease in MSS between original transmission and ACK
      (e.g. due to PMTUD), this could cause tcp_trim_head() to
      counter-intuitively increase the segment count when trimming bytes off
      the head of an skb. This violated assumptions in tcp_tso_acked() that
      tcp_trim_head() only decreases the packet count, so that packets_acked
      in tcp_tso_acked() could underflow, leading tcp_clean_rtx_queue() to
      pass u32 pkts_acked values as large as 0xffffffff to
      ca_ops->pkts_acked().
      
      As an aside, if tcp_trim_head() had really wanted the skb to reflect
      the current MSS, it should have called tcp_set_skb_tso_segs()
      unconditionally, since a decrease in MSS would mean that a
      single-packet skb should now be sliced into multiple segments.
      Signed-off-by: NNeal Cardwell <ncardwell@google.com>
      Acked-by: NNandita Dukkipati <nanditad@google.com>
      Acked-by: NIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5b35e1e6
    • G
      net/tcp: Fix tcp memory limits initialization when !CONFIG_SYSCTL · 4acb4190
      Glauber Costa 提交于
      sysctl_tcp_mem() initialization was moved to sysctl_tcp_ipv4.c
      in commit 3dc43e3e, since it
      became a per-ns value.
      
      That code, however, will never run when CONFIG_SYSCTL is
      disabled, leading to bogus values on those fields - causing hung
      TCP sockets.
      
      This patch fixes it by keeping an initialization code in
      tcp_init(). It will be overwritten by the first net namespace
      init if CONFIG_SYSCTL is compiled in, and do the right thing if
      it is compiled out.
      
      It is also named properly as tcp_init_mem(), to properly signal
      its non-sysctl side effect on TCP limits.
      Reported-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NGlauber Costa <glommer@parallels.com>
      Cc: David S. Miller <davem@davemloft.net>
      Link: http://lkml.kernel.org/r/4F22D05A.8030604@parallels.com
      [ renamed the function, tidied up the changelog a bit ]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4acb4190
  6. 28 1月, 2012 1 次提交
  7. 27 1月, 2012 3 次提交
    • W
      ipv6: Fix ip_gre lockless xmits. · f2b3ee9e
      Willem de Bruijn 提交于
      Tunnel devices set NETIF_F_LLTX to bypass HARD_TX_LOCK.  Sit and
      ipip set this unconditionally in ops->setup, but gre enables it
      conditionally after parameter passing in ops->newlink. This is
      not called during tunnel setup as below, however, so GRE tunnels are
      still taking the lock.
      
      modprobe ip_gre
      ip tunnel add test0 mode gre remote 10.5.1.1 dev lo
      ip link set test0 up
      ip addr add 10.6.0.1 dev test0
       # cat /sys/class/net/test0/features
       # $DIR/test_tunnel_xmit 10 10.5.2.1
      ip route add 10.5.2.0/24 dev test0
      ip tunnel del test0
      
      The newlink callback is only called in rtnl_netlink, and only if
      the device is new, as it calls register_netdevice internally. Gre
      tunnels are created at 'ip tunnel add' with ioctl SIOCADDTUNNEL,
      which calls ipgre_tunnel_locate, which calls register_netdev.
      rtnl_newlink is called at 'ip link set', but skips ops->newlink
      and the device is up with locking still enabled. The equivalent
      ipip tunnel works fine, btw (just substitute 'method gre' for
      'method ipip').
      
      On kernels before /sys/class/net/*/features was removed [1],
      the first commented out line returns 0x6000 with method gre,
      which indicates that NETIF_F_LLTX (0x1000) is not set. With ipip,
      it reports 0x7000. This test cannot be used on recent kernels where
      the sysfs file is removed (and ETHTOOL_GFEATURES does not currently
      work for tunnel devices, because they lack dev->ethtool_ops).
      
      The second commented out line calls a simple transmission test [2]
      that sends on 24 cores at maximum rate. Results of a single run:
      
      ipip:			19,372,306
      gre before patch:	 4,839,753
      gre after patch:	19,133,873
      
      This patch replicates the condition check in ipgre_newlink to
      ipgre_tunnel_locate. It works for me, both with oseq on and off.
      This is the first time I looked at rtnetlink and iproute2 code,
      though, so someone more knowledgeable should probably check the
      patch. Thanks.
      
      The tail of both functions is now identical, by the way. To avoid
      code duplication, I'll be happy to rework this and merge the two.
      
      [1] http://patchwork.ozlabs.org/patch/104610/
      [2] http://kernel.googlecode.com/files/xmit_udp_parallel.cSigned-off-by: NWillem de Bruijn <willemb@google.com>
      Acked-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f2b3ee9e
    • D
      ipv4/ipv6: Prepare for new route gateway semantics. · 39232973
      David S. Miller 提交于
      In the future the ipv4/ipv6 route gateway will take on two types
      of values:
      
      1) INADDR_ANY/IN6ADDR_ANY, for local network routes, and in this case
         the neighbour must be obtained using the destination address in
         ipv4/ipv6 header as the lookup key.
      
      2) Everything else, the actual nexthop route address.
      
      So if the gateway is not inaddr-any we use it, otherwise we must use
      the packet's destination address.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      39232973
    • E
      tcp: add LINUX_MIB_TCPRETRANSFAIL counter · 09e9b813
      Eric Dumazet 提交于
      It might be useful to get a counter of failed tcp_retransmit_skb()
      calls.
      Reported-by: NSatoru Moriya <satoru.moriya@hds.com>
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      09e9b813
  8. 26 1月, 2012 2 次提交
  9. 25 1月, 2012 3 次提交
  10. 23 1月, 2012 2 次提交
    • S
      tcp: md5: using remote adress for md5 lookup in rst packet · 8a622e71
      shawnlu 提交于
      md5 key is added in socket through remote address.
      remote address should be used in finding md5 key when
      sending out reset packet.
      Signed-off-by: Nshawnlu <shawn.lu@ericsson.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8a622e71
    • Y
      tcp: detect loss above high_seq in recovery · 974c1236
      Yuchung Cheng 提交于
      Correctly implement a loss detection heuristic: New sequences (above
      high_seq) sent during the fast recovery are deemed lost when higher
      sequences are SACKed.
      
      Current code does not catch these losses, because tcp_mark_head_lost()
      does not check packets beyond high_seq. The fix is straight-forward by
      checking packets until the highest sacked packet. In addition, all the
      FLAG_DATA_LOST logic are in-effective and redundant and can be removed.
      
      Update the loss heuristic comments. The algorithm above is documented
      as heuristic B, but it is redundant too because heuristic A already
      covers B.
      
      Note that this change only marks some forward-retransmitted packets LOST.
      It does NOT forbid TCP performing further CWR on new losses. A potential
      follow-up patch under preparation is to perform another CWR on "new"
      losses such as
      1) sequence above high_seq is lost (by resetting high_seq to snd_nxt)
      2) retransmission is lost.
      Signed-off-by: NYuchung Cheng <ycheng@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      974c1236
  11. 21 1月, 2012 2 次提交
    • N
      tcp: fix undo after RTO for CUBIC · 5a45f008
      Neal Cardwell 提交于
      This patch fixes CUBIC so that cwnd reductions made during RTOs can be
      undone (just as they already can be undone when using the default/Reno
      behavior).
      
      When undoing cwnd reductions, BIC-derived congestion control modules
      were restoring the cwnd from last_max_cwnd. There were two problems
      with using last_max_cwnd to restore a cwnd during undo:
      
      (a) last_max_cwnd was set to 0 on state transitions into TCP_CA_Loss
      (by calling the module's reset() functions), so cwnd reductions from
      RTOs could not be undone.
      
      (b) when fast_covergence is enabled (which it is by default)
      last_max_cwnd does not actually hold the value of snd_cwnd before the
      loss; instead, it holds a scaled-down version of snd_cwnd.
      
      This patch makes the following changes:
      
      (1) upon undo, revert snd_cwnd to ca->loss_cwnd, which is already, as
      the existing comment notes, the "congestion window at last loss"
      
      (2) stop forgetting ca->loss_cwnd on TCP_CA_Loss events
      
      (3) use ca->last_max_cwnd to check if we're in slow start
      Signed-off-by: NNeal Cardwell <ncardwell@google.com>
      Acked-by: NStephen Hemminger <shemminger@vyatta.com>
      Acked-by: NSangtae Ha <sangtae.ha@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5a45f008
    • N
      tcp: fix undo after RTO for BIC · fc16dcd8
      Neal Cardwell 提交于
      This patch fixes BIC so that cwnd reductions made during RTOs can be
      undone (just as they already can be undone when using the default/Reno
      behavior).
      
      When undoing cwnd reductions, BIC-derived congestion control modules
      were restoring the cwnd from last_max_cwnd. There were two problems
      with using last_max_cwnd to restore a cwnd during undo:
      
      (a) last_max_cwnd was set to 0 on state transitions into TCP_CA_Loss
      (by calling the module's reset() functions), so cwnd reductions from
      RTOs could not be undone.
      
      (b) when fast_covergence is enabled (which it is by default)
      last_max_cwnd does not actually hold the value of snd_cwnd before the
      loss; instead, it holds a scaled-down version of snd_cwnd.
      
      This patch makes the following changes:
      
      (1) upon undo, revert snd_cwnd to ca->loss_cwnd, which is already, as
      the existing comment notes, the "congestion window at last loss"
      
      (2) stop forgetting ca->loss_cwnd on TCP_CA_Loss events
      
      (3) use ca->last_max_cwnd to check if we're in slow start
      Signed-off-by: NNeal Cardwell <ncardwell@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fc16dcd8
  12. 18 1月, 2012 1 次提交
  13. 17 1月, 2012 2 次提交
  14. 13 1月, 2012 2 次提交
  15. 12 1月, 2012 2 次提交
  16. 10 1月, 2012 1 次提交
  17. 08 1月, 2012 1 次提交
  18. 06 1月, 2012 1 次提交
  19. 31 12月, 2011 1 次提交
  20. 29 12月, 2011 1 次提交
  21. 28 12月, 2011 2 次提交
  22. 23 12月, 2011 3 次提交