1. 27 May, 2015 8 commits
    • David S. Miller's avatar
      Merge branch 'ip_frag_next' · 837b9955
      David S. Miller authored
      Florian Westphal says:
      
      ====================
      net: force refragmentation for DF reassembed skbs
      
      output path tests:
      
          if (skb->len > mtu) ip_fragment()
      
      This breaks connectivity in one corner case:
       If the skb was reassembled, but has the DF bit set and ..
       .. its reassembled size is <= outdev mtu ..
       .. we will forward a DF packet larger than what the sender
          transmitted on wire.
      
      If a router later in the path can't forward this packet, it will send an
      icmp error in response to an mtu that the original sender never exceeded.
      
      This changes ipv4 defrag/output path to
      
      a) force refragmentation for DF reassembled skbs and
      b) set DF bit on all fragments when refragmenting if it was set on original
      frags.
      
      tested via:
      from scapy.all import *
      dip="10.23.42.2"
      payload="A"*1400
      packet=IP(dst=dip,id=12345,flags='DF')/UDP(sport=42,dport=42)/payload
      frags=fragment(packet,fragsize=1200)
      for fragment in frags:
          send(fragment)
      
      Without this patch, we generate fragments without df bit set based
      on the outgoing device mtu when fragmenting after forwarding, ie.
      
      IP (ttl 64, id 12345, offset 0, flags [+, DF], proto UDP (17), length 1204)
          192.168.7.1.42 > 10.23.42.2.42: UDP, length 1400
      IP (ttl 64, id 12345, offset 1184, flags [DF], proto UDP (17), length 244)
          192.168.7.1 > 10.23.42.2: ip-proto-17
      
      on ingress will either turn into
      
      IP (ttl 63, id 12345, offset 0, flags [+], proto UDP (17), length 1396)
          192.168.7.1.42 > 10.23.42.2.42: UDP, length 1400
      IP (ttl 63, id 12345, offset 1376, flags [none], proto UDP (17), length 52)
      
      (mtu 1400: We strip df and send larger fragment), or
      
      IP (ttl 63, id 12345, offset 0, flags [DF], proto UDP (17), length 1428)
          192.168.7.1.42 > 10.23.42.2.42: [udp sum ok] UDP, length 1400
      
      if mtu is 1500.  And in this case things break; router with a smaller mtu
      will send icmp error, but original sender only sent packets <= 1204 byte.
      
      With patch, we keep intent of such fragments and will emit DF-fragments
      that won't exceed 1204 byte in size.
      
      Joint work with Hannes Frederic Sowa.
      
      Changes since v2:
       - split unrelated patches from series
       - rework changelog of patch #2 to better illustrate breakage
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      837b9955
    • Florian Westphal's avatar
      ip_fragment: don't forward defragmented DF packet · d6b915e2
      Florian Westphal authored
      We currently always send fragments without DF bit set.
      
      Thus, given following setup:
      
      mtu1500 - mtu1500:1400 - mtu1400:1280 - mtu1280
         A           R1              R2         B
      
      Where R1 and R2 run linux with netfilter defragmentation/conntrack
      enabled, then if Host A sent a fragmented packet _with_ DF set to B, R1
      will respond with icmp too big error if one of these fragments exceeded
      1400 bytes.
      
      However, if R1 receives fragment sizes 1200 and 100, it would
      forward the reassembled packet without refragmenting, i.e.
      R2 will send an icmp error in response to a packet that was never sent,
      citing mtu that the original sender never exceeded.
      
      The other minor issue is that a refragmentation on R1 will conceal the
      MTU of R2-B since refragmentation does not set DF bit on the fragments.
      
      This modifies ip_fragment so that we track largest fragment size seen
      both for DF and non-DF packets, and set frag_max_size to the largest
      value.
      
      If the DF fragment size is larger or equal to the non-df one, we will
      consider the packet a path mtu probe:
      We set DF bit on the reassembled skb and also tag it with a new IPCB flag
      to force refragmentation even if skb fits outdev mtu.
      
      We will also set DF bit on each fragment in this case.
      
      Joint work with Hannes Frederic Sowa.
      Reported-by: default avatarJesse Gross <jesse@nicira.com>
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d6b915e2
    • Florian Westphal's avatar
      net: ipv4: avoid repeated calls to ip_skb_dst_mtu helper · c5501eb3
      Florian Westphal authored
      ip_skb_dst_mtu is small inline helper, but its called in several places.
      
      before: 17061      44       0   17105    42d1 net/ipv4/ip_output.o
      after:  16805      44       0   16849    41d1 net/ipv4/ip_output.o
      Signed-off-by: default avatarFlorian Westphal <fw@strlen.de>
      Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c5501eb3
    • David S. Miller's avatar
      Merge branch 'phy_rgmii' · 8c0ce770
      David S. Miller authored
      Florian Fainelli says:
      
      ====================
      net: phy: phy_interface_is_rgmii helper
      
      As you suggested, here is the helper function to avoid missing some RGMII
      interface checks. Had to wait for net to be merged in net-next to avoid
      submitting the same patch/commit.
      
      Dan, you might want to rebase your dp83867 submission to use that helper
      when you this patchset gets merged into net-next, thanks!
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8c0ce770
    • Florian Fainelli's avatar
      net: phy: Utilize phy_interface_is_rgmii · 32a64161
      Florian Fainelli authored
      Update all open-coded tests for all 4 PHY_INTERFACE_MODE_RGMII* values
      to use the newly introduced helper: phy_interface_is_rgmii.
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      32a64161
    • Florian Fainelli's avatar
      net: phy: Add phy_interface_is_rgmii helper · e463d88c
      Florian Fainelli authored
      RGMII interfaces come in 4 different flavors that the PHY library needs
      to care about: regular RGMII (no delays), RGMII with either RX or TX
      delay, and both. In order to avoid errors of checking only for one type
      of RGMII interface and miss the 3 others, introduce a convenience
      function which tests for all values.
      Suggested-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e463d88c
    • David S. Miller's avatar
      ipv4: Fix fib_trie.c build, missing linux/vmalloc.h include. · ffa915d0
      David S. Miller authored
      We used to get this indirectly I supposed, but no longer do.
      
      Either way, an explicit include should have been done in the
      first place.
      
         net/ipv4/fib_trie.c: In function '__node_free_rcu':
      >> net/ipv4/fib_trie.c:293:3: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration]
            vfree(n);
            ^
         net/ipv4/fib_trie.c: In function 'tnode_alloc':
      >> net/ipv4/fib_trie.c:312:3: error: implicit declaration of function 'vzalloc' [-Werror=implicit-function-declaration]
            return vzalloc(size);
            ^
      >> net/ipv4/fib_trie.c:312:3: warning: return makes pointer from integer without a cast
         cc1: some warnings being treated as errors
      Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ffa915d0
    • Eric Dumazet's avatar
      tcp: tcp_tso_autosize() minimum is one packet · d6a4e26a
      Eric Dumazet authored
      By making sure sk->sk_gso_max_segs minimal value is one,
      and sysctl_tcp_min_tso_segs minimal value is one as well,
      tcp_tso_autosize() will return a non zero value.
      
      We can then revert 843925f3
      ("tcp: Do not apply TSO segment limit to non-TSO packets")
      and save few cpu cycles in fast path.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Neal Cardwell <ncardwell@google.com>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Acked-by: default avatarNeal Cardwell <ncardwell@google.com>
      Acked-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d6a4e26a
  2. 26 May, 2015 7 commits
    • Eric Dumazet's avatar
      tcp: fix/cleanup inet_ehash_locks_alloc() · 095dc8e0
      Eric Dumazet authored
      If tcp ehash table is constrained to a very small number of buckets
      (eg boot parameter thash_entries=128), then we can crash if spinlock
      array has more entries.
      
      While we are at it, un-inline inet_ehash_locks_alloc() and make
      following changes :
      
      - Budget 2 cache lines per cpu worth of 'spinlocks'
      - Try to kmalloc() the array to avoid extra TLB pressure.
        (Most servers at Google allocate 8192 bytes for this hash table)
      - Get rid of various #ifdef
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      095dc8e0
    • Jon Paul Maloy's avatar
      tipc: fix bug in link protocol message create function · f3903bcc
      Jon Paul Maloy authored
      In commit dd3f9e70
      ("tipc: add packet sequence number at instant of transmission") we
      made a change with the consequence that packets in the link backlog
      queue don't contain valid sequence numbers.
      
      However, when we create a link protocol message, we still use the
      sequence number of the first packet in the backlog, if there is any,
      as "next_sent" indicator in the message. This may entail unnecessary
      retransissions or stale packet transmission when there is very low
      traffic on the link.
      
      This commit fixes this issue by only using the current value of
      tipc_link::snd_nxt as indicator.
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f3903bcc
    • Eric Dumazet's avatar
      net: fix inet_proto_csum_replace4() sparse errors · 05c98543
      Eric Dumazet authored
      make C=2 CF=-D__CHECK_ENDIAN__ net/core/utils.o
      ...
      net/core/utils.c:307:72: warning: incorrect type in argument 2 (different base types)
      net/core/utils.c:307:72:    expected restricted __wsum [usertype] addend
      net/core/utils.c:307:72:    got restricted __be32 [usertype] from
      net/core/utils.c:308:34: warning: incorrect type in argument 2 (different base types)
      net/core/utils.c:308:34:    expected restricted __wsum [usertype] addend
      net/core/utils.c:308:34:    got restricted __be32 [usertype] to
      net/core/utils.c:310:70: warning: incorrect type in argument 2 (different base types)
      net/core/utils.c:310:70:    expected restricted __wsum [usertype] addend
      net/core/utils.c:310:70:    got restricted __be32 [usertype] from
      net/core/utils.c:310:77: warning: incorrect type in argument 2 (different base types)
      net/core/utils.c:310:77:    expected restricted __wsum [usertype] addend
      net/core/utils.c:310:77:    got restricted __be32 [usertype] to
      net/core/utils.c:312:72: warning: incorrect type in argument 2 (different base types)
      net/core/utils.c:312:72:    expected restricted __wsum [usertype] addend
      net/core/utils.c:312:72:    got restricted __be32 [usertype] from
      net/core/utils.c:313:35: warning: incorrect type in argument 2 (different base types)
      net/core/utils.c:313:35:    expected restricted __wsum [usertype] addend
      net/core/utils.c:313:35:    got restricted __be32 [usertype] to
      
      Note we can use csum_replace4() helper
      
      Fixes: 58e3cac5 ("net: optimise inet_proto_csum_replace4()")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      05c98543
    • Eric Dumazet's avatar
      net: remove a sparse error in secure_dccpv6_sequence_number() · 68319052
      Eric Dumazet authored
      make C=2 CF=-D__CHECK_ENDIAN__ net/core/secure_seq.o
      net/core/secure_seq.c:157:50: warning: restricted __be32 degrades to
      integer
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      68319052
    • Wilson Kok's avatar
      bridge: skip fdb add if the port shouldn't learn · eb8d7baa
      Wilson Kok authored
      Check in fdb_add_entry() if the source port should learn, similar
      check is used in br_fdb_update.
      Note that new fdb entries which are added manually or
      as local ones are still permitted.
      This patch has been tested by running traffic via a bridge port and
      switching the port's state, also by manually adding/removing entries
      from the bridge's fdb.
      Signed-off-by: default avatarWilson Kok <wkok@cumulusnetworks.com>
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      eb8d7baa
    • Eric Dumazet's avatar
      pktgen: remove one sparse error · d4969581
      Eric Dumazet authored
      net/core/pktgen.c:2672:43: warning: incorrect type in assignment (different base types)
      net/core/pktgen.c:2672:43:    expected unsigned short [unsigned] [short] [usertype] <noident>
      net/core/pktgen.c:2672:43:    got restricted __be16 [usertype] protocol
      
      Let's use proper struct ethhdr instead of hard coding everything.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d4969581
    • Eric Dumazet's avatar
      ipv6: ipv6_select_ident() returns a __be32 · 7f159867
      Eric Dumazet authored
      ipv6_select_ident() returns a 32bit value in network order.
      
      Fixes: 286c2349 ("ipv6: Clean up ipv6_select_ident() and ip6_fragment()")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
      Acked-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7f159867
  3. 25 May, 2015 25 commits