1. 16 Jul, 2018 23 commits
    • 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
  2. 14 Jul, 2018 5 commits
  3. 13 Jul, 2018 7 commits
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf · c849eb0d
      David S. Miller authored
      Daniel Borkmann says:
      
      ====================
      pull-request: bpf 2018-07-13
      
      The following pull-request contains BPF updates for your *net* tree.
      
      The main changes are:
      
      1) Fix AF_XDP TX error reporting before final kernel release such that it
         becomes consistent between copy mode and zero-copy, from Magnus.
      
      2) Fix three different syzkaller reported issues: oob due to ld_abs
         rewrite with too large offset, another oob in l3 based skb test run
         and a bug leaving mangled prog in subprog JITing error path, from Daniel.
      
      3) Fix BTF handling for bitfield extraction on big endian, from Okash.
      
      4) Fix a missing linux/errno.h include in cgroup/BPF found by kbuild bot,
         from Roman.
      
      5) Fix xdp2skb_meta.sh sample by using just command names instead of
         absolute paths for tc and ip and allow them to be redefined, from Taeung.
      
      6) Fix availability probing for BPF seg6 helpers before final kernel ships
         so they can be detected at prog load time, from Mathieu.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c849eb0d
    • Stefano Brivio's avatar
      skbuff: Unconditionally copy pfmemalloc in __skb_clone() · e78bfb07
      Stefano Brivio authored
      Commit 8b700862 ("net: Don't copy pfmemalloc flag in
      __copy_skb_header()") introduced a different handling for the
      pfmemalloc flag in copy and clone paths.
      
      In __skb_clone(), now, the flag is set only if it was set in the
      original skb, but not cleared if it wasn't. This is wrong and
      might lead to socket buffers being flagged with pfmemalloc even
      if the skb data wasn't allocated from pfmemalloc reserves. Copy
      the flag instead of ORing it.
      Reported-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Fixes: 8b700862 ("net: Don't copy pfmemalloc flag in __copy_skb_header()")
      Signed-off-by: default avatarStefano Brivio <sbrivio@redhat.com>
      Tested-by: default avatarSabrina Dubroca <sd@queasysnail.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e78bfb07
    • Daniel Borkmann's avatar
      Merge branch 'bpf-af-xdp-consistent-err-reporting' · 5e3e6e83
      Daniel Borkmann authored
      Magnus Karlsson says:
      
      ====================
      This patch set adjusts the AF_XDP TX error reporting so that it becomes
      consistent between copy mode and zero-copy. First some background:
      
      Copy-mode for TX uses the SKB path in which the action of sending the
      packet is performed from process context using the sendmsg
      syscall. Completions are usually done asynchronously from NAPI mode by
      using a TX interrupt. In this mode, send errors can be returned back
      through the syscall.
      
      In zero-copy mode both the sending of the packet and the completions
      are done asynchronously from NAPI mode for performance reasons. In
      this mode, the sendmsg syscall only makes sure that the TX NAPI loop
      will be run that performs both the actions of sending and
      completing. In this mode it is therefore not possible to return errors
      through the sendmsg syscall as the sending is done from the NAPI
      loop. Note that it is possible to implement a synchronous send with
      our API, but in our benchmarks that made the TX performance drop by
      nearly half due to synchronization requirements and cache line
      bouncing. But for some netdevs this might be preferable so let us
      leave it up to the implementation to decide.
      
      The problem is that the current code base returns some errors in
      copy-mode that are not possible to return in zero-copy mode. This
      patch set aligns them so that the two modes always return the same
      error code. We achieve this by removing some of the errors returned by
      sendmsg in copy-mode (and in one case adding an error message for
      zero-copy mode) and offering alternative error detection methods that
      are consistent between the two modes.
      
      The structure of the patch set is as follows:
      
      Patch 1: removes the ENXIO return code from copy-mode when someone has
      forcefully changed the number of queues on the device so that the
      queue bound to the socket is no longer available. Just silently stop
      sending anything as in zero-copy mode.
      
      Patch 2: stop returning EAGAIN in copy mode when the completion queue
      is full as zero-copy does not do this. Instead this situation can be
      detected by comparing the head and tail pointers of the completion
      queue in both modes. In any case, EAGAIN was not the correct error code
      here since no amount of calling sendmsg will solve the problem. Only
      consuming one or more messages on the completion queue will fix this.
      
      Patch 3: Always return ENOBUFS from sendmsg if there is no TX queue
      configured. This was not the case for zero-copy mode.
      
      Patch 4: stop returning EMSGSIZE when the size of the packet is larger
      than the MTU. Just send it to the device so that it will drop it as in
      zero-copy mode.
      
      Note that copy-mode can still return EAGAIN in certain circumstances,
      but as these conditions cannot occur in zero-copy mode it is fine for
      copy-mode to return them.
      ====================
      Acked-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      5e3e6e83
    • Magnus Karlsson's avatar
      xsk: do not return EMSGSIZE in copy mode for packets larger than MTU · 09210c4b
      Magnus Karlsson authored
      This patch stops returning EMSGSIZE from sendmsg in copy mode when the
      size of the packet is larger than the MTU. Just send it to the device
      so that it will drop it as in zero-copy mode. This makes the error
      reporting consistent between copy mode and zero-copy mode.
      
      Fixes: 35fcde7f ("xsk: support for Tx")
      Signed-off-by: default avatarMagnus Karlsson <magnus.karlsson@intel.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      09210c4b
    • Magnus Karlsson's avatar
      xsk: always return ENOBUFS from sendmsg if there is no TX queue · 6efb4436
      Magnus Karlsson authored
      This patch makes sure ENOBUFS is always returned from sendmsg if there
      is no TX queue configured. This was not the case for zero-copy
      mode. With this patch this error reporting is consistent between copy
      mode and zero-copy mode.
      
      Fixes: ac98d8aa ("xsk: wire upp Tx zero-copy functions")
      Signed-off-by: default avatarMagnus Karlsson <magnus.karlsson@intel.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      6efb4436
    • Magnus Karlsson's avatar
      xsk: do not return EAGAIN from sendmsg when completion queue is full · 9684f5e7
      Magnus Karlsson authored
      This patch stops returning EAGAIN in TX copy mode when the completion
      queue is full as zero-copy does not do this. Instead this situation
      can be detected by comparing the head and tail pointers of the
      completion queue in both modes. In any case, EAGAIN was not the
      correct error code here since no amount of calling sendmsg will solve
      the problem. Only consuming one or more messages on the completion
      queue will fix this.
      
      With this patch, the error reporting becomes consistent between copy
      mode and zero-copy mode.
      
      Fixes: 35fcde7f ("xsk: support for Tx")
      Signed-off-by: default avatarMagnus Karlsson <magnus.karlsson@intel.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      9684f5e7
    • Magnus Karlsson's avatar
      xsk: do not return ENXIO from TX copy mode · 509d7648
      Magnus Karlsson authored
      This patch removes the ENXIO return code from TX copy-mode when
      someone has forcefully changed the number of queues on the device so
      that the queue bound to the socket is no longer available. Just
      silently stop sending anything as in zero-copy mode so the error
      reporting gets consistent between the two modes.
      
      Fixes: 35fcde7f ("xsk: support for Tx")
      Signed-off-by: default avatarMagnus Karlsson <magnus.karlsson@intel.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      509d7648
  4. 12 Jul, 2018 5 commits