1. 18 Jul, 2018 13 commits
  2. 16 Jul, 2018 24 commits
    • Ursula Braun's avatar
      net/smc: take sock lock in smc_ioctl() · 1992d998
      Ursula Braun authored
      SMC ioctl processing requires the sock lock to work properly in
      all thinkable scenarios.
      Problem has been found with RaceFuzzer and fixes:
         KASAN: null-ptr-deref Read in smc_ioctl
      Reported-by: default avatarByoungyoung Lee <lifeasageek@gmail.com>
      Reported-by: syzbot+35b2c5aa76fd398b9fd4@syzkaller.appspotmail.com
      Signed-off-by: default avatarUrsula Braun <ubraun@linux.ibm.com>
      Reviewed-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1992d998
    • David S. Miller's avatar
      Merge branch 'tg3-fixes' · bd598d20
      David S. Miller authored
      Siva Reddy Kallam says:
      
      ====================
      tg3: Update copyright and fix for tx timeout with 5762
      
      First patch:
              Update copyright
      
      Second patch:
              Add higher cpu clock for 5762
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bd598d20
    • Sanjeev Bansal's avatar
      tg3: Add higher cpu clock for 5762. · 3a498606
      Sanjeev Bansal authored
      This patch has fix for TX timeout while running bi-directional
      traffic with 100 Mbps using 5762.
      Signed-off-by: default avatarSanjeev Bansal <sanjeevb.bansal@broadcom.com>
      Signed-off-by: default avatarSiva Reddy Kallam <siva.kallam@broadcom.com>
      Reviewed-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3a498606
    • Siva Reddy Kallam's avatar
      0f2605fb
    • John Allen's avatar
      ibmvnic: Fix error recovery on login failure · 3578a7ec
      John Allen authored
      Testing has uncovered a failure case that is not handled properly. In the
      event that a login fails and we are not able to recover on the spot, we
      return 0 from do_reset, preventing any error recovery code from being
      triggered.  Additionally, the state is set to "probed" meaning that when we
      are able to trigger the error recovery, the driver always comes up in the
      probed state. To handle the case properly, we need to return a failure code
      here and set the adapter state to the state that we entered the reset in
      indicating the state that we would like to come out of the recovery reset
      in.
      Signed-off-by: default avatarJohn Allen <jallen@linux.vnet.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3578a7ec
    • Stefan Wahren's avatar
      net: lan78xx: Fix race in tx pending skb size calculation · dea39aca
      Stefan Wahren authored
      The skb size calculation in lan78xx_tx_bh is in race with the start_xmit,
      which could lead to rare kernel oopses. So protect the whole skb walk with
      a spin lock. As a benefit we can unlink the skb directly.
      
      This patch was tested on Raspberry Pi 3B+
      
      Link: https://github.com/raspberrypi/linux/issues/2608
      Fixes: 55d7de9d ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet")
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarFloris Bos <bos@je-eigen-domein.nl>
      Signed-off-by: default avatarStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dea39aca
    • David Ahern's avatar
      net/ipv6: Do not allow device only routes via the multipath API · b5d2d75e
      David Ahern authored
      Eric reported that reverting the patch that fixed and simplified IPv6
      multipath routes means reverting back to invalid userspace notifications.
      eg.,
      $ ip -6 route add 2001:db8:1::/64 nexthop dev eth0 nexthop dev eth1
      
      only generates a single notification:
      2001:db8:1::/64 dev eth0 metric 1024 pref medium
      
      While working on a fix for this problem I found another case that is just
      broken completely - a multipath route with a gateway followed by device
      followed by gateway:
          $ ip -6 ro add 2001:db8:103::/64
                nexthop via 2001:db8:1::64
                nexthop dev dummy2
                nexthop via 2001:db8:3::64
      
      In this case the device only route is dropped completely - no notification
      to userpsace but no addition to the FIB either:
      
      $ ip -6 ro ls
      2001:db8:1::/64 dev dummy1 proto kernel metric 256 pref medium
      2001:db8:2::/64 dev dummy2 proto kernel metric 256 pref medium
      2001:db8:3::/64 dev dummy3 proto kernel metric 256 pref medium
      2001:db8:103::/64 metric 1024
      	nexthop via 2001:db8:1::64 dev dummy1 weight 1
      	nexthop via 2001:db8:3::64 dev dummy3 weight 1 pref medium
      fe80::/64 dev dummy1 proto kernel metric 256 pref medium
      fe80::/64 dev dummy2 proto kernel metric 256 pref medium
      fe80::/64 dev dummy3 proto kernel metric 256 pref medium
      
      Really, IPv6 multipath is just FUBAR'ed beyond repair when it comes to
      device only routes, so do not allow it all.
      
      This change will break any scripts relying on the mpath api for insert,
      but I don't see any other way to handle the permutations. Besides, since
      the routes are added to the FIB as standalone (non-multipath) routes the
      kernel is not doing what the user requested, so it might as well tell the
      user that.
      Reported-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid Ahern <dsahern@gmail.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b5d2d75e
    • Stefan Baranoff's avatar
      tcp: Fix broken repair socket window probe patch · 31048d7a
      Stefan Baranoff authored
      Correct previous bad attempt at allowing sockets to come out of TCP
      repair without sending window probes. To avoid changing size of
      the repair variable in struct tcp_sock, this lets the decision for
      sending probes or not to be made when coming out of repair by
      introducing two ways to turn it off.
      
      v2:
      * Remove erroneous comment; defines now make behavior clear
      
      Fixes: 70b7ff13 ("tcp: allow user to create repair socket without window probes")
      Signed-off-by: default avatarStefan Baranoff <sbaranoff@gmail.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Acked-by: default avatarAndrei Vagin <avagin@virtuozzo.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      31048d7a
    • Saeed Mahameed's avatar
      net/mlx4_en: Don't reuse RX page when XDP is set · 432e629e
      Saeed Mahameed authored
      When a new rx packet arrives, the rx path will decide whether to reuse
      the remainder of the page or not according to one of the below conditions:
      1. frag_info->frag_stride == PAGE_SIZE / 2
      2. frags->page_offset + frag_info->frag_size > PAGE_SIZE;
      
      The first condition is no met for when XDP is set.
      For XDP, page_offset is always set to priv->rx_headroom which is
      XDP_PACKET_HEADROOM and frag_info->frag_size is around mtu size + some
      padding, still the 2nd release condition will hold since
      XDP_PACKET_HEADROOM + 1536 < PAGE_SIZE, as a result the page will not
      be released and will be _wrongly_ reused for next free rx descriptor.
      
      In XDP there is an assumption to have a page per packet and reuse can
      break such assumption and might cause packet data corruptions.
      
      Fix this by adding an extra condition (!priv->rx_headroom) to the 2nd
      case to avoid page reuse when XDP is set, since rx_headroom is set to 0
      for non XDP setup and set to XDP_PACKET_HEADROOM for XDP setup.
      
      No additional cache line is required for the new condition.
      
      Fixes: 34db548b ("mlx4: add page recycling in receive path")
      Signed-off-by: default avatarSaeed Mahameed <saeedm@mellanox.com>
      Signed-off-by: default avatarTariq Toukan <tariqt@mellanox.com>
      Suggested-by: default avatarMartin KaFai Lau <kafai@fb.com>
      CC: Eric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      432e629e
    • Randy Dunlap's avatar
      net/ethernet/freescale/fman: fix cross-build error · c1334597
      Randy Dunlap authored
        CC [M]  drivers/net/ethernet/freescale/fman/fman.o
      In file included from ../drivers/net/ethernet/freescale/fman/fman.c:35:
      ../include/linux/fsl/guts.h: In function 'guts_set_dmacr':
      ../include/linux/fsl/guts.h:165:2: error: implicit declaration of function 'clrsetbits_be32' [-Werror=implicit-function-declaration]
        clrsetbits_be32(&guts->dmacr, 3 << shift, device << shift);
        ^~~~~~~~~~~~~~~
      Signed-off-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Cc: Madalin Bucur <madalin.bucur@nxp.com>
      Cc: netdev@vger.kernel.org
      Cc: linuxppc-dev@lists.ozlabs.org
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c1334597
    • Stephen Hemminger's avatar
      hv/netvsc: fix handling of fallback to single queue mode · 916c5e14
      Stephen Hemminger authored
      The netvsc device may need to fallback to running in single queue
      mode if host side only wants to support single queue.
      
      Recent change for handling mtu broke this in setup logic.
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Fixes: 3ffe64f1 ("hv_netvsc: split sub-channel setup into async and sync")
      Signed-off-by: default avatarStephen Hemminger <sthemmin@microsoft.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      916c5e14
    • Thomas Falcon's avatar
      ibmvnic: Revise RX/TX queue error messages · 2d14d379
      Thomas Falcon authored
      During a device failover, there may be latency between the loss
      of the current backing device and a notification from firmware that
      a failover has occurred. This latency can result in a large amount of
      error printouts as firmware returns outgoing traffic with a generic
      error code. These are not necessarily errors in this case as the
      firmware is busy swapping in a new backing adapter and is not ready
      to send packets yet. This patch reclassifies those error codes as
      warnings with an explanation that a failover may be pending. All
      other return codes will be considered errors.
      Signed-off-by: default avatarThomas Falcon <tlfalcon@linux.vnet.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2d14d379
    • Sabrina Dubroca's avatar
      ipv6: make DAD fail with enhanced DAD when nonce length differs · e6651599
      Sabrina Dubroca authored
      Commit adc176c5 ("ipv6 addrconf: Implemented enhanced DAD (RFC7527)")
      added enhanced DAD with a nonce length of 6 bytes. However, RFC7527
      doesn't specify the length of the nonce, other than being 6 + 8*k bytes,
      with integer k >= 0 (RFC3971 5.3.2). The current implementation simply
      assumes that the nonce will always be 6 bytes, but others systems are
      free to choose different sizes.
      
      If another system sends a nonce of different length but with the same 6
      bytes prefix, it shouldn't be considered as the same nonce. Thus, check
      that the length of the received nonce is the same as the length we sent.
      
      Ugly scapy test script running on veth0:
      
      def loop():
          pkt=sniff(iface="veth0", filter="icmp6", count=1)
          pkt = pkt[0]
          b = bytearray(pkt[Raw].load)
          b[1] += 1
          b += b'\xde\xad\xbe\xef\xde\xad\xbe\xef'
          pkt[Raw].load = bytes(b)
          pkt[IPv6].plen += 8
          # fixup checksum after modifying the payload
          pkt[IPv6].payload.cksum -= 0x3b44
          if pkt[IPv6].payload.cksum < 0:
              pkt[IPv6].payload.cksum += 0xffff
          sendp(pkt, iface="veth0")
      
      This should result in DAD failure for any address added to veth0's peer,
      but is currently ignored.
      
      Fixes: adc176c5 ("ipv6 addrconf: Implemented enhanced DAD (RFC7527)")
      Signed-off-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Reviewed-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e6651599
    • Corentin Labbe's avatar
      net: ethernet: stmmac: fix documentation warning · 014dd768
      Corentin Labbe authored
      This patch remove the following documentation warning
      drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:103: warning: Excess function parameter 'priv' description in 'stmmac_axi_setup'
      It was introduced in commit afea0365 ("stmmac: rework DMA bus setting and introduce new platform AXI structure")
      Signed-off-by: default avatarCorentin Labbe <clabbe@baylibre.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      014dd768
    • Corentin Labbe's avatar
      net: stmmac: dwmac-sun8i: fix typo descrive => describe · 56c266dc
      Corentin Labbe authored
      This patch fix a typo in the word Describe
      Signed-off-by: default avatarCorentin Labbe <clabbe@baylibre.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      56c266dc
    • Prashant Bhole's avatar
      net: ip6_gre: get ipv6hdr after skb_cow_head() · b7ed8794
      Prashant Bhole authored
      A KASAN:use-after-free bug was found related to ip6-erspan
      while running selftests/net/ip6_gre_headroom.sh
      
      It happens because of following sequence:
      - ipv6hdr pointer is obtained from skb
      - skb_cow_head() is called, skb->head memory is reallocated
      - old data is accessed using ipv6hdr pointer
      
      skb_cow_head() call was added in e41c7c68 ("ip6erspan: make sure
      enough headroom at xmit."), but looking at the history there was a
      chance of similar bug because gre_handle_offloads() and pskb_trim()
      can also reallocate skb->head memory. Fixes tag points to commit
      which introduced possibility of this bug.
      
      This patch moves ipv6hdr pointer assignment after skb_cow_head() call.
      
      Fixes: 5a963eb6 ("ip6_gre: Add ERSPAN native tunnel support")
      Signed-off-by: default avatarPrashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
      Reviewed-by: default avatarGreg Rose <gvrose8192@gmail.com>
      Acked-by: default avatarWilliam Tu <u9012063@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b7ed8794
    • Toshiaki Makita's avatar
      tun: Fix use-after-free on XDP_TX · 6e8cfd6d
      Toshiaki Makita authored
      On XDP_TX we need to free up the frame only when tun_xdp_tx() returns a
      negative value. A positive value indicates that the packet is
      successfully enqueued to the ptr_ring, so freeing the page causes
      use-after-free.
      
      Fixes: 735fc405 ("xdp: change ndo_xdp_xmit API to support bulking")
      Signed-off-by: default avatarToshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
      Acked-by: default avatarJason Wang <jasowang@redhat.com>
      Acked-by: default avatarJesper Dangaard Brouer <brouer@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6e8cfd6d
    • Masanari Iida's avatar
      bonding: Fix a typo in bonding.txt · 9f80a072
      Masanari Iida authored
      This patch fixes a spelling typo in bonding.txt
      Signed-off-by: default avatarMasanari Iida <standby24x7@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9f80a072
    • Dave Watson's avatar
      tls: Stricter error checking in zerocopy sendmsg path · 32da1221
      Dave Watson authored
      In the zerocopy sendmsg() path, there are error checks to revert
      the zerocopy if we get any error code.  syzkaller has discovered
      that tls_push_record can return -ECONNRESET, which is fatal, and
      happens after the point at which it is safe to revert the iter,
      as we've already passed the memory to do_tcp_sendpages.
      
      Previously this code could return -ENOMEM and we would want to
      revert the iter, but AFAIK this no longer returns ENOMEM after
      a447da7d ("tls: fix waitall behavior in tls_sw_recvmsg"),
      so we fail for all error codes.
      
      Reported-by: syzbot+c226690f7b3126c5ee04@syzkaller.appspotmail.com
      Reported-by: syzbot+709f2810a6a05f11d4d3@syzkaller.appspotmail.com
      Signed-off-by: default avatarDave Watson <davejwatson@fb.com>
      Fixes: 3c4d7559 ("tls: kernel TLS support")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      32da1221
    • Constantine Shulyupin's avatar
    • Eric Biggers's avatar
      KEYS: DNS: fix parsing multiple options · c604cb76
      Eric Biggers authored
      My recent fix for dns_resolver_preparse() printing very long strings was
      incomplete, as shown by syzbot which still managed to hit the
      WARN_ONCE() in set_precision() by adding a crafted "dns_resolver" key:
      
          precision 50001 too large
          WARNING: CPU: 7 PID: 864 at lib/vsprintf.c:2164 vsnprintf+0x48a/0x5a0
      
      The bug this time isn't just a printing bug, but also a logical error
      when multiple options ("#"-separated strings) are given in the key
      payload.  Specifically, when separating an option string into name and
      value, if there is no value then the name is incorrectly considered to
      end at the end of the key payload, rather than the end of the current
      option.  This bypasses validation of the option length, and also means
      that specifying multiple options is broken -- which presumably has gone
      unnoticed as there is currently only one valid option anyway.
      
      A similar problem also applied to option values, as the kstrtoul() when
      parsing the "dnserror" option will read past the end of the current
      option and into the next option.
      
      Fix these bugs by correctly computing the length of the option name and
      by copying the option value, null-terminated, into a temporary buffer.
      
      Reproducer for the WARN_ONCE() that syzbot hit:
      
          perl -e 'print "#A#", "\0" x 50000' | keyctl padd dns_resolver desc @s
      
      Reproducer for "dnserror" option being parsed incorrectly (expected
      behavior is to fail when seeing the unknown option "foo", actual
      behavior was to read the dnserror value as "1#foo" and fail there):
      
          perl -e 'print "#dnserror=1#foo\0"' | keyctl padd dns_resolver desc @s
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Fixes: 4a2d7892 ("DNS: If the DNS server returns an error, allow that to be cached [ver #2]")
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c604cb76
    • David S. Miller's avatar
      Merge branch 'multicast-init-as-INCLUDE-when-join-SSM-INCLUDE-group' · 8e05fd83
      David S. Miller authored
      Hangbin Liu says:
      
      ====================
      multicast: init as INCLUDE when join SSM INCLUDE group
      
      Based on RFC3376 5.1 and RFC3810 6.1, we should init as INCLUDE when join SSM
      INCLUDE group. In my first version I only clear the group change record. But
      this is not enough as when a new group join, it will init as EXCLUDE and
      trigger an filter mode change in ip/ip6_mc_add_src(), which will clear all
      source addresses' sf_crcount. This will prevent early joined address sending
      state change records if multi source addresses joined at the same time.
      
      In this v2 patchset, I fixed it by directly initializing the mode to INCLUDE
      for SSM JOIN_SOURCE_GROUP. I also split the original patch into two separated
      patches for IPv4 and IPv6.
      
      Test: test by myself and customer.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8e05fd83
    • Hangbin Liu's avatar
      ipv6/mcast: init as INCLUDE when join SSM INCLUDE group · c7ea20c9
      Hangbin Liu authored
      This an IPv6 version patch of "ipv4/igmp: init group mode as INCLUDE when
      join source group". From RFC3810, part 6.1:
      
         If no per-interface state existed for that
         multicast address before the change (i.e., the change consisted of
         creating a new per-interface record), or if no state exists after the
         change (i.e., the change consisted of deleting a per-interface
         record), then the "non-existent" state is considered to have an
         INCLUDE filter mode and an empty source list.
      
      Which means a new multicast group should start with state IN(). Currently,
      for MLDv2 SSM JOIN_SOURCE_GROUP mode, we first call ipv6_sock_mc_join(),
      then ip6_mc_source(), which will trigger a TO_IN() message instead of
      ALLOW().
      
      The issue was exposed by commit a052517a ("net/multicast: should not
      send source list records when have filter mode change"). Before this change,
      we sent both ALLOW(A) and TO_IN(A). Now, we only send TO_IN(A).
      
      Fix it by adding a new parameter to init group mode. Also add some wrapper
      functions to avoid changing too much code.
      
      v1 -> v2:
      In the first version I only cleared the group change record. But this is not
      enough. Because when a new group join, it will init as EXCLUDE and trigger
      a filter mode change in ip/ip6_mc_add_src(), which will clear all source
      addresses sf_crcount. This will prevent early joined address sending state
      change records if multi source addressed joined at the same time.
      
      In v2 patch, I fixed it by directly initializing the mode to INCLUDE for SSM
      JOIN_SOURCE_GROUP. I also split the original patch into two separated patches
      for IPv4 and IPv6.
      
      There is also a difference between v4 and v6 version. For IPv6, when the
      interface goes down and up, we will send correct state change record with
      unspecified IPv6 address (::) with function ipv6_mc_up(). But after DAD is
      completed, we resend the change record TO_IN() in mld_send_initial_cr().
      Fix it by sending ALLOW() for INCLUDE mode in mld_send_initial_cr().
      
      Fixes: a052517a ("net/multicast: should not send source list records when have filter mode change")
      Reviewed-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c7ea20c9
    • Hangbin Liu's avatar
      ipv4/igmp: init group mode as INCLUDE when join source group · 6e2059b5
      Hangbin Liu authored
      Based on RFC3376 5.1
         If no interface
         state existed for that multicast address before the change (i.e., the
         change consisted of creating a new per-interface record), or if no
         state exists after the change (i.e., the change consisted of deleting
         a per-interface record), then the "non-existent" state is considered
         to have a filter mode of INCLUDE and an empty source list.
      
      Which means a new multicast group should start with state IN().
      
      Function ip_mc_join_group() works correctly for IGMP ASM(Any-Source Multicast)
      mode. It adds a group with state EX() and inits crcount to mc_qrv,
      so the kernel will send a TO_EX() report message after adding group.
      
      But for IGMPv3 SSM(Source-specific multicast) JOIN_SOURCE_GROUP mode, we
      split the group joining into two steps. First we join the group like ASM,
      i.e. via ip_mc_join_group(). So the state changes from IN() to EX().
      
      Then we add the source-specific address with INCLUDE mode. So the state
      changes from EX() to IN(A).
      
      Before the first step sends a group change record, we finished the second
      step. So we will only send the second change record. i.e. TO_IN(A).
      
      Regarding the RFC stands, we should actually send an ALLOW(A) message for
      SSM JOIN_SOURCE_GROUP as the state should mimic the 'IN() to IN(A)'
      transition.
      
      The issue was exposed by commit a052517a ("net/multicast: should not
      send source list records when have filter mode change"). Before this change,
      we used to send both ALLOW(A) and TO_IN(A). After this change we only send
      TO_IN(A).
      
      Fix it by adding a new parameter to init group mode. Also add new wrapper
      functions so we don't need to change too much code.
      
      v1 -> v2:
      In my first version I only cleared the group change record. But this is not
      enough. Because when a new group join, it will init as EXCLUDE and trigger
      an filter mode change in ip/ip6_mc_add_src(), which will clear all source
      addresses' sf_crcount. This will prevent early joined address sending state
      change records if multi source addressed joined at the same time.
      
      In v2 patch, I fixed it by directly initializing the mode to INCLUDE for SSM
      JOIN_SOURCE_GROUP. I also split the original patch into two separated patches
      for IPv4 and IPv6.
      
      Fixes: a052517a ("net/multicast: should not send source list records when have filter mode change")
      Reviewed-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Signed-off-by: default avatarHangbin Liu <liuhangbin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6e2059b5
  3. 14 Jul, 2018 3 commits
    • David S. Miller's avatar
      Merge branch 'fix-DCTCP-delayed-ACK' · 6bed5e26
      David S. Miller authored
      Yuchung Cheng says:
      
      ====================
      fix DCTCP delayed ACK
      
      This patch series addresses the issue that sometimes DCTCP
      fail to acknowledge the latest sequence and result in sender timeout
      if inflight is small.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6bed5e26
    • Yuchung Cheng's avatar
      tcp: remove DELAYED ACK events in DCTCP · a69258f7
      Yuchung Cheng authored
      After fixing the way DCTCP tracking delayed ACKs, the delayed-ACK
      related callbacks are no longer needed
      Signed-off-by: default avatarYuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Acked-by: default avatarNeal Cardwell <ncardwell@google.com>
      Acked-by: default avatarLawrence Brakmo <brakmo@fb.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a69258f7
    • Yuchung Cheng's avatar
      tcp: fix dctcp delayed ACK schedule · b0c05d0e
      Yuchung Cheng authored
      Previously, when a data segment was sent an ACK was piggybacked
      on the data segment without generating a CA_EVENT_NON_DELAYED_ACK
      event to notify congestion control modules. So the DCTCP
      ca->delayed_ack_reserved flag could incorrectly stay set when
      in fact there were no delayed ACKs being reserved. This could result
      in sending a special ECN notification ACK that carries an older
      ACK sequence, when in fact there was no need for such an ACK.
      DCTCP keeps track of the delayed ACK status with its own separate
      state ca->delayed_ack_reserved. Previously it may accidentally cancel
      the delayed ACK without updating this field upon sending a special
      ACK that carries a older ACK sequence. This inconsistency would
      lead to DCTCP receiver never acknowledging the latest data until the
      sender times out and retry in some cases.
      
      Packetdrill script (provided by Larry Brakmo)
      
      0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
      0.000 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
      0.000 setsockopt(3, SOL_TCP, TCP_CONGESTION, "dctcp", 5) = 0
      0.000 bind(3, ..., ...) = 0
      0.000 listen(3, 1) = 0
      
      0.100 < [ect0] SEW 0:0(0) win 32792 <mss 1000,sackOK,nop,nop,nop,wscale 7>
      0.100 > SE. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 8>
      0.110 < [ect0] . 1:1(0) ack 1 win 257
      0.200 accept(3, ..., ...) = 4
      
      0.200 < [ect0] . 1:1001(1000) ack 1 win 257
      0.200 > [ect01] . 1:1(0) ack 1001
      
      0.200 write(4, ..., 1) = 1
      0.200 > [ect01] P. 1:2(1) ack 1001
      
      0.200 < [ect0] . 1001:2001(1000) ack 2 win 257
      0.200 write(4, ..., 1) = 1
      0.200 > [ect01] P. 2:3(1) ack 2001
      
      0.200 < [ect0] . 2001:3001(1000) ack 3 win 257
      0.200 < [ect0] . 3001:4001(1000) ack 3 win 257
      0.200 > [ect01] . 3:3(0) ack 4001
      
      0.210 < [ce] P. 4001:4501(500) ack 3 win 257
      
      +0.001 read(4, ..., 4500) = 4500
      +0 write(4, ..., 1) = 1
      +0 > [ect01] PE. 3:4(1) ack 4501
      
      +0.010 < [ect0] W. 4501:5501(1000) ack 4 win 257
      // Previously the ACK sequence below would be 4501, causing a long RTO
      +0.040~+0.045 > [ect01] . 4:4(0) ack 5501   // delayed ack
      
      +0.311 < [ect0] . 5501:6501(1000) ack 4 win 257  // More data
      +0 > [ect01] . 4:4(0) ack 6501     // now acks everything
      
      +0.500 < F. 9501:9501(0) ack 4 win 257
      Reported-by: default avatarLarry Brakmo <brakmo@fb.com>
      Signed-off-by: default avatarYuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Acked-by: default avatarNeal Cardwell <ncardwell@google.com>
      Acked-by: default avatarLawrence Brakmo <brakmo@fb.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b0c05d0e