1. 12 Sep, 2020 3 commits
  2. 11 Sep, 2020 1 commit
  3. 10 Sep, 2020 22 commits
  4. 09 Sep, 2020 14 commits
    • Vinicius Costa Gomes's avatar
      igc: Fix not considering the TX delay for timestamps · 4406e977
      Vinicius Costa Gomes authored
      When timestamping a packet there's a delay between the start of the
      packet and the point where the hardware actually captures the
      timestamp. This difference needs to be considered if we want accurate
      timestamps.
      
      This was done on the RX side, but not on the TX side.
      
      Fixes: 2c344ae2 ("igc: Add support for TX timestamping")
      Signed-off-by: default avatarVinicius Costa Gomes <vinicius.gomes@intel.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      4406e977
    • Vinicius Costa Gomes's avatar
      igc: Fix wrong timestamp latency numbers · f03369b9
      Vinicius Costa Gomes authored
      The previous timestamping latency numbers were obtained by
      interpolating the i210 numbers with the i225 crystal clock value. That
      calculation was wrong.
      
      Use the correct values from real measurements.
      
      Fixes: 81b05520 ("igc: Add support for RX timestamping")
      Signed-off-by: default avatarVinicius Costa Gomes <vinicius.gomes@intel.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      f03369b9
    • Stefan Assmann's avatar
      i40e: always propagate error value in i40e_set_vsi_promisc() · b6f23d38
      Stefan Assmann authored
      The for loop in i40e_set_vsi_promisc() reports errors via dev_err() but
      does not propagate the error up the call chain. Instead it continues the
      loop and potentially overwrites the reported error value.
      This results in the error being recorded in the log buffer, but the
      caller might never know anything went the wrong way.
      
      To avoid this situation i40e_set_vsi_promisc() needs to temporarily store
      the error after reporting it. This is still not optimal as multiple
      different errors may occur, so store the first error and hope that's
      the main issue.
      
      Fixes: 37d318d7 (i40e: Remove scheduling while atomic possibility)
      Reported-by: default avatarMichal Schmidt <mschmidt@redhat.com>
      Signed-off-by: default avatarStefan Assmann <sassmann@kpanic.de>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      b6f23d38
    • Stefan Assmann's avatar
      i40e: fix return of uninitialized aq_ret in i40e_set_vsi_promisc · e1e1b535
      Stefan Assmann authored
      drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c: In function ‘i40e_set_vsi_promisc’:
      drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:1176:14: error: ‘aq_ret’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
        i40e_status aq_ret;
      
      In case the code inside the if statement and the for loop does not get
      executed aq_ret will be uninitialized when the variable gets returned at
      the end of the function.
      
      Avoid this by changing num_vlans from int to u16, so aq_ret always gets
      set. Making this change in additional places as num_vlans should never
      be negative.
      
      Fixes: 37d318d7 ("i40e: Remove scheduling while atomic possibility")
      Signed-off-by: default avatarStefan Assmann <sassmann@kpanic.de>
      Acked-by: default avatarJakub Kicinski <kuba@kernel.org>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarTony Nguyen <anthony.l.nguyen@intel.com>
      e1e1b535
    • David S. Miller's avatar
      Merge branch 'net-qed-disable-aRFS-in-NPAR-and-100G' · 9b29e26f
      David S. Miller authored
      Igor Russkikh says:
      
      ====================
      net: qed disable aRFS in NPAR and 100G
      
      This patchset fixes some recent issues found by customers.
      
      v3:
        resending on Dmitry's behalf
      
      v2:
        correct hash in Fixes tag
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9b29e26f
    • Dmitry Bogdanov's avatar
      net: qed: RDMA personality shouldn't fail VF load · ce1cf9e5
      Dmitry Bogdanov authored
      Fix the assert during VF driver installation when the personality is iWARP
      
      Fixes: 1fe614d1 ("qed: Relax VF firmware requirements")
      Signed-off-by: default avatarIgor Russkikh <irusskikh@marvell.com>
      Signed-off-by: default avatarMichal Kalderon <michal.kalderon@marvell.com>
      Signed-off-by: default avatarDmitry Bogdanov <dbogdanov@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ce1cf9e5
    • Dmitry Bogdanov's avatar
      net: qede: Disable aRFS for NPAR and 100G · 0367f058
      Dmitry Bogdanov authored
      In some configurations ARFS cannot be used, so disable it if device
      is not capable.
      
      Fixes: e4917d46 ("qede: Add aRFS support")
      Signed-off-by: default avatarManish Chopra <manishc@marvell.com>
      Signed-off-by: default avatarIgor Russkikh <irusskikh@marvell.com>
      Signed-off-by: default avatarMichal Kalderon <michal.kalderon@marvell.com>
      Signed-off-by: default avatarDmitry Bogdanov <dbogdanov@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0367f058
    • Dmitry Bogdanov's avatar
      net: qed: Disable aRFS for NPAR and 100G · 2d2fe843
      Dmitry Bogdanov authored
      In CMT and NPAR the PF is unknown when the GFS block processes the
      packet. Therefore cannot use searcher as it has a per PF database,
      and thus ARFS must be disabled.
      
      Fixes: d51e4af5 ("qed: aRFS infrastructure support")
      Signed-off-by: default avatarManish Chopra <manishc@marvell.com>
      Signed-off-by: default avatarIgor Russkikh <irusskikh@marvell.com>
      Signed-off-by: default avatarMichal Kalderon <michal.kalderon@marvell.com>
      Signed-off-by: default avatarDmitry Bogdanov <dbogdanov@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2d2fe843
    • David S. Miller's avatar
      Merge tag 'wireless-drivers-2020-09-09' of... · a19454b6
      David S. Miller authored
      Merge tag 'wireless-drivers-2020-09-09' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers
      
      Kalle Valo says:
      
      ====================
      wireless-drivers fixes for v5.9
      
      First set of fixes for v5.9, small but important.
      
      brcmfmac
      
      * fix a throughput regression on bcm4329
      
      mt76
      
      * fix a regression with stations reconnecting on mt7616
      
      * properly free tx skbs, it was working by accident before
      
      mwifiex
      
      * fix a regression with 256 bit encryption keys
      
      wlcore
      
      * revert AES CMAC support as it caused a regression
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a19454b6
    • David S. Miller's avatar
      Merge branch 'wireguard-fixes' · 99dc4a5d
      David S. Miller authored
      Jason A. Donenfeld says:
      
      ====================
      wireguard fixes for 5.9-rc5
      
      Yesterday, Eric reported a race condition found by syzbot. This series
      contains two commits, one that fixes the direct issue, and another that
      addresses the more general issue, as a defense in depth.
      
      1) The basic problem syzbot unearthed was that one particular mutation
         of handshake->entry was not protected by the handshake mutex like the
         other cases, so this patch basically just reorders a line to make
         sure the mutex is actually taken at the right point. Most of the work
         here went into making sure the race was fully understood and making a
         reproducer (which syzbot was unable to do itself, due to the rarity
         of the race).
      
      2) Eric's initial suggestion for fixing this was taking a spinlock
         around the hash table replace function where the null ptr deref was
         happening. This doesn't address the main problem in the most precise
         possible way like (1) does, but it is a good suggestion for
         defense-in-depth, in case related issues come up in the future, and
         basically costs nothing from a performance perspective. I thought it
         aided in implementing a good general rule: all mutators of that hash
         table take the table lock. So that's part of this series as a
         companion.
      
      Both of these contain Fixes: tags and are good candidates for stable.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      99dc4a5d
    • Jason A. Donenfeld's avatar
      wireguard: peerlookup: take lock before checking hash in replace operation · 6147f7b1
      Jason A. Donenfeld authored
      Eric's suggested fix for the previous commit's mentioned race condition
      was to simply take the table->lock in wg_index_hashtable_replace(). The
      table->lock of the hash table is supposed to protect the bucket heads,
      not the entires, but actually, since all the mutator functions are
      already taking it, it makes sense to take it too for the test to
      hlist_unhashed, as a defense in depth measure, so that it no longer
      races with deletions, regardless of what other locks are protecting
      individual entries. This is sensible from a performance perspective
      because, as Eric pointed out, the case of being unhashed is already the
      unlikely case, so this won't add common contention. And comparing
      instructions, this basically doesn't make much of a difference other
      than pushing and popping %r13, used by the new `bool ret`. More
      generally, I like the idea of locking consistency across table mutator
      functions, and this might let me rest slightly easier at night.
      Suggested-by: default avatarEric Dumazet <edumazet@google.com>
      Link: https://lore.kernel.org/wireguard/20200908145911.4090480-1-edumazet@google.com/
      Fixes: e7096c13 ("net: WireGuard secure network tunnel")
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6147f7b1
    • Jason A. Donenfeld's avatar
      wireguard: noise: take lock when removing handshake entry from table · 9179ba31
      Jason A. Donenfeld authored
      Eric reported that syzkaller found a race of this variety:
      
      CPU 1                                       CPU 2
      -------------------------------------------|---------------------------------------
      wg_index_hashtable_replace(old, ...)       |
        if (hlist_unhashed(&old->index_hash))    |
                                                 | wg_index_hashtable_remove(old)
                                                 |   hlist_del_init_rcu(&old->index_hash)
      				           |     old->index_hash.pprev = NULL
        hlist_replace_rcu(&old->index_hash, ...) |
          *old->index_hash.pprev                 |
      
      Syzbot wasn't actually able to reproduce this more than once or create a
      reproducer, because the race window between checking "hlist_unhashed" and
      calling "hlist_replace_rcu" is just so small. Adding an mdelay(5) or
      similar there helps make this demonstrable using this simple script:
      
          #!/bin/bash
          set -ex
          trap 'kill $pid1; kill $pid2; ip link del wg0; ip link del wg1' EXIT
          ip link add wg0 type wireguard
          ip link add wg1 type wireguard
          wg set wg0 private-key <(wg genkey) listen-port 9999
          wg set wg1 private-key <(wg genkey) peer $(wg show wg0 public-key) endpoint 127.0.0.1:9999 persistent-keepalive 1
          wg set wg0 peer $(wg show wg1 public-key)
          ip link set wg0 up
          yes link set wg1 up | ip -force -batch - &
          pid1=$!
          yes link set wg1 down | ip -force -batch - &
          pid2=$!
          wait
      
      The fundumental underlying problem is that we permit calls to wg_index_
      hashtable_remove(handshake.entry) without requiring the caller to take
      the handshake mutex that is intended to protect members of handshake
      during mutations. This is consistently the case with calls to wg_index_
      hashtable_insert(handshake.entry) and wg_index_hashtable_replace(
      handshake.entry), but it's missing from a pertinent callsite of wg_
      index_hashtable_remove(handshake.entry). So, this patch makes sure that
      mutex is taken.
      
      The original code was a little bit funky though, in the form of:
      
          remove(handshake.entry)
          lock(), memzero(handshake.some_members), unlock()
          remove(handshake.entry)
      
      The original intention of that double removal pattern outside the lock
      appears to be some attempt to prevent insertions that might happen while
      locks are dropped during expensive crypto operations, but actually, all
      callers of wg_index_hashtable_insert(handshake.entry) take the write
      lock and then explicitly check handshake.state, as they should, which
      the aforementioned memzero clears, which means an insertion should
      already be impossible. And regardless, the original intention was
      necessarily racy, since it wasn't guaranteed that something else would
      run after the unlock() instead of after the remove(). So, from a
      soundness perspective, it seems positive to remove what looks like a
      hack at best.
      
      The crash from both syzbot and from the script above is as follows:
      
        general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN
        KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
        CPU: 0 PID: 7395 Comm: kworker/0:3 Not tainted 5.9.0-rc4-syzkaller #0
        Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
        Workqueue: wg-kex-wg1 wg_packet_handshake_receive_worker
        RIP: 0010:hlist_replace_rcu include/linux/rculist.h:505 [inline]
        RIP: 0010:wg_index_hashtable_replace+0x176/0x330 drivers/net/wireguard/peerlookup.c:174
        Code: 00 fc ff df 48 89 f9 48 c1 e9 03 80 3c 01 00 0f 85 44 01 00 00 48 b9 00 00 00 00 00 fc ff df 48 8b 45 10 48 89 c6 48 c1 ee 03 <80> 3c 0e 00 0f 85 06 01 00 00 48 85 d2 4c 89 28 74 47 e8 a3 4f b5
        RSP: 0018:ffffc90006a97bf8 EFLAGS: 00010246
        RAX: 0000000000000000 RBX: ffff888050ffc4f8 RCX: dffffc0000000000
        RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88808e04e010
        RBP: ffff88808e04e000 R08: 0000000000000001 R09: ffff8880543d0000
        R10: ffffed100a87a000 R11: 000000000000016e R12: ffff8880543d0000
        R13: ffff88808e04e008 R14: ffff888050ffc508 R15: ffff888050ffc500
        FS:  0000000000000000(0000) GS:ffff8880ae600000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 00000000f5505db0 CR3: 0000000097cf7000 CR4: 00000000001526f0
        DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
        DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
        Call Trace:
        wg_noise_handshake_begin_session+0x752/0xc9a drivers/net/wireguard/noise.c:820
        wg_receive_handshake_packet drivers/net/wireguard/receive.c:183 [inline]
        wg_packet_handshake_receive_worker+0x33b/0x730 drivers/net/wireguard/receive.c:220
        process_one_work+0x94c/0x1670 kernel/workqueue.c:2269
        worker_thread+0x64c/0x1120 kernel/workqueue.c:2415
        kthread+0x3b5/0x4a0 kernel/kthread.c:292
        ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Reported-by: default avatarEric Dumazet <edumazet@google.com>
      Link: https://lore.kernel.org/wireguard/20200908145911.4090480-1-edumazet@google.com/
      Fixes: e7096c13 ("net: WireGuard secure network tunnel")
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9179ba31
    • Ye Bin's avatar
      hsr: avoid newline at end of message in NL_SET_ERR_MSG_MOD · b87f9fe1
      Ye Bin authored
      clean follow coccicheck warning:
      net//hsr/hsr_netlink.c:94:8-42: WARNING avoid newline at end of message
      in NL_SET_ERR_MSG_MOD
      net//hsr/hsr_netlink.c:87:30-57: WARNING avoid newline at end of message
      in NL_SET_ERR_MSG_MOD
      net//hsr/hsr_netlink.c:79:29-53: WARNING avoid newline at end of message
      in NL_SET_ERR_MSG_MOD
      Signed-off-by: default avatarYe Bin <yebin10@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b87f9fe1
    • David S. Miller's avatar
      Merge branch 'net-skb_put_padto-fixes' · 0ddaa278
      David S. Miller authored
      Eric Dumazet says:
      
      ====================
      net: skb_put_padto() fixes
      
      sysbot reported a bug in qrtr leading to use-after-free.
      
      First patch fixes the issue.
      
      Second patch addes __must_check attribute to avoid similar
      issues in the future.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0ddaa278