1. 20 Feb, 2020 16 commits
    • Tim Harvey's avatar
      net: thunderx: workaround BGX TX Underflow issue · 971617c3
      Tim Harvey authored
      While it is not yet understood why a TX underflow can easily occur
      for SGMII interfaces resulting in a TX wedge. It has been found that
      disabling/re-enabling the LMAC resolves the issue.
      Signed-off-by: default avatarTim Harvey <tharvey@gateworks.com>
      Reviewed-by: default avatarRobert Jones <rjones@gateworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      971617c3
    • Shannon Nelson's avatar
      ionic: fix fw_status read · 68b759a7
      Shannon Nelson authored
      The fw_status field is only 8 bits, so fix the read.  Also,
      we only want to look at the one status bit, to allow for future
      use of the other bits, and watch for a bad PCI read.
      
      Fixes: 97ca4865 ("ionic: add heartbeat check")
      Signed-off-by: default avatarShannon Nelson <snelson@pensando.io>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      68b759a7
    • Roman Kiryanov's avatar
      net: disable BRIDGE_NETFILTER by default · 98bda63e
      Roman Kiryanov authored
      The description says 'If unsure, say N.' but
      the module is built as M by default (once
      the dependencies are satisfied).
      
      When the module is selected (Y or M), it enables
      NETFILTER_FAMILY_BRIDGE and SKB_EXTENSIONS
      which alter kernel internal structures.
      
      We (Android Studio Emulator) currently do not
      use this module and think this it is more consistent
      to have it disabled by default as opposite to
      disabling it explicitly to prevent enabling
      NETFILTER_FAMILY_BRIDGE and SKB_EXTENSIONS.
      Signed-off-by: default avatarRoman Kiryanov <rkir@google.com>
      Acked-by: default avatarFlorian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      98bda63e
    • Alexandre Belloni's avatar
      net: macb: Properly handle phylink on at91rm9200 · ac2fcfa9
      Alexandre Belloni authored
      at91ether_init was handling the phy mode and speed but since the switch to
      phylink, the NCFGR register got overwritten by macb_mac_config(). The issue
      is that the RM9200_RMII bit and the MACB_CLK_DIV32 field are cleared
      but never restored as they conflict with the PAE, GBE and PCSSEL bits.
      
      Add new capability to differentiate between EMAC and the other versions of
      the IP and use it to set and avoid clearing the relevant bits.
      
      Also, this fixes a NULL pointer dereference in macb_mac_link_up as the EMAC
      doesn't use any rings/bufffers/queues.
      
      Fixes: 7897b071 ("net: macb: convert to phylink")
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@bootlin.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ac2fcfa9
    • David S. Miller's avatar
      Merge branch 's390-fixes' · 0d5b8d70
      David S. Miller authored
      Julian Wiedmann says:
      
      ====================
      s390/qeth: fixes 2020-02-20
      
      please apply the following patch series for qeth to netdev's net tree.
      
      This corrects three minor issues:
      1) return a more fitting errno when VNICC cmds are not supported,
      2) remove a bogus WARN in the NAPI code, and
      3) be _very_ pedantic about the RX copybreak.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0d5b8d70
    • Julian Wiedmann's avatar
      s390/qeth: fix off-by-one in RX copybreak check · 54a61fbc
      Julian Wiedmann authored
      The RX copybreak is intended as the _max_ value where the frame's data
      should be copied. So for frame_len == copybreak, don't build an SG skb.
      
      Fixes: 4a71df50 ("qeth: new qeth device driver")
      Signed-off-by: default avatarJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      54a61fbc
    • Julian Wiedmann's avatar
      s390/qeth: don't warn for napi with 0 budget · 420579db
      Julian Wiedmann authored
      Calling napi->poll() with 0 budget is a legitimate use by netpoll.
      
      Fixes: a1c3ed4c ("qeth: NAPI support for l2 and l3 discipline")
      Signed-off-by: default avatarJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      420579db
    • Alexandra Winter's avatar
      s390/qeth: vnicc Fix EOPNOTSUPP precedence · 6f3846f0
      Alexandra Winter authored
      When getting or setting VNICC parameters, the error code EOPNOTSUPP
      should have precedence over EBUSY.
      
      EBUSY is used because vnicc feature and bridgeport feature are mutually
      exclusive, which is a temporary condition.
      Whereas EOPNOTSUPP indicates that the HW does not support all or parts of
      the vnicc feature.
      This issue causes the vnicc sysfs params to show 'blocked by bridgeport'
      for HW that does not support VNICC at all.
      
      Fixes: caa1f0b1 ("s390/qeth: add VNICC enable/disable support")
      Signed-off-by: default avatarAlexandra Winter <wintera@linux.ibm.com>
      Signed-off-by: default avatarJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6f3846f0
    • Kees Cook's avatar
      openvswitch: Distribute switch variables for initialization · 16a556ee
      Kees Cook authored
      Variables declared in a switch statement before any case statements
      cannot be automatically initialized with compiler instrumentation (as
      they are not part of any execution flow). With GCC's proposed automatic
      stack variable initialization feature, this triggers a warning (and they
      don't get initialized). Clang's automatic stack variable initialization
      (via CONFIG_INIT_STACK_ALL=y) doesn't throw a warning, but it also
      doesn't initialize such variables[1]. Note that these warnings (or silent
      skipping) happen before the dead-store elimination optimization phase,
      so even when the automatic initializations are later elided in favor of
      direct initializations, the warnings remain.
      
      To avoid these problems, move such variables into the "case" where
      they're used or lift them up into the main function body.
      
      net/openvswitch/flow_netlink.c: In function ‘validate_set’:
      net/openvswitch/flow_netlink.c:2711:29: warning: statement will never be executed [-Wswitch-unreachable]
       2711 |  const struct ovs_key_ipv4 *ipv4_key;
            |                             ^~~~~~~~
      
      [1] https://bugs.llvm.org/show_bug.cgi?id=44916Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      16a556ee
    • Kees Cook's avatar
      net: ip6_gre: Distribute switch variables for initialization · 46d30cb1
      Kees Cook authored
      Variables declared in a switch statement before any case statements
      cannot be automatically initialized with compiler instrumentation (as
      they are not part of any execution flow). With GCC's proposed automatic
      stack variable initialization feature, this triggers a warning (and they
      don't get initialized). Clang's automatic stack variable initialization
      (via CONFIG_INIT_STACK_ALL=y) doesn't throw a warning, but it also
      doesn't initialize such variables[1]. Note that these warnings (or silent
      skipping) happen before the dead-store elimination optimization phase,
      so even when the automatic initializations are later elided in favor of
      direct initializations, the warnings remain.
      
      To avoid these problems, move such variables into the "case" where
      they're used or lift them up into the main function body.
      
      net/ipv6/ip6_gre.c: In function ‘ip6gre_err’:
      net/ipv6/ip6_gre.c:440:32: warning: statement will never be executed [-Wswitch-unreachable]
        440 |   struct ipv6_tlv_tnl_enc_lim *tel;
            |                                ^~~
      
      net/ipv6/ip6_tunnel.c: In function ‘ip6_tnl_err’:
      net/ipv6/ip6_tunnel.c:520:32: warning: statement will never be executed [-Wswitch-unreachable]
        520 |   struct ipv6_tlv_tnl_enc_lim *tel;
            |                                ^~~
      
      [1] https://bugs.llvm.org/show_bug.cgi?id=44916Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      46d30cb1
    • Kees Cook's avatar
      net: core: Distribute switch variables for initialization · 161d1792
      Kees Cook authored
      Variables declared in a switch statement before any case statements
      cannot be automatically initialized with compiler instrumentation (as
      they are not part of any execution flow). With GCC's proposed automatic
      stack variable initialization feature, this triggers a warning (and they
      don't get initialized). Clang's automatic stack variable initialization
      (via CONFIG_INIT_STACK_ALL=y) doesn't throw a warning, but it also
      doesn't initialize such variables[1]. Note that these warnings (or silent
      skipping) happen before the dead-store elimination optimization phase,
      so even when the automatic initializations are later elided in favor of
      direct initializations, the warnings remain.
      
      To avoid these problems, move such variables into the "case" where
      they're used or lift them up into the main function body.
      
      net/core/skbuff.c: In function ‘skb_checksum_setup_ip’:
      net/core/skbuff.c:4809:7: warning: statement will never be executed [-Wswitch-unreachable]
       4809 |   int err;
            |       ^~~
      
      [1] https://bugs.llvm.org/show_bug.cgi?id=44916Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      161d1792
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf · 41f57cfd
      David S. Miller authored
      Alexei Starovoitov says:
      
      ====================
      pull-request: bpf 2020-02-19
      
      The following pull-request contains BPF updates for your *net* tree.
      
      We've added 10 non-merge commits during the last 10 day(s) which contain
      a total of 10 files changed, 93 insertions(+), 31 deletions(-).
      
      The main changes are:
      
      1) batched bpf hashtab fixes from Brian and Yonghong.
      
      2) various selftests and libbpf fixes.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      41f57cfd
    • David S. Miller's avatar
      Merge branch '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-queue · fca07a93
      David S. Miller authored
      Jeff Kirsher says:
      
      ====================
      Intel Wired LAN Driver Updates 2020-02-19
      
      This series contains fixes to the ice driver.
      
      Brett fixes an issue where if a user sets an odd [tx|rx]-usecs value
      through ethtool, the request is denied because the hardware is set to
      have an ITR with 2us granularity.  Also fix an issue where the VF has
      not been completely removed/reset after being unbound from the host
      driver, so resolve this by waiting for the VF remove/reset process to
      happen before checking if the VF is disabled.
      
      Michal fixes an issue, where when the user changes flow control via
      ethtool, the OS is told the link is going down when that may not be the
      case.  Before the fix, the only way to get out of this state was to take
      the interface down and up again.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fca07a93
    • Willem de Bruijn's avatar
      udp: rehash on disconnect · 303d0403
      Willem de Bruijn authored
      As of the below commit, udp sockets bound to a specific address can
      coexist with one bound to the any addr for the same port.
      
      The commit also phased out the use of socket hashing based only on
      port (hslot), in favor of always hashing on {addr, port} (hslot2).
      
      The change broke the following behavior with disconnect (AF_UNSPEC):
      
          server binds to 0.0.0.0:1337
          server connects to 127.0.0.1:80
          server disconnects
          client connects to 127.0.0.1:1337
          client sends "hello"
          server reads "hello"	// times out, packet did not find sk
      
      On connect the server acquires a specific source addr suitable for
      routing to its destination. On disconnect it reverts to the any addr.
      
      The connect call triggers a rehash to a different hslot2. On
      disconnect, add the same to return to the original hslot2.
      
      Skip this step if the socket is going to be unhashed completely.
      
      Fixes: 4cdeeee9 ("net: udp: prefer listeners bound to an address")
      Reported-by: default avatarPavel Roskin <plroskin@gmail.com>
      Signed-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      303d0403
    • Rohit Maheshwari's avatar
      net/tls: Fix to avoid gettig invalid tls record · 06f5201c
      Rohit Maheshwari authored
      Current code doesn't check if tcp sequence number is starting from (/after)
      1st record's start sequnce number. It only checks if seq number is before
      1st record's end sequnce number. This problem will always be a possibility
      in re-transmit case. If a record which belongs to a requested seq number is
      already deleted, tls_get_record will start looking into list and as per the
      check it will look if seq number is before the end seq of 1st record, which
      will always be true and will return 1st record always, it should in fact
      return NULL.
      As part of the fix, start looking each record only if the sequence number
      lies in the list else return NULL.
      There is one more check added, driver look for the start marker record to
      handle tcp packets which are before the tls offload start sequence number,
      hence return 1st record if the record is tls start marker and seq number is
      before the 1st record's starting sequence number.
      
      Fixes: e8f69799 ("net/tls: Add generic NIC offload infrastructure")
      Signed-off-by: default avatarRohit Maheshwari <rohitm@chelsio.com>
      Reviewed-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      06f5201c
    • Yonghong Song's avatar
      bpf: Fix a potential deadlock with bpf_map_do_batch · b9aff38d
      Yonghong Song authored
      Commit 05799638 ("bpf: Add batch ops to all htab bpf map")
      added lookup_and_delete batch operation for hash table.
      The current implementation has bpf_lru_push_free() inside
      the bucket lock, which may cause a deadlock.
      
      syzbot reports:
         -> #2 (&htab->buckets[i].lock#2){....}:
             __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
             _raw_spin_lock_irqsave+0x95/0xcd kernel/locking/spinlock.c:159
             htab_lru_map_delete_node+0xce/0x2f0 kernel/bpf/hashtab.c:593
             __bpf_lru_list_shrink_inactive kernel/bpf/bpf_lru_list.c:220 [inline]
             __bpf_lru_list_shrink+0xf9/0x470 kernel/bpf/bpf_lru_list.c:266
             bpf_lru_list_pop_free_to_local kernel/bpf/bpf_lru_list.c:340 [inline]
             bpf_common_lru_pop_free kernel/bpf/bpf_lru_list.c:447 [inline]
             bpf_lru_pop_free+0x87c/0x1670 kernel/bpf/bpf_lru_list.c:499
             prealloc_lru_pop+0x2c/0xa0 kernel/bpf/hashtab.c:132
             __htab_lru_percpu_map_update_elem+0x67e/0xa90 kernel/bpf/hashtab.c:1069
             bpf_percpu_hash_update+0x16e/0x210 kernel/bpf/hashtab.c:1585
             bpf_map_update_value.isra.0+0x2d7/0x8e0 kernel/bpf/syscall.c:181
             generic_map_update_batch+0x41f/0x610 kernel/bpf/syscall.c:1319
             bpf_map_do_batch+0x3f5/0x510 kernel/bpf/syscall.c:3348
             __do_sys_bpf+0x9b7/0x41e0 kernel/bpf/syscall.c:3460
             __se_sys_bpf kernel/bpf/syscall.c:3355 [inline]
             __x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:3355
             do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
             entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
         -> #0 (&loc_l->lock){....}:
             check_prev_add kernel/locking/lockdep.c:2475 [inline]
             check_prevs_add kernel/locking/lockdep.c:2580 [inline]
             validate_chain kernel/locking/lockdep.c:2970 [inline]
             __lock_acquire+0x2596/0x4a00 kernel/locking/lockdep.c:3954
             lock_acquire+0x190/0x410 kernel/locking/lockdep.c:4484
             __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
             _raw_spin_lock_irqsave+0x95/0xcd kernel/locking/spinlock.c:159
             bpf_common_lru_push_free kernel/bpf/bpf_lru_list.c:516 [inline]
             bpf_lru_push_free+0x250/0x5b0 kernel/bpf/bpf_lru_list.c:555
             __htab_map_lookup_and_delete_batch+0x8d4/0x1540 kernel/bpf/hashtab.c:1374
             htab_lru_map_lookup_and_delete_batch+0x34/0x40 kernel/bpf/hashtab.c:1491
             bpf_map_do_batch+0x3f5/0x510 kernel/bpf/syscall.c:3348
             __do_sys_bpf+0x1f7d/0x41e0 kernel/bpf/syscall.c:3456
             __se_sys_bpf kernel/bpf/syscall.c:3355 [inline]
             __x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:3355
             do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
             entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
          Possible unsafe locking scenario:
      
                CPU0                    CPU2
                ----                    ----
           lock(&htab->buckets[i].lock#2);
                                        lock(&l->lock);
                                        lock(&htab->buckets[i].lock#2);
           lock(&loc_l->lock);
      
          *** DEADLOCK ***
      
      To fix the issue, for htab_lru_map_lookup_and_delete_batch() in CPU0,
      let us do bpf_lru_push_free() out of the htab bucket lock. This can
      avoid the above deadlock scenario.
      
      Fixes: 05799638 ("bpf: Add batch ops to all htab bpf map")
      Reported-by: syzbot+a38ff3d9356388f2fb83@syzkaller.appspotmail.com
      Reported-by: syzbot+122b5421d14e68f29cd1@syzkaller.appspotmail.com
      Suggested-by: default avatarHillf Danton <hdanton@sina.com>
      Suggested-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: default avatarYonghong Song <yhs@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Reviewed-by: default avatarJakub Sitnicki <jakub@cloudflare.com>
      Acked-by: default avatarBrian Vazquez <brianvv@google.com>
      Acked-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Link: https://lore.kernel.org/bpf/20200219234757.3544014-1-yhs@fb.com
      b9aff38d
  2. 19 Feb, 2020 15 commits
  3. 18 Feb, 2020 9 commits