1. 23 Aug, 2016 7 commits
    • Eric Dumazet's avatar
      tcp: properly scale window in tcp_v[46]_reqsk_send_ack() · 20a2b49f
      Eric Dumazet authored
      When sending an ack in SYN_RECV state, we must scale the offered
      window if wscale option was negotiated and accepted.
      
      Tested:
       Following packetdrill test demonstrates the issue :
      
      0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
      +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
      
      +0 bind(3, ..., ...) = 0
      +0 listen(3, 1) = 0
      
      // Establish a connection.
      +0 < S 0:0(0) win 20000 <mss 1000,sackOK,wscale 7, nop, TS val 100 ecr 0>
      +0 > S. 0:0(0) ack 1 win 28960 <mss 1460,sackOK, TS val 100 ecr 100, nop, wscale 7>
      
      +0 < . 1:11(10) ack 1 win 156 <nop,nop,TS val 99 ecr 100>
      // check that window is properly scaled !
      +0 > . 1:1(0) ack 1 win 226 <nop,nop,TS val 200 ecr 100>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Yuchung Cheng <ycheng@google.com>
      Cc: Neal Cardwell <ncardwell@google.com>
      Acked-by: default avatarYuchung Cheng <ycheng@google.com>
      Acked-by: default avatarNeal Cardwell <ncardwell@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      20a2b49f
    • Zefir Kurtisi's avatar
      gianfar: fix size of scatter-gathered frames · 6c389fc9
      Zefir Kurtisi authored
      The current scatter-gather logic in gianfar is flawed, since
      it does not consider the eTSEC's RxBD 'Data Length' field is
      context depening: for the last fragment it contains the full
      frame size, while fragments contain the fragment size, which
      equals the value written to register MRBLR.
      
      This causes data corruption as soon as the hardware starts
      to fragment receiving frames. As a result, the size of
      fragmented frames is increased by
      (nr_frags - 1) * MRBLR
      
      We first noticed this issue working with DSA, where an ICMP
      request sized 1472 bytes causes the scatter-gather logic to
      kick in. The full Ethernet frame (1518) gets increased by
      DSA (4), GMAC_FCB_LEN (8), and FSL_GIANFAR_DEV_HAS_TIMER
      (priv->padding=8) to a total of 1538 octets, which is
      fragmented by the hardware and reconstructed by the driver
      to a 3074 octet frame.
      
      This patch fixes the problem by adjusting the size of
      the last fragment.
      
      It was tested by setting MRBLR to different multiples of
      64, proving correct scatter-gather operation on frames
      with up to 9000 octets in size.
      Signed-off-by: default avatarZefir Kurtisi <zefir.kurtisi@neratec.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6c389fc9
    • Zefir Kurtisi's avatar
      gianfar: prevent fragmentation in DSA environments · b323431b
      Zefir Kurtisi authored
      The eTSEC register MRBLR defines the maximum space in
      the RX buffers and is set to 1536 by gianfar. This
      reasonably covers the common use case where the MTU
      is kept at default 1500. In that case, the largest
      Ethernet frame size of 1518 plus an optional
      GMAC_FCB_LEN of 8, and an additional padding of 8
      to handle FSL_GIANFAR_DEV_HAS_TIMER totals to 1534
      and nicely fit within the chosen MRBLR.
      
      Alas, if the eTSEC is attached to a DSA enabled switch,
      the (E)DSA header extension (4 or 8 bytes) causes every
      maximum sized frame to be fragmented by the hardware.
      
      This patch increases the maximum RX buffer size by 8
      and rounds up to the next multiple of 64, which the
      hardware's defines as RX buffer granularity.
      Signed-off-by: default avatarZefir Kurtisi <zefir.kurtisi@neratec.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b323431b
    • Eric Dumazet's avatar
      udp: fix poll() issue with zero sized packets · e83c6744
      Eric Dumazet authored
      Laura tracked poll() [and friends] regression caused by commit
      e6afc8ac ("udp: remove headers from UDP packets before queueing")
      
      udp_poll() needs to know if there is a valid packet in receive queue,
      even if its payload length is 0.
      
      Change first_packet_length() to return an signed int, and use -1
      as the indication of an empty queue.
      
      Fixes: e6afc8ac ("udp: remove headers from UDP packets before queueing")
      Reported-by: default avatarLaura Abbott <labbott@redhat.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Tested-by: default avatarLaura Abbott <labbott@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e83c6744
    • Jamal Hadi Salim's avatar
      net sched: fix encoding to use real length · 28a10c42
      Jamal Hadi Salim authored
      Encoding of the metadata was using the padded length as opposed to
      the real length of the data which is a bug per specification.
      This has not been an issue todate because all metadatum specified
      so far has been 32 bit where aligned and data length are the same width.
      This also includes a bug fix for validating the length of a u16 field.
      But since there is no metadata of size u16 yes we are fine to include it
      here.
      
      While at it get rid of magic numbers.
      
      Fixes: ef6980b6 ("net sched: introduce IFE action")
      Signed-off-by: default avatarJamal Hadi Salim <jhs@mojatatu.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      28a10c42
    • Yuval Mintz's avatar
      qed: FLR of active VFs might lead to FW assert · 4870e704
      Yuval Mintz authored
      Driver never bothered marking the VF's vport with the VF's sw_fid.
      As a result, FLR flows are not going to clean those vports.
      
      If the vport was active when FLRed, re-activating it would lead
      to a FW assertion.
      
      Fixes: dacd88d6 ("qed: IOV l2 functionality")
      Signed-off-by: default avatarYuval Mintz <Yuval.Mintz@qlogic.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4870e704
    • Shmulik Ladkani's avatar
      net: ip_finish_output_gso: Allow fragmenting segments of tunneled skbs if their DF is unset · c0451fe1
      Shmulik Ladkani authored
      In b8247f09,
      
         "net: ip_finish_output_gso: If skb_gso_network_seglen exceeds MTU, allow segmentation for local udp tunneled skbs"
      
      gso skbs arriving from an ingress interface that go through UDP
      tunneling, are allowed to be fragmented if the resulting encapulated
      segments exceed the dst mtu of the egress interface.
      
      This aligned the behavior of gso skbs to non-gso skbs going through udp
      encapsulation path.
      
      However the non-gso vs gso anomaly is present also in the following
      cases of a GRE tunnel:
       - ip_gre in collect_md mode, where TUNNEL_DONT_FRAGMENT is not set
         (e.g. OvS vport-gre with df_default=false)
       - ip_gre in nopmtudisc mode, where IFLA_GRE_IGNORE_DF is set
      
      In both of the above cases, the non-gso skbs get fragmented, whereas the
      gso skbs (having skb_gso_network_seglen that exceeds dst mtu) get dropped,
      as they don't go through the segment+fragment code path.
      
      Fix: Setting IPSKB_FRAG_SEGS if the tunnel specified IP_DF bit is NOT set.
      
      Tunnels that do set IP_DF, will not go to fragmentation of segments.
      This preserves behavior of ip_gre in (the default) pmtudisc mode.
      
      Fixes: b8247f09 ("net: ip_finish_output_gso: If skb_gso_network_seglen exceeds MTU, allow segmentation for local udp tunneled skbs")
      Reported-by: default avatarwenxu <wenxu@ucloud.cn>
      Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarShmulik Ladkani <shmulik.ladkani@gmail.com>
      Tested-by: default avatarwenxu <wenxu@ucloud.cn>
      Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c0451fe1
  2. 22 Aug, 2016 9 commits
  3. 21 Aug, 2016 2 commits
  4. 20 Aug, 2016 5 commits
  5. 19 Aug, 2016 17 commits