platform/kernel/linux-starfive.git
4 years agonet: wireless: intel: fix wiki website url
Flavio Suligoi [Fri, 5 Jun 2020 15:41:09 +0000 (17:41 +0200)]
net: wireless: intel: fix wiki website url

In some Intel files, the wiki url is still the old
"wireless.kernel.org" instead of the new
"wireless.wiki.kernel.org"

Signed-off-by: Flavio Suligoi <f.suligoi@asem.it>
Link: https://lore.kernel.org/r/20200605154112.16277-7-f.suligoi@asem.it
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
4 years agoiwlwifi: Replace zero-length array with flexible-array
Gustavo A. R. Silva [Thu, 7 May 2020 18:55:38 +0000 (13:55 -0500)]
iwlwifi: Replace zero-length array with flexible-array

The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:

struct foo {
        int stuff;
        struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.

Also, notice that, dynamic memory allocations won't be affected by
this change:

"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]

sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type[1]. There are some instances of code in
which the sizeof operator is being incorrectly/erroneously applied to
zero-length arrays and the result is zero. Such instances may be hiding
some bugs. So, this work (flexible-array member conversions) will also
help to get completely rid of those sorts of issues.

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")

Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20200507185538.GA14674@embeddedor
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
4 years agoiwlwifi: mvm: Remove unused inline function iwl_mvm_tid_to_ac_queue
YueHaibing [Wed, 6 May 2020 13:42:17 +0000 (21:42 +0800)]
iwlwifi: mvm: Remove unused inline function iwl_mvm_tid_to_ac_queue

commit cfbc6c4c5b91 ("iwlwifi: mvm: support mac80211 TXQs model")
left behind this, remove it.

Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20200506134217.49760-1-yuehaibing@huawei.com
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
4 years agoiwlwifi: mvm: fix gcc-10 zero-length-bounds warning
Arnd Bergmann [Thu, 30 Apr 2020 21:30:44 +0000 (23:30 +0200)]
iwlwifi: mvm: fix gcc-10 zero-length-bounds warning

gcc-10 complains when a zero-length array is accessed:

drivers/net/wireless/intel/iwlwifi/mvm/tx.c: In function 'iwl_mvm_rx_ba_notif':
drivers/net/wireless/intel/iwlwifi/mvm/tx.c:1929:17: warning: array subscript 9 is outside the bounds of an interior zero-length array 'struct iwl_mvm_compressed_ba_tfd[0]' [-Wzero-length-bounds]
 1929 |     &ba_res->tfd[i];
      |      ~~~~~~~~~~~^~~
In file included from drivers/net/wireless/intel/iwlwifi/mvm/../fw/api/tdls.h:68,
                 from drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h:68,
                 from drivers/net/wireless/intel/iwlwifi/mvm/sta.h:73,
                 from drivers/net/wireless/intel/iwlwifi/mvm/mvm.h:83,
                 from drivers/net/wireless/intel/iwlwifi/mvm/tx.c:72:
drivers/net/wireless/intel/iwlwifi/mvm/../fw/api/tx.h:769:35: note: while referencing 'tfd'
  769 |  struct iwl_mvm_compressed_ba_tfd tfd[0];
      |                                   ^~~

Change this structure to use a flexible-array member for 'tfd' instead,
along with the various structures using an zero-length ieee80211_hdr
array that do not show warnings today but might be affected by similar
issues in the future.

Fixes: 6f68cc367ab6 ("iwlwifi: api: annotate compressed BA notif array sizes")
Fixes: c46e7724bfe9 ("iwlwifi: mvm: support new BA notification response")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20200430213101.135134-3-arnd@arndb.de
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
4 years agoiwlwifi: mvm: remove redundant assignment to variable ret
Colin Ian King [Mon, 20 Apr 2020 22:24:49 +0000 (23:24 +0100)]
iwlwifi: mvm: remove redundant assignment to variable ret

The variable ret is being assigned with a value that is never read
and it is being updated later with a new value. The initialization is
redundant and can be removed.

Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20200420222449.99481-1-colin.king@canonical.com
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
4 years agoiwlwifi: fix config variable name in comment
Luca Ceresoli [Mon, 10 Feb 2020 13:58:17 +0000 (14:58 +0100)]
iwlwifi: fix config variable name in comment

The correct variable name was replaced here by mistake by commit
ab27926d9e4a ("iwlwifi: fix devices with PCI Device ID 0x34F0 and 11ac RF
modules").

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Link: https://lore.kernel.org/r/20200210135817.31994-1-luca@lucaceresoli.net
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
4 years agoiwlwifi: mvm: Fix avg-power report
Ben Greear [Tue, 26 Nov 2019 21:47:44 +0000 (13:47 -0800)]
iwlwifi: mvm: Fix avg-power report

On AX200, the average power was showing positive instead of negative, but
otherwise matched the expected RSSI.  Flip the value to negative before
 giving to mac80211.

Signed-off-by: Ben Greear <greearb@candelatech.com>
Link: https://lore.kernel.org/r/20191126214744.1283-1-greearb@candelatech.com
[removed unnecessary check and some unnecessary parentheses]
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
4 years agoiwlwifi: Don't IWL_WARN on FW reconfiguration
Chris Down [Thu, 17 Oct 2019 14:48:41 +0000 (10:48 -0400)]
iwlwifi: Don't IWL_WARN on FW reconfiguration

IWL_WARN seems excessive here since this can happen during normal
operation. Every time I connect to a new network with 8086:24fd I get
this as KERN_WARNING on the console, which mildly distracts from other
more pressing messages. For example:

    % sudo journalctl _TRANSPORT=kernel | grep -c 'FW already configured'
    403

Signed-off-by: Chris Down <chris@chrisdown.name>
Cc: Shahar S Matityahu <shahar.s.matityahu@intel.com>
Cc: Luca Coelho <luciano.coelho@intel.com>
Cc: linux-kernel@vger.kernel.org
Cc: linux-wireless@vger.kernel.org
Link: https://lore.kernel.org/r/20191017144841.GA16393@chrisdown.name
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
4 years agoiwlwifi: Extended Key ID support for mvm and dvm
Alexander Wetzel [Mon, 19 Aug 2019 18:05:40 +0000 (20:05 +0200)]
iwlwifi: Extended Key ID support for mvm and dvm

All iwlwifi cards below the 22000 series are able to handle multiple
keyids per STA and allow the selection of the encryption key per MPDU.

These are therefore fully compatible with the Extended Key ID support
implementation in mac80211.

Enable Extended Key ID support for all dvm cards and the mvm cards not
using the incompatible new Tx API introduced for the 22000 series.

Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de>
Link: https://lore.kernel.org/r/20190819180540.2855-1-alexander@wetzel-home.de
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
4 years agoMerge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
David S. Miller [Mon, 1 Jun 2020 00:48:46 +0000 (17:48 -0700)]
Merge git://git./linux/kernel/git/netdev/net

xdp_umem.c had overlapping changes between the 64-bit math fix
for the calculation of npgs and the removal of the zerocopy
memory type which got rid of the chunk_size_nohdr member.

The mlx5 Kconfig conflict is a case where we just take the
net-next copy of the Kconfig entry dependency as it takes on
the ESWITCH dependency by one level of indirection which is
what the 'net' conflicting change is trying to ensure.

Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agoMerge tag 'mac80211-next-for-davem-2020-05-31' of git://git.kernel.org/pub/scm/linux...
David S. Miller [Sun, 31 May 2020 21:32:50 +0000 (14:32 -0700)]
Merge tag 'mac80211-next-for-davem-2020-05-31' of git://git./linux/kernel/git/jberg/mac80211-next

Johannes Berg says:

====================
Another set of changes, including
 * many 6 GHz changes, though it's not _quite_ complete
   (I left out scanning for now, we're still discussing)
 * allow userspace SA-query processing for operating channel
   validation
 * TX status for control port TX, for AP-side operation
 * more per-STA/TID control options
 * move to kHz for channels, for future S1G operation
 * various other small changes
====================

Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agocheckpatch/coding-style: deprecate 80-column warning
Joe Perches [Fri, 29 May 2020 23:12:21 +0000 (16:12 -0700)]
checkpatch/coding-style: deprecate 80-column warning

Yes, staying withing 80 columns is certainly still _preferred_.  But
it's not the hard limit that the checkpatch warnings imply, and other
concerns can most certainly dominate.

Increase the default limit to 100 characters.  Not because 100
characters is some hard limit either, but that's certainly a "what are
you doing" kind of value and less likely to be about the occasional
slightly longer lines.

Miscellanea:

 - to avoid unnecessary whitespace changes in files, checkpatch will no
   longer emit a warning about line length when scanning files unless
   --strict is also used

 - Add a bit to coding-style about alignment to open parenthesis

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
4 years agoMerge tag 'x86-urgent-2020-05-31' of git://git.kernel.org/pub/scm/linux/kernel/git...
Linus Torvalds [Sun, 31 May 2020 17:45:11 +0000 (10:45 -0700)]
Merge tag 'x86-urgent-2020-05-31' of git://git./linux/kernel/git/tip/tip

Pull x86 fixes from Thomas Gleixner:
 "A pile of x86 fixes:

   - Prevent a memory leak in ioperm which was caused by the stupid
     assumption that the exit cleanup is always called for current,
     which is not the case when fork fails after taking a reference on
     the ioperm bitmap.

   - Fix an arithmething overflow in the DMA code on 32bit systems

   - Fill gaps in the xstate copy with defaults instead of leaving them
     uninitialized

   - Revert: "Make __X32_SYSCALL_BIT be unsigned long" as it turned out
     that existing user space fails to build"

* tag 'x86-urgent-2020-05-31' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/ioperm: Prevent a memory leak when fork fails
  x86/dma: Fix max PFN arithmetic overflow on 32 bit systems
  copy_xstate_to_kernel(): don't leave parts of destination uninitialized
  x86/syscalls: Revert "x86/syscalls: Make __X32_SYSCALL_BIT be unsigned long"

4 years agoMerge tag 'sched-urgent-2020-05-31' of git://git.kernel.org/pub/scm/linux/kernel...
Linus Torvalds [Sun, 31 May 2020 17:43:17 +0000 (10:43 -0700)]
Merge tag 'sched-urgent-2020-05-31' of git://git./linux/kernel/git/tip/tip

Pull scheduler fix from Thomas Gleixner:
 "A single scheduler fix preventing a crash in NUMA balancing.

  The current->mm check is not reliable as the mm might be temporary due
  to use_mm() in a kthread. Check for PF_KTHREAD explictly"

* tag 'sched-urgent-2020-05-31' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  sched/fair: Don't NUMA balance for kthreads

4 years agoMerge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
Linus Torvalds [Sun, 31 May 2020 17:16:53 +0000 (10:16 -0700)]
Merge git://git./linux/kernel/git/netdev/net

Pull networking fixes from David Miller:
 "Another week, another set of bug fixes:

   1) Fix pskb_pull length in __xfrm_transport_prep(), from Xin Long.

   2) Fix double xfrm_state put in esp{4,6}_gro_receive(), also from Xin
      Long.

   3) Re-arm discovery timer properly in mac80211 mesh code, from Linus
      Lüssing.

   4) Prevent buffer overflows in nf_conntrack_pptp debug code, from
      Pablo Neira Ayuso.

   5) Fix race in ktls code between tls_sw_recvmsg() and
      tls_decrypt_done(), from Vinay Kumar Yadav.

   6) Fix crashes on TCP fallback in MPTCP code, from Paolo Abeni.

   7) More validation is necessary of untrusted GSO packets coming from
      virtualization devices, from Willem de Bruijn.

   8) Fix endianness of bnxt_en firmware message length accesses, from
      Edwin Peer.

   9) Fix infinite loop in sch_fq_pie, from Davide Caratti.

  10) Fix lockdep splat in DSA by setting lockless TX in netdev features
      for slave ports, from Vladimir Oltean.

  11) Fix suspend/resume crashes in mlx5, from Mark Bloch.

  12) Fix use after free in bpf fmod_ret, from Alexei Starovoitov.

  13) ARP retransmit timer guard uses wrong offset, from Hongbin Liu.

  14) Fix leak in inetdev_init(), from Yang Yingliang.

  15) Don't try to use inet hash and unhash in l2tp code, results in
      crashes. From Eric Dumazet"

* git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (77 commits)
  l2tp: add sk_family checks to l2tp_validate_socket
  l2tp: do not use inet_hash()/inet_unhash()
  net: qrtr: Allocate workqueue before kernel_bind
  mptcp: remove msk from the token container at destruction time.
  mptcp: fix race between MP_JOIN and close
  mptcp: fix unblocking connect()
  net/sched: act_ct: add nat mangle action only for NAT-conntrack
  devinet: fix memleak in inetdev_init()
  virtio_vsock: Fix race condition in virtio_transport_recv_pkt
  drivers/net/ibmvnic: Update VNIC protocol version reporting
  NFC: st21nfca: add missed kfree_skb() in an error path
  neigh: fix ARP retransmit timer guard
  bpf, selftests: Add a verifier test for assigning 32bit reg states to 64bit ones
  bpf, selftests: Verifier bounds tests need to be updated
  bpf: Fix a verifier issue when assigning 32bit reg states to 64bit ones
  bpf: Fix use-after-free in fmod_ret check
  net/mlx5e: replace EINVAL in mlx5e_flower_parse_meta()
  net/mlx5e: Fix MLX5_TC_CT dependencies
  net/mlx5e: Properly set default values when disabling adaptive moderation
  net/mlx5e: Fix arch depending casting issue in FEC
  ...

4 years agocfg80211: support bigger kek/kck key length
Nathan Errera [Thu, 28 May 2020 19:22:38 +0000 (21:22 +0200)]
cfg80211: support bigger kek/kck key length

With some newer AKMs, the KCK and KEK are bigger, so allow that
if the driver advertises support for it. In addition, add a new
attribute for the AKM so we can use it for offloaded rekeying.

Signed-off-by: Nathan Errera <nathan.errera@intel.com>
[reword commit message]
Link: https://lore.kernel.org/r/20200528212237.5eb58b00a5d1.I61b09d77c4f382e8d58a05dcca78096e99a6bc15@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
4 years agomac80211: set short_slot for 6 GHz band
Tova Mussai [Thu, 28 May 2020 19:34:46 +0000 (21:34 +0200)]
mac80211: set short_slot for 6 GHz band

Set short slot also for 6 GHz band, just like 5 GHz.

Signed-off-by: Tova Mussai <tova.mussai@intel.com>
Link: https://lore.kernel.org/r/20200528213443.75f38e6f5efd.I272fbae402b03123f04e9ae69204eeab960c70cd@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
4 years agomac80211: Consider 6 GHz band when handling power constraint
Ilan Peer [Thu, 28 May 2020 19:34:45 +0000 (21:34 +0200)]
mac80211: Consider 6 GHz band when handling power constraint

Treat it like the 5 GHz band.

Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Link: https://lore.kernel.org/r/20200528213443.889e5c9dd006.Id8ed3bb8000ba8738be5df05639415eb2e23c61a@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
4 years agomac80211: accept aggregation sessions on 6 GHz
Johannes Berg [Thu, 28 May 2020 19:34:44 +0000 (21:34 +0200)]
mac80211: accept aggregation sessions on 6 GHz

On 6 GHz, stations don't have ht_supported set, but they can
still do aggregation since they must have HE, allow that.

Link: https://lore.kernel.org/r/20200528213443.776d3c891b64.Ifa099d450617b50c691832b3c4aa08959fab520a@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
4 years agocfg80211: require HE capabilities for 6 GHz band
Johannes Berg [Thu, 28 May 2020 19:34:42 +0000 (21:34 +0200)]
cfg80211: require HE capabilities for 6 GHz band

On 6 GHz band, HE capabilities must be available for all of
the interface types, otherwise we shouldn't use 6 GHz. Check
this.

Link: https://lore.kernel.org/r/20200528213443.5881cb3c8c4a.I583b54172f91f98d44af64a16c5826fe458cbb27@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
4 years agocfg80211: reject HT/VHT capabilities on 6 GHz band
Johannes Berg [Thu, 28 May 2020 19:34:41 +0000 (21:34 +0200)]
cfg80211: reject HT/VHT capabilities on 6 GHz band

On the 6 GHz band, HE should be used, but without any direct HT/VHT
capabilities, instead the HE 6 GHz band capabilities will capture
the relevant information. Reject HT/VHT capabilities here.

Link: https://lore.kernel.org/r/20200528213443.bfe89c35459a.Ibba5e066fa0087fd49d13cfee89d196ea0c68ae2@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
4 years agocfg80211: treat 6 GHz channels as valid regardless of capability
Johannes Berg [Thu, 28 May 2020 19:34:40 +0000 (21:34 +0200)]
cfg80211: treat 6 GHz channels as valid regardless of capability

If a 6 GHz channel exists, then we can probably safely assume that
the device actually supports it, and then it should support most
bandwidths.

This will probably need to be extended to check the interface type
and then dig into the HE capabilities for that though, to have the
correct bandwidth check.

Link: https://lore.kernel.org/r/20200528213443.d4864ef52e92.I82f09b2b14a56413ce20376d09967fe954a033eb@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
4 years agomac80211: Add HE 6GHz capabilities element to probe request
Ilan Peer [Thu, 28 May 2020 19:34:39 +0000 (21:34 +0200)]
mac80211: Add HE 6GHz capabilities element to probe request

On 6 GHz, the 6 GHz capabilities element should be added, do that.

Signed-off-by: Ilan Peer <ilan.peer@intel.com>
[add commit message]
Link: https://lore.kernel.org/r/20200528213443.8ee764f0cde0.I2b0c66b60e11818c97c9803e04a6a197c6376243@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
4 years agomac80211: use HE 6 GHz band capability and pass it to the driver
Johannes Berg [Thu, 28 May 2020 19:34:38 +0000 (21:34 +0200)]
mac80211: use HE 6 GHz band capability and pass it to the driver

In order to handle 6 GHz AP side, take the HE 6 GHz band capability
data and pass it to the driver (which needs it for A-MPDU spacing
and A-MPDU length).

Link: https://lore.kernel.org/r/1589399105-25472-6-git-send-email-rmanohar@codeaurora.org
Co-developed-by: Rajkumar Manoharan <rmanohar@codeaurora.org>
Signed-off-by: Rajkumar Manoharan <rmanohar@codeaurora.org>
Link: https://lore.kernel.org/r/20200528213443.784e4890d82f.I5f1230d5ab27e84e7bbe88e3645b24ea15a0c146@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
4 years agomac80211: check the correct bit for EMA AP
Shaul Triebitz [Thu, 28 May 2020 19:34:37 +0000 (21:34 +0200)]
mac80211: check the correct bit for EMA AP

An AP supporting EMA (Enhanced Multi-BSSID advertisement) should set
bit 83 in the extended capabilities IE (9.4.2.26 in the 802.11ax D5 spec).
So the *3rd* bit of the 10th byte should be checked.
Also, in one place, the wrong byte was checked.
(cfg80211_find_ie returns a pointer to the beginning of the IE,
 so the data really starts at ie[2], so the 10th byte
 should be ie[12]. To avoid this confusion, use cfg80211_find_elem
 instead).

Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com>
Link: https://lore.kernel.org/r/20200528213443.4316121fa2a3.I9745582f8d41ad8e689dac0fefcd70b276d7c1ea@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
4 years agomac80211: determine chandef from HE 6 GHz operation
Johannes Berg [Thu, 28 May 2020 19:34:36 +0000 (21:34 +0200)]
mac80211: determine chandef from HE 6 GHz operation

Support connecting to HE 6 GHz APs and mesh networks on 6 GHz,
where the HT/VHT information is missing but instead the HE 6 GHz
band capability is present, and the 6 GHz Operation information
field is used to encode the channel configuration instead of the
HT/VHT operation elements.

Also add some other bits needed to connect to 6 GHz networks.

Link: https://lore.kernel.org/r/1589399105-25472-10-git-send-email-rmanohar@codeaurora.org
Co-developed-by: Rajkumar Manoharan <rmanohar@codeaurora.org>
Signed-off-by: Rajkumar Manoharan <rmanohar@codeaurora.org>
Link: https://lore.kernel.org/r/20200528213443.25687d2695bc.I3f9747c1147480f65445f13eda5c4a5ed4e86757@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
4 years agomac80211: avoid using ext NSS high BW if not supported
Johannes Berg [Thu, 28 May 2020 19:34:35 +0000 (21:34 +0200)]
mac80211: avoid using ext NSS high BW if not supported

If the AP advertises inconsistent data, namely it has CCFS1 or CCFS2,
but doesn't advertise support for 160/80+80 bandwidth or "Extended NSS
BW Support", then we cannot use any MCSes in the the higher bandwidth.
Thus, avoid connecting with higher bandwidth since it's less efficient
that way.

Link: https://lore.kernel.org/r/20200528213443.0e55d40c3ccc.I6fd0b4708ebd087e5e46466c3e91f6efbcbef668@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
4 years agomac80211: do not allow HT/VHT IEs in 6 GHz mesh mode
Rajkumar Manoharan [Thu, 28 May 2020 19:34:34 +0000 (21:34 +0200)]
mac80211: do not allow HT/VHT IEs in 6 GHz mesh mode

As HT/VHT elements are not allowed in 6 GHz band, do not include
them in mesh beacon template formation.

Signed-off-by: Rajkumar Manoharan <rmanohar@codeaurora.org>
Link: https://lore.kernel.org/r/1589399105-25472-9-git-send-email-rmanohar@codeaurora.org
Link: https://lore.kernel.org/r/20200528193455.76796-2-johannes@sipsolutions.net
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
4 years agomac80211: build HE operation with 6 GHz oper information
Rajkumar Manoharan [Thu, 28 May 2020 19:34:33 +0000 (21:34 +0200)]
mac80211: build HE operation with 6 GHz oper information

Add 6 GHz operation information (IEEE 802.11ax/D6.0, Figure 9-787k)
while building HE operation element for non-HE AP. This field is used to
determine channel information in the absence of HT/VHT IEs.

Signed-off-by: Rajkumar Manoharan <rmanohar@codeaurora.org>
Link: https://lore.kernel.org/r/1589399105-25472-8-git-send-email-rmanohar@codeaurora.org
[fix skb allocation size]
Link: https://lore.kernel.org/r/20200528193455.76796-1-johannes@sipsolutions.net
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
4 years agomac80211: add HE 6 GHz Band Capability element
Rajkumar Manoharan [Thu, 28 May 2020 19:34:32 +0000 (21:34 +0200)]
mac80211: add HE 6 GHz Band Capability element

Construct HE 6 GHz band capability element (IEEE 802.11ax/D6.0,
9.4.2.261) for association request and mesh beacon. The 6 GHz
capability information is passed by driver through iftypes caps.

Signed-off-by: Rajkumar Manoharan <rmanohar@codeaurora.org>
Link: https://lore.kernel.org/r/1589399105-25472-7-git-send-email-rmanohar@codeaurora.org
[handle SMPS, adjust for previous patches, reserve SKB space properly,
 change to handle SKB directly]
Link: https://lore.kernel.org/r/20200528213443.643aa8101111.I3f9747c1147480f65445f13eda5c4a5ed4e86757@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
4 years agocfg80211: add and expose HE 6 GHz band capabilities
Johannes Berg [Thu, 28 May 2020 19:34:31 +0000 (21:34 +0200)]
cfg80211: add and expose HE 6 GHz band capabilities

These capabilities cover what would otherwise be transported
in HT/VHT capabilities, but only a subset thereof that is
actually needed on 6 GHz with HE already present. Expose the
capabilities to userspace, drivers are expected to set them
as using the 6 GHz band (currently) requires HE capability.

Link: https://lore.kernel.org/r/20200528213443.244cd5cb9db8.Icd8c773277a88c837e7e3af1d4d1013cc3b66543@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
4 years agomac80211: add HE 6 GHz Band Capabilities into parse extension
Rajkumar Manoharan [Thu, 28 May 2020 19:34:30 +0000 (21:34 +0200)]
mac80211: add HE 6 GHz Band Capabilities into parse extension

Handle 6 GHz band capability element parsing for association.

Signed-off-by: Rajkumar Manoharan <rmanohar@codeaurora.org>
Link: https://lore.kernel.org/r/1589399105-25472-4-git-send-email-rmanohar@codeaurora.org
[some renaming to be in line with previous patches]
Link: https://lore.kernel.org/r/20200528213443.a13d7a0b85b0.Ia07584da4fc77aa77c4cc563248d2ce4234ffe5d@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
4 years agocfg80211: handle 6 GHz capability of new station
Rajkumar Manoharan [Thu, 28 May 2020 19:34:29 +0000 (21:34 +0200)]
cfg80211: handle 6 GHz capability of new station

Handle 6 GHz HE capability while adding new station. It will be used
later in mac80211 station processing.

Signed-off-by: Rajkumar Manoharan <rmanohar@codeaurora.org>
Link: https://lore.kernel.org/r/1589399105-25472-2-git-send-email-rmanohar@codeaurora.org
[handle nl80211_set_station, require WME,
 remove NL80211_HE_6GHZ_CAPABILITY_LEN]
Link: https://lore.kernel.org/r/20200528213443.b6b711fd4312.Ic9b97d57b6c4f2b28d4b2d23d2849d8bc20bd8cc@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
4 years agoieee80211: add HE ext EIDs and 6 GHz capability defines
Johannes Berg [Thu, 28 May 2020 19:34:28 +0000 (21:34 +0200)]
ieee80211: add HE ext EIDs and 6 GHz capability defines

Add the HE extended element IDs and the definitions for the
HE 6 GHz band capabilities element, from Draft 5.0.

Link: https://lore.kernel.org/r/20200528213443.1a6689fe093f.Ifdc5400fb01779351354daf38663ebeea03c9ad9@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
4 years agoieee80211: add code to obtain and parse 6 GHz operation field
Johannes Berg [Thu, 28 May 2020 19:34:27 +0000 (21:34 +0200)]
ieee80211: add code to obtain and parse 6 GHz operation field

Add some code to obtain and parse the 6 GHz operation field
inside the HE operation element.

While at it, fix the required length using sizeof() the new
struct, which is 5 instead of 4 now.

Link: https://lore.kernel.org/r/20200528213443.42ca72c45ca9.Id74bc1b03da9ea6574f9bc70deeb60dfc1634359@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
4 years agoieee80211: definitions for reduced neighbor reports
Tova Mussai [Thu, 28 May 2020 19:34:26 +0000 (21:34 +0200)]
ieee80211: definitions for reduced neighbor reports

Add the necessary definitions to parse reduced neighbor
report elements.

Signed-off-by: Tova Mussai <tova.mussai@intel.com>
[change struct name, remove IEEE80211_MIN_AP_NEIGHBOR_INFO_SIZE]
Link: https://lore.kernel.org/r/20200528213443.4f9154461c06.I518d9898ad982f838112ea9ca14a20d6bbb16394@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
4 years agocfg80211: add a helper to identify 6 GHz PSCs
Johannes Berg [Thu, 28 May 2020 19:34:25 +0000 (21:34 +0200)]
cfg80211: add a helper to identify 6 GHz PSCs

This allows identifying whether or not a channel is a PSC
(preferred scanning channel).

Link: https://lore.kernel.org/r/20200528213443.414363ecf62c.Ic15e681a0e249eab7350a06ceb582cca8bb9a080@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
4 years agonl80211: really allow client-only BIGTK support
Johannes Berg [Thu, 28 May 2020 19:34:24 +0000 (21:34 +0200)]
nl80211: really allow client-only BIGTK support

My previous commit here was wrong, it didn't check the new
flag in two necessary places, so things didn't work. Fix that.

Fixes: 155d7c733807 ("nl80211: allow client-only BIGTK support")
Link: https://lore.kernel.org/r/20200528213443.993f108e96ca.I0086ae42d672379380d04ac5effb2f3d5135731b@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
4 years agocfg80211: adapt to new channelization of the 6GHz band
Arend Van Spriel [Fri, 29 May 2020 09:41:43 +0000 (11:41 +0200)]
cfg80211: adapt to new channelization of the 6GHz band

The 6GHz band does not have regulatory approval yet, but things are
moving forward. However, that has led to a change in the channelization
of the 6GHz band which has been accepted in the 11ax specification. It
also fixes a missing MHZ_TO_KHZ() macro for 6GHz channels while at it.

This change is primarily thrown in to discuss how to deal with it.
I noticed ath11k adding 6G support with old channelization and ditto
for iw. It probably involves changes in hostapd as well.

Cc: Pradeep Kumar Chitrapu <pradeepc@codeaurora.org>
Cc: Jouni Malinen <jouni@w1.fi>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Link: https://lore.kernel.org/r/edf07cdd-ad15-4012-3afd-d8b961a80b69@broadcom.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
4 years agocfg80211: fix 6 GHz frequencies to kHz
Johannes Berg [Fri, 29 May 2020 12:04:27 +0000 (14:04 +0200)]
cfg80211: fix 6 GHz frequencies to kHz

The updates to change to kHz frequencies and the 6 GHz
additions evidently overlapped (or rather, I didn't see
it when applying the latter), so the 6 GHz is broken.
Fix this.

Fixes: 934f4c7dd3a5 ("cfg80211: express channels with a KHz component")
Link: https://lore.kernel.org/r/20200529140425.1bf824f6911b.I4a1174916b8f5965af4366999eb9ffc7a0347470@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
4 years agol2tp: add sk_family checks to l2tp_validate_socket
Eric Dumazet [Fri, 29 May 2020 18:32:25 +0000 (11:32 -0700)]
l2tp: add sk_family checks to l2tp_validate_socket

syzbot was able to trigger a crash after using an ISDN socket
and fool l2tp.

Fix this by making sure the UDP socket is of the proper family.

BUG: KASAN: slab-out-of-bounds in setup_udp_tunnel_sock+0x465/0x540 net/ipv4/udp_tunnel.c:78
Write of size 1 at addr ffff88808ed0c590 by task syz-executor.5/3018

CPU: 0 PID: 3018 Comm: syz-executor.5 Not tainted 5.7.0-rc6-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x188/0x20d lib/dump_stack.c:118
 print_address_description.constprop.0.cold+0xd3/0x413 mm/kasan/report.c:382
 __kasan_report.cold+0x20/0x38 mm/kasan/report.c:511
 kasan_report+0x33/0x50 mm/kasan/common.c:625
 setup_udp_tunnel_sock+0x465/0x540 net/ipv4/udp_tunnel.c:78
 l2tp_tunnel_register+0xb15/0xdd0 net/l2tp/l2tp_core.c:1523
 l2tp_nl_cmd_tunnel_create+0x4b2/0xa60 net/l2tp/l2tp_netlink.c:249
 genl_family_rcv_msg_doit net/netlink/genetlink.c:673 [inline]
 genl_family_rcv_msg net/netlink/genetlink.c:718 [inline]
 genl_rcv_msg+0x627/0xdf0 net/netlink/genetlink.c:735
 netlink_rcv_skb+0x15a/0x410 net/netlink/af_netlink.c:2469
 genl_rcv+0x24/0x40 net/netlink/genetlink.c:746
 netlink_unicast_kernel net/netlink/af_netlink.c:1303 [inline]
 netlink_unicast+0x537/0x740 net/netlink/af_netlink.c:1329
 netlink_sendmsg+0x882/0xe10 net/netlink/af_netlink.c:1918
 sock_sendmsg_nosec net/socket.c:652 [inline]
 sock_sendmsg+0xcf/0x120 net/socket.c:672
 ____sys_sendmsg+0x6e6/0x810 net/socket.c:2352
 ___sys_sendmsg+0x100/0x170 net/socket.c:2406
 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2439
 do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295
 entry_SYSCALL_64_after_hwframe+0x49/0xb3
RIP: 0033:0x45ca29
Code: 0d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 db b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007effe76edc78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00000000004fe1c0 RCX: 000000000045ca29
RDX: 0000000000000000 RSI: 0000000020000240 RDI: 0000000000000005
RBP: 000000000078bf00 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 000000000000094e R14: 00000000004d5d00 R15: 00007effe76ee6d4

Allocated by task 3018:
 save_stack+0x1b/0x40 mm/kasan/common.c:49
 set_track mm/kasan/common.c:57 [inline]
 __kasan_kmalloc mm/kasan/common.c:495 [inline]
 __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:468
 __do_kmalloc mm/slab.c:3656 [inline]
 __kmalloc+0x161/0x7a0 mm/slab.c:3665
 kmalloc include/linux/slab.h:560 [inline]
 sk_prot_alloc+0x223/0x2f0 net/core/sock.c:1612
 sk_alloc+0x36/0x1100 net/core/sock.c:1666
 data_sock_create drivers/isdn/mISDN/socket.c:600 [inline]
 mISDN_sock_create+0x272/0x400 drivers/isdn/mISDN/socket.c:796
 __sock_create+0x3cb/0x730 net/socket.c:1428
 sock_create net/socket.c:1479 [inline]
 __sys_socket+0xef/0x200 net/socket.c:1521
 __do_sys_socket net/socket.c:1530 [inline]
 __se_sys_socket net/socket.c:1528 [inline]
 __x64_sys_socket+0x6f/0xb0 net/socket.c:1528
 do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295
 entry_SYSCALL_64_after_hwframe+0x49/0xb3

Freed by task 2484:
 save_stack+0x1b/0x40 mm/kasan/common.c:49
 set_track mm/kasan/common.c:57 [inline]
 kasan_set_free_info mm/kasan/common.c:317 [inline]
 __kasan_slab_free+0xf7/0x140 mm/kasan/common.c:456
 __cache_free mm/slab.c:3426 [inline]
 kfree+0x109/0x2b0 mm/slab.c:3757
 kvfree+0x42/0x50 mm/util.c:603
 __free_fdtable+0x2d/0x70 fs/file.c:31
 put_files_struct fs/file.c:420 [inline]
 put_files_struct+0x248/0x2e0 fs/file.c:413
 exit_files+0x7e/0xa0 fs/file.c:445
 do_exit+0xb04/0x2dd0 kernel/exit.c:791
 do_group_exit+0x125/0x340 kernel/exit.c:894
 get_signal+0x47b/0x24e0 kernel/signal.c:2739
 do_signal+0x81/0x2240 arch/x86/kernel/signal.c:784
 exit_to_usermode_loop+0x26c/0x360 arch/x86/entry/common.c:161
 prepare_exit_to_usermode arch/x86/entry/common.c:196 [inline]
 syscall_return_slowpath arch/x86/entry/common.c:279 [inline]
 do_syscall_64+0x6b1/0x7d0 arch/x86/entry/common.c:305
 entry_SYSCALL_64_after_hwframe+0x49/0xb3

The buggy address belongs to the object at ffff88808ed0c000
 which belongs to the cache kmalloc-2k of size 2048
The buggy address is located 1424 bytes inside of
 2048-byte region [ffff88808ed0c000ffff88808ed0c800)
The buggy address belongs to the page:
page:ffffea00023b4300 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0
flags: 0xfffe0000000200(slab)
raw: 00fffe0000000200 ffffea0002838208 ffffea00015ba288 ffff8880aa000e00
raw: 0000000000000000 ffff88808ed0c000 0000000100000001 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff88808ed0c480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffff88808ed0c500: 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff88808ed0c580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                         ^
 ffff88808ed0c600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff88808ed0c680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc

Fixes: 6b9f34239b00 ("l2tp: fix races in tunnel creation")
Fixes: fd558d186df2 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: James Chapman <jchapman@katalix.com>
Cc: Guillaume Nault <gnault@redhat.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Acked-by: Guillaume Nault <gnault@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agol2tp: do not use inet_hash()/inet_unhash()
Eric Dumazet [Fri, 29 May 2020 18:20:53 +0000 (11:20 -0700)]
l2tp: do not use inet_hash()/inet_unhash()

syzbot recently found a way to crash the kernel [1]

Issue here is that inet_hash() & inet_unhash() are currently
only meant to be used by TCP & DCCP, since only these protocols
provide the needed hashinfo pointer.

L2TP uses a single list (instead of a hash table)

This old bug became an issue after commit 610236587600
("bpf: Add new cgroup attach type to enable sock modifications")
since after this commit, sk_common_release() can be called
while the L2TP socket is still considered 'hashed'.

general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 0 PID: 7063 Comm: syz-executor654 Not tainted 5.7.0-rc6-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:inet_unhash+0x11f/0x770 net/ipv4/inet_hashtables.c:600
Code: 03 0f b6 04 02 84 c0 74 08 3c 03 0f 8e dd 04 00 00 48 8d 7d 08 44 8b 73 08 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 55 05 00 00 48 8d 7d 14 4c 8b 6d 08 48 b8 00 00
RSP: 0018:ffffc90001777d30 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: ffff88809a6df940 RCX: ffffffff8697c242
RDX: 0000000000000001 RSI: ffffffff8697c251 RDI: 0000000000000008
RBP: 0000000000000000 R08: ffff88809f3ae1c0 R09: fffffbfff1514cc1
R10: ffffffff8a8a6607 R11: fffffbfff1514cc0 R12: ffff88809a6df9b0
R13: 0000000000000007 R14: 0000000000000000 R15: ffffffff873a4d00
FS:  0000000001d2b880(0000) GS:ffff8880ae600000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000006cd090 CR3: 000000009403a000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 sk_common_release+0xba/0x370 net/core/sock.c:3210
 inet_create net/ipv4/af_inet.c:390 [inline]
 inet_create+0x966/0xe00 net/ipv4/af_inet.c:248
 __sock_create+0x3cb/0x730 net/socket.c:1428
 sock_create net/socket.c:1479 [inline]
 __sys_socket+0xef/0x200 net/socket.c:1521
 __do_sys_socket net/socket.c:1530 [inline]
 __se_sys_socket net/socket.c:1528 [inline]
 __x64_sys_socket+0x6f/0xb0 net/socket.c:1528
 do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295
 entry_SYSCALL_64_after_hwframe+0x49/0xb3
RIP: 0033:0x441e29
Code: e8 fc b3 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 eb 08 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffdce184148 EFLAGS: 00000246 ORIG_RAX: 0000000000000029
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000441e29
RDX: 0000000000000073 RSI: 0000000000000002 RDI: 0000000000000002
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000402c30 R14: 0000000000000000 R15: 0000000000000000
Modules linked in:
---[ end trace 23b6578228ce553e ]---
RIP: 0010:inet_unhash+0x11f/0x770 net/ipv4/inet_hashtables.c:600
Code: 03 0f b6 04 02 84 c0 74 08 3c 03 0f 8e dd 04 00 00 48 8d 7d 08 44 8b 73 08 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 55 05 00 00 48 8d 7d 14 4c 8b 6d 08 48 b8 00 00
RSP: 0018:ffffc90001777d30 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: ffff88809a6df940 RCX: ffffffff8697c242
RDX: 0000000000000001 RSI: ffffffff8697c251 RDI: 0000000000000008
RBP: 0000000000000000 R08: ffff88809f3ae1c0 R09: fffffbfff1514cc1
R10: ffffffff8a8a6607 R11: fffffbfff1514cc0 R12: ffff88809a6df9b0
R13: 0000000000000007 R14: 0000000000000000 R15: ffffffff873a4d00
FS:  0000000001d2b880(0000) GS:ffff8880ae600000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000006cd090 CR3: 000000009403a000 CR4: 00000000001406f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400

Fixes: 0d76751fad77 ("l2tp: Add L2TPv3 IP encapsulation (no UDP) support")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: James Chapman <jchapman@katalix.com>
Cc: Andrii Nakryiko <andriin@fb.com>
Reported-by: syzbot+3610d489778b57cc8031@syzkaller.appspotmail.com
4 years agomptcp: fix NULL ptr dereference in MP_JOIN error path
Paolo Abeni [Fri, 29 May 2020 15:49:18 +0000 (17:49 +0200)]
mptcp: fix NULL ptr dereference in MP_JOIN error path

When token lookup on MP_JOIN 3rd ack fails, the server
socket closes with a reset the incoming child. Such socket
has the 'is_mptcp' flag set, but no msk socket associated
- due to the failed lookup.

While crafting the reset packet mptcp_established_options_mp()
will try to dereference the child's master socket, causing
a NULL ptr dereference.

This change addresses the issue with explicit fallback to
TCP in such error path.

Fixes: 729cd6436f35 ("mptcp: cope better with MP_JOIN failure")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agosch_cake: Take advantage of skb->hash where appropriate
Toke Høiland-Jørgensen [Fri, 29 May 2020 12:43:44 +0000 (14:43 +0200)]
sch_cake: Take advantage of skb->hash where appropriate

While the other fq-based qdiscs take advantage of skb->hash and doesn't
recompute it if it is already set, sch_cake does not.

This was a deliberate choice because sch_cake hashes various parts of the
packet header to support its advanced flow isolation modes. However,
foregoing the use of skb->hash entirely loses a few important benefits:

- When skb->hash is set by hardware, a few CPU cycles can be saved by not
  hashing again in software.

- Tunnel encapsulations will generally preserve the value of skb->hash from
  before the encapsulation, which allows flow-based qdiscs to distinguish
  between flows even though the outer packet header no longer has flow
  information.

It turns out that we can preserve these desirable properties in many cases,
while still supporting the advanced flow isolation properties of sch_cake.
This patch does so by reusing the skb->hash value as the flow_hash part of
the hashing procedure in cake_hash() only in the following conditions:

- If the skb->hash is marked as covering the flow headers (skb->l4_hash is
  set)

AND

- NAT header rewriting is either disabled, or did not change any values
  used for hashing. The latter is important to match local-origin packets
  such as those of a tunnel endpoint.

The immediate motivation for fixing this was the recent patch to WireGuard
to preserve the skb->hash on encapsulation. As such, this is also what I
tested against; with this patch, added latency under load for competing
flows drops from ~8 ms to sub-1ms on an RRUL test over a WireGuard tunnel
going through a virtual link shaped to 1Gbps using sch_cake. This matches
the results we saw with a similar setup using sch_fq_codel when testing the
WireGuard patch.

Fixes: 046f6fd5daef ("sched: Add Common Applications Kept Enhanced (cake) qdisc")
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agoravb: Mask PHY mode to avoid inserting delays twice
Geert Uytterhoeven [Fri, 29 May 2020 12:25:40 +0000 (14:25 +0200)]
ravb: Mask PHY mode to avoid inserting delays twice

Until recently, the Micrel KSZ9031 PHY driver ignored any PHY mode
("RGMII-*ID") settings, but used the hardware defaults, augmented by
explicit configuration of individual skew values using the "*-skew-ps"
DT properties.  The lack of PHY mode support was compensated by the
EtherAVB MAC driver, which configures TX and/or RX internal delay
itself, based on the PHY mode.

However, now the KSZ9031 driver has gained PHY mode support, delays may
be configured twice, causing regressions.  E.g. on the Renesas
Salvator-X board with R-Car M3-W ES1.0, TX performance dropped from ca.
400 Mbps to 0.1-0.3 Mbps, as measured by nuttcp.

As internal delay configuration supported by the KSZ9031 PHY is too
limited for some use cases, the ability to configure MAC internal delay
is deemed useful and necessary.  Hence a proper fix would involve
splitting internal delay configuration in two parts, one for the PHY,
and one for the MAC.  However, this would require adding new DT
properties, thus breaking DTB backwards-compatibility.

Hence fix the regression in a backwards-compatibility way, by letting
the EtherAVB driver mask the PHY mode when it has inserted a delay, to
avoid the PHY driver adding a second delay.  This also fixes messages
like:

    Micrel KSZ9031 Gigabit PHY e6800000.ethernet-ffffffff:00: *-skew-ps values should be used only with phy-mode = "rgmii"

as the PHY no longer sees the original RGMII-*ID mode.

Solving the issue by splitting configuration in two parts can be handled
in future patches, and would require retaining a backwards-compatibility
mode anyway.

Fixes: bcf3440c6dd78bfe ("net: phy: micrel: add phy-mode support for the KSZ9031 PHY")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agoMerge branch 'selftests-forwarding-Two-small-changes'
David S. Miller [Sun, 31 May 2020 04:48:24 +0000 (21:48 -0700)]
Merge branch 'selftests-forwarding-Two-small-changes'

Petr Machata says:

====================
selftests: forwarding: Two small changes

Two unrelated changes in this patchset:

- In patch #1, convert mirror tests from using ping directly to generating
  ICMP packets by mausezahn. Using ping in tests is error-prone, because
  ping is too smart. On a flaky system (notably in a simulator), when
  packets don't come quickly enough, more pings are sent, and that throws
  off counters. This was worked around in the past by just pinging more
  slowly, but using mausezahn avoids the issue as well without making the
  tests unnecessary slow.

- A missing stats_update callback was recently added to act_pedit. Now that
  iproute2 supports JSON dumping for pedit, extend in patch #2 the
  pedit_dsfield selftest with a check that would have caught the fact that
  the callback was missing.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agoselftests: forwarding: pedit_dsfield: Check counter value
Petr Machata [Fri, 29 May 2020 11:16:54 +0000 (14:16 +0300)]
selftests: forwarding: pedit_dsfield: Check counter value

A missing stats_update callback was recently added to act_pedit. Now that
iproute2 supports JSON dumping for pedit, extend the pedit_dsfield selftest
with a check that would have caught the fact that the callback was missing.

Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agoselftests: forwarding: mirror_lib: Use mausezahn
Petr Machata [Fri, 29 May 2020 11:16:53 +0000 (14:16 +0300)]
selftests: forwarding: mirror_lib: Use mausezahn

Using ping in tests is error-prone, because ping is too smart. On a
flaky system (notably in a simulator), when packets don't come quickly
enough, more pings are sent, and that throws off counters. Instead use
mausezahn to generate ICMP echo request packets. That allows us to
send them in quicker succession as well, because the reason the ping
was made slow in the first place was to make the tests work on
simulated systems.

Signed-off-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agoMerge branch 'vxlan-fdb-nexthop-misc-fixes'
David S. Miller [Sun, 31 May 2020 04:47:08 +0000 (21:47 -0700)]
Merge branch 'vxlan-fdb-nexthop-misc-fixes'

Roopa Prabhu says:

====================
vxlan fdb nexthop misc fixes

Roopa Prabhu (2):
  vxlan: add check to prevent use of remote ip attributes with NDA_NH_ID
  vxlan: few locking fixes in nexthop event handler
====================

Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agovxlan: few locking fixes in nexthop event handler
Roopa Prabhu [Fri, 29 May 2020 05:12:36 +0000 (22:12 -0700)]
vxlan: few locking fixes in nexthop event handler

- remove fdb from nh_list before the rcu grace period
- protect fdb->vdev with rcu
- hold spin lock before destroying fdb

Fixes: c7cdbe2efc40 ("vxlan: support for nexthop notifiers")
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Reviewed-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agovxlan: add check to prevent use of remote ip attributes with NDA_NH_ID
Roopa Prabhu [Fri, 29 May 2020 05:12:35 +0000 (22:12 -0700)]
vxlan: add check to prevent use of remote ip attributes with NDA_NH_ID

NDA_NH_ID represents a remote ip or a group of remote ips.
It allows use of nexthop groups in lieu of a remote ip or a
list of remote ips supported by the fdb api.

Current code ignores the other remote ip attrs when NDA_NH_ID is
specified. In the spirit of strict checking, This commit adds a
check to explicitly return an error on incorrect usage.

Fixes: 1274e1cc4226 ("vxlan: ecmp support for mac fdb entries")
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agoMerge branch '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next...
David S. Miller [Sun, 31 May 2020 04:44:50 +0000 (21:44 -0700)]
Merge branch '100GbE' of git://git./linux/kernel/git/jkirsher/next-queue

Jeff Kirsher says:

====================
100GbE Intel Wired LAN Driver Updates 2020-05-28

This series contains updates to the ice driver only.

Anirudh (Ani) adds a poll for reset completion before proceeding with
driver initialization when the DDP package fails to load and the firmware
issues a core reset.

Jake cleans up unnecessary code, since ice_set_dflt_vsi_ctx() performs a
memset to clear the info from the context structures.  Fixed a potential
double free during probe unrolling after a failure.  Also fixed a
potential NULL pointer dereference upon register_netdev() failure.

Tony makes two functions static which are not called outside of their
file.

Brett refactors the ice_ena_vf_mappings(), which was doing the VF's MSIx
and queue mapping in one function which was hard to digest.  So create a
new function to handle the enabling MSIx mappings and another function
to handle the enabling of queue mappings.  Simplify the code flow in
ice_sriov_configure().  Created a helper function for clearing
VPGEN_VFRTRIG register, as this needs to be done on reset to notify the
VF that we are done resetting it.  Fixed the initialization/creation and
reset flows, which was unnecessarily complicated, so separate the two
flows into their own functions.  Renamed VF initialization functions to
make it more clear what they do and why.  Added functionality to set the
VF trust mode bit on reset.  Added helper functions to rebuild the VLAN
and MAC configurations when resetting a VF.  Refactored how the VF reset
is handled to prevent VF reset timeouts.

Paul cleaned up code not needed during a CORER/GLOBR reset.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agonet: qrtr: Allocate workqueue before kernel_bind
Chris Lew [Thu, 28 May 2020 23:05:26 +0000 (16:05 -0700)]
net: qrtr: Allocate workqueue before kernel_bind

A null pointer dereference in qrtr_ns_data_ready() is seen if a client
opens a qrtr socket before qrtr_ns_init() can bind to the control port.
When the control port is bound, the ENETRESET error will be broadcasted
and clients will close their sockets. This results in DEL_CLIENT
packets being sent to the ns and qrtr_ns_data_ready() being called
without the workqueue being allocated.

Allocate the workqueue before setting sk_data_ready and binding to the
control port. This ensures that the work and workqueue structs are
allocated and initialized before qrtr_ns_data_ready can be called.

Fixes: 0c2204a4ad71 ("net: qrtr: Migrate nameservice to kernel from userspace")
Signed-off-by: Chris Lew <clew@codeaurora.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agoMerge branch 'mptcp-a-bunch-of-fixes'
David S. Miller [Sun, 31 May 2020 04:39:13 +0000 (21:39 -0700)]
Merge branch 'mptcp-a-bunch-of-fixes'

Paolo Abeni says:

====================
mptcp: a bunch of fixes

This patch series pulls together a few bugfixes for MPTCP bug observed while
doing stress-test with apache bench - forced to use MPTCP and multiple
subflows.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agomptcp: remove msk from the token container at destruction time.
Paolo Abeni [Fri, 29 May 2020 15:43:31 +0000 (17:43 +0200)]
mptcp: remove msk from the token container at destruction time.

Currently we remote the msk from the token container only
via mptcp_close(). The MPTCP master socket can be destroyed
also via other paths (e.g. if not yet accepted, when shutting
down the listener socket). When we hit the latter scenario,
dangling msk references are left into the token container,
leading to memory corruption and/or UaF.

This change addresses the issue by moving the token removal
into the msk destructor.

Fixes: 79c0949e9a09 ("mptcp: Add key generation and token tree")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agomptcp: fix race between MP_JOIN and close
Paolo Abeni [Fri, 29 May 2020 15:43:30 +0000 (17:43 +0200)]
mptcp: fix race between MP_JOIN and close

If a MP_JOIN subflow completes the 3whs while another
CPU is closing the master msk, we can hit the
following race:

CPU1                                    CPU2

close()
 mptcp_close
                                        subflow_syn_recv_sock
                                         mptcp_token_get_sock
                                         mptcp_finish_join
                                          inet_sk_state_load
  mptcp_token_destroy
  inet_sk_state_store(TCP_CLOSE)
  __mptcp_flush_join_list()
                                          mptcp_sock_graft
                                          list_add_tail
  sk_common_release
   sock_orphan()
 <socket free>

The MP_JOIN socket will be leaked. Additionally we can hit
UaF for the msk 'struct socket' referenced via the 'conn'
field.

This change try to address the issue introducing some
synchronization between the MP_JOIN 3whs and mptcp_close
via the join_list spinlock. If we detect the msk is closing
the MP_JOIN socket is closed, too.

Fixes: f296234c98a8 ("mptcp: Add handling of incoming MP_JOIN requests")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agomptcp: fix unblocking connect()
Paolo Abeni [Fri, 29 May 2020 15:43:29 +0000 (17:43 +0200)]
mptcp: fix unblocking connect()

Currently unblocking connect() on MPTCP sockets fails frequently.
If mptcp_stream_connect() is invoked to complete a previously
attempted unblocking connection, it will still try to create
the first subflow via __mptcp_socket_create(). If the 3whs is
completed and the 'can_ack' flag is already set, the latter
will fail with -EINVAL.

This change addresses the issue checking for pending connect and
delegating the completion to the first subflow. Additionally
do msk addresses and sk_state changes only when needed.

Fixes: 2303f994b3e1 ("mptcp: Associate MPTCP context with TCP socket")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agoMerge branch 'r8169-again-few-improvements'
David S. Miller [Sun, 31 May 2020 04:36:55 +0000 (21:36 -0700)]
Merge branch 'r8169-again-few-improvements'

Heiner Kallweit says:

====================
r8169: again few improvements

Again a series with few r8169 improvements.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agor8169: improve handling power management ops
Heiner Kallweit [Sat, 30 May 2020 21:59:58 +0000 (23:59 +0200)]
r8169: improve handling power management ops

Simplify handling the power management callbacks.

Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agor8169: make rtl8169_down central chip quiesce function
Heiner Kallweit [Sat, 30 May 2020 21:58:35 +0000 (23:58 +0200)]
r8169: make rtl8169_down central chip quiesce function

Functionality for quiescing the chip is spread across different
functions currently. Move it to rtl8169_down().

Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agor8169: move some calls to rtl8169_hw_reset
Heiner Kallweit [Sat, 30 May 2020 21:57:10 +0000 (23:57 +0200)]
r8169: move some calls to rtl8169_hw_reset

Move calls that are needed before and after calling rtl8169_hw_reset()
into this function. This requires to move the function in the code.

Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agor8169: don't reset tx ring indexes in rtl8169_tx_clear
Heiner Kallweit [Sat, 30 May 2020 21:56:14 +0000 (23:56 +0200)]
r8169: don't reset tx ring indexes in rtl8169_tx_clear

In places where the indexes have to be reset, we call
rtl8169_init_ring_indexes() anyway after rtl8169_tx_clear().

Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agor8169: enable WAKE_PHY as only WoL source when runtime-suspending
Heiner Kallweit [Sat, 30 May 2020 21:55:30 +0000 (23:55 +0200)]
r8169: enable WAKE_PHY as only WoL source when runtime-suspending

We go to runtime-suspend few secs after cable removal. As cable is
removed "physical link up" is the only meaningful WoL source.

Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agor8169: change driver data type
Heiner Kallweit [Sat, 30 May 2020 21:54:36 +0000 (23:54 +0200)]
r8169: change driver data type

Change driver private data type to struct rtl8169_private * to avoid
some overhead.

Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agoMerge tag 'wireless-drivers-next-2020-05-30' of git://git.kernel.org/pub/scm/linux...
David S. Miller [Sun, 31 May 2020 01:14:11 +0000 (18:14 -0700)]
Merge tag 'wireless-drivers-next-2020-05-30' of git://git./linux/kernel/git/kvalo/wireless-drivers-next

Kalle Valo says:

====================
wireless-drivers-next patches for v5.8

Third set of patches for v5.8. Final new features before the merge
window (most likely) opens, noteworthy here is adding WPA3 support to
old drivers rt2800, b43 and b43_legacy.

Major changes:

ath10k

* SDIO and SNOC busses are not experimental anymore

ath9k

* allow receive of broadcast Action frames

ath9k_htc

* allow receive of broadcast Action frames

rt2800

* enable WPA3 support out of box

b43

* enable WPA3 support

b43_legacy

* enable WPA3 support

mwifiex

* advertise max number of clients to user space

mt76

* mt7663: add remain-on-channel support

* mt7915: add spatial reuse support

* add support for mt7611n hardware

iwlwifi

* add ACPI DSM support

* support enabling 5.2GHz bands in Indonesia via ACPI

* bump FW API version to 56
====================

Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agonet/smc: pre-fetch send buffer outside of send_lock
Karsten Graul [Sat, 30 May 2020 14:42:37 +0000 (16:42 +0200)]
net/smc: pre-fetch send buffer outside of send_lock

Pre-fetch send buffer for the CDC validation message before entering the
send_lock. Without that the send call might fail with -EBUSY because
there are no free buffers and waiting for buffers is not possible under
send_lock.

Signed-off-by: Karsten Graul <kgraul@linux.ibm.com>
Reviewed-by: Ursula Braun <ubraun@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agoMerge branch 'Fix-2-non-critical-issues-in-SJA1105-DSA'
David S. Miller [Sun, 31 May 2020 01:00:36 +0000 (18:00 -0700)]
Merge branch 'Fix-2-non-critical-issues-in-SJA1105-DSA'

Vladimir Oltean says:

====================
Fix 2 non-critical issues in SJA1105 DSA

This small series suppresses the W=1 warnings in the sja1105 driver and
it corrects some register offsets. I would like to target it against
net-next since it would have non-trivial conflicts with net, and the
problems it solves are not that big of a deal.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agonet: dsa: sja1105: fix port mirroring for P/Q/R/S
Vladimir Oltean [Sat, 30 May 2020 10:29:53 +0000 (13:29 +0300)]
net: dsa: sja1105: fix port mirroring for P/Q/R/S

The dynamic configuration interface for the General Params and the L2
Lookup Params tables was copy-pasted between E/T devices and P/Q/R/S
devices. Nonetheless, these interfaces are bitwise different.

The driver is using dynamic reconfiguration of the General Parameters
table for the port mirroring feature, which was therefore broken on
P/Q/R/S.

Note that this patch can't be backported easily very far to stable trees
(since it conflicts with some other development done since the
introduction of the driver). So the Fixes: tag is purely informational.

Fixes: 8aa9ebccae87 ("net: dsa: Introduce driver for NXP SJA1105 5-port L2 switch")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agonet: dsa: sja1105: suppress -Wmissing-prototypes in sja1105_static_config.c
Vladimir Oltean [Sat, 30 May 2020 10:29:52 +0000 (13:29 +0300)]
net: dsa: sja1105: suppress -Wmissing-prototypes in sja1105_static_config.c

Newer compilers complain with W=1 builds that there are non-static
functions defined in sja1105_static_config.c that don't have a
prototype, because their prototype is defined in sja1105.h which this
translation unit does not include.

I don't entirely understand what is the point of these warnings, since
in principle there's nothing wrong with that. But let's move the
prototypes to a header file that _is_ included by
sja1105_static_config.c, since that will make these warnings go away.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agonet/sched: act_ct: add nat mangle action only for NAT-conntrack
wenxu [Sat, 30 May 2020 05:54:51 +0000 (13:54 +0800)]
net/sched: act_ct: add nat mangle action only for NAT-conntrack

Currently add nat mangle action with comparing invert and orig tuple.
It is better to check IPS_NAT_MASK flags first to avoid non necessary
memcmp for non-NAT conntrack.

Signed-off-by: wenxu <wenxu@ucloud.cn>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agoMerge tag 'mlx5-cleanup-2020-05-29' of git://git.kernel.org/pub/scm/linux/kernel...
David S. Miller [Sun, 31 May 2020 00:53:57 +0000 (17:53 -0700)]
Merge tag 'mlx5-cleanup-2020-05-29' of git://git./linux/kernel/git/saeed/linux

Saeed Mahameed says:

====================
mlx5-cleanup-2020-05-29

Accumulated cleanup patches and sparse warning fixes for mlx5 driver.

1) sync with mlx5-next branch

2) Eli Cohen declares mpls_entry_encode() helper in mpls.h as suggested
by Jakub Kicinski and David Ahern, and use it in mlx5

3) Jesper Fixes xdp data_meta setup in mlx5

4) Many sparse and build warnings cleanup
====================

Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agodevinet: fix memleak in inetdev_init()
Yang Yingliang [Sat, 30 May 2020 03:34:33 +0000 (11:34 +0800)]
devinet: fix memleak in inetdev_init()

When devinet_sysctl_register() failed, the memory allocated
in neigh_parms_alloc() should be freed.

Fixes: 20e61da7ffcf ("ipv4: fail early when creating netdev named all or default")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agovirtio_vsock: Fix race condition in virtio_transport_recv_pkt
Jia He [Sat, 30 May 2020 01:38:28 +0000 (09:38 +0800)]
virtio_vsock: Fix race condition in virtio_transport_recv_pkt

When client on the host tries to connect(SOCK_STREAM, O_NONBLOCK) to the
server on the guest, there will be a panic on a ThunderX2 (armv8a server):

[  463.718844] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
[  463.718848] Mem abort info:
[  463.718849]   ESR = 0x96000044
[  463.718852]   EC = 0x25: DABT (current EL), IL = 32 bits
[  463.718853]   SET = 0, FnV = 0
[  463.718854]   EA = 0, S1PTW = 0
[  463.718855] Data abort info:
[  463.718856]   ISV = 0, ISS = 0x00000044
[  463.718857]   CM = 0, WnR = 1
[  463.718859] user pgtable: 4k pages, 48-bit VAs, pgdp=0000008f6f6e9000
[  463.718861] [0000000000000000] pgd=0000000000000000
[  463.718866] Internal error: Oops: 96000044 [#1] SMP
[...]
[  463.718977] CPU: 213 PID: 5040 Comm: vhost-5032 Tainted: G           O      5.7.0-rc7+ #139
[  463.718980] Hardware name: GIGABYTE R281-T91-00/MT91-FS1-00, BIOS F06 09/25/2018
[  463.718982] pstate: 60400009 (nZCv daif +PAN -UAO)
[  463.718995] pc : virtio_transport_recv_pkt+0x4c8/0xd40 [vmw_vsock_virtio_transport_common]
[  463.718999] lr : virtio_transport_recv_pkt+0x1fc/0xd40 [vmw_vsock_virtio_transport_common]
[  463.719000] sp : ffff80002dbe3c40
[...]
[  463.719025] Call trace:
[  463.719030]  virtio_transport_recv_pkt+0x4c8/0xd40 [vmw_vsock_virtio_transport_common]
[  463.719034]  vhost_vsock_handle_tx_kick+0x360/0x408 [vhost_vsock]
[  463.719041]  vhost_worker+0x100/0x1a0 [vhost]
[  463.719048]  kthread+0x128/0x130
[  463.719052]  ret_from_fork+0x10/0x18

The race condition is as follows:
Task1                                Task2
=====                                =====
__sock_release                       virtio_transport_recv_pkt
  __vsock_release                      vsock_find_bound_socket (found sk)
    lock_sock_nested
    vsock_remove_sock
    sock_orphan
      sk_set_socket(sk, NULL)
    sk->sk_shutdown = SHUTDOWN_MASK
    ...
    release_sock
                                    lock_sock
                                       virtio_transport_recv_connecting
                                         sk->sk_socket->state (panic!)

The root cause is that vsock_find_bound_socket can't hold the lock_sock,
so there is a small race window between vsock_find_bound_socket() and
lock_sock(). If __vsock_release() is running in another task,
sk->sk_socket will be set to NULL inadvertently.

This fixes it by checking sk->sk_shutdown(suggested by Stefano) after
lock_sock since sk->sk_shutdown is set to SHUTDOWN_MASK under the
protection of lock_sock_nested.

Signed-off-by: Jia He <justin.he@arm.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agoMerge branch 'hns3-next'
David S. Miller [Sun, 31 May 2020 00:41:22 +0000 (17:41 -0700)]
Merge branch 'hns3-next'

Huazhong Tan says:

====================
net: hns3: adds some cleanups for -next

There are some cleanups for the HNS3 ethernet driver, fix an
incorrect print format, an incorrect comment and some coding
style issues, also remove some unused codes and macros.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agonet: hns3: remove some unused codes in hns3_nic_set_features()
Huazhong Tan [Sat, 30 May 2020 01:08:32 +0000 (09:08 +0800)]
net: hns3: remove some unused codes in hns3_nic_set_features()

NETIF_F_HW_VLAN_CTAG_FILTER is not set in netdev->hw_feature for
the HNS3 driver, so the handler of NETIF_F_HW_VLAN_CTAG_FILTER
in hns3_nic_set_features() won't be called, remove it.

Reported-by: Jian Shen <shenjian15@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agonet: hns3: fix two coding style issues in hclgevf_main.c
Huazhong Tan [Sat, 30 May 2020 01:08:31 +0000 (09:08 +0800)]
net: hns3: fix two coding style issues in hclgevf_main.c

Remove a redundant blank line in hclgevf_cmd_set_promisc_mode(),
and fix a reverse xmas tree coding style issue in
hclgevf_set_rss_tc_mode().

Reported-by: Jian Shen <shenjian15@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agonet: hns3: fix an incorrect comment for num_tqps in struct hclgevf_dev
Huazhong Tan [Sat, 30 May 2020 01:08:30 +0000 (09:08 +0800)]
net: hns3: fix an incorrect comment for num_tqps in struct hclgevf_dev

struct hclgevf_dev stands for VF device, its field num_tqps
indicates the number of VF's task queue pairs, so the comment
is incorrect, replace 'PF' with 'VF'.

Reported-by: Jian Shen <shenjian15@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agonet: hns3: remove two unused macros in hclgevf_cmd.c
Huazhong Tan [Sat, 30 May 2020 01:08:29 +0000 (09:08 +0800)]
net: hns3: remove two unused macros in hclgevf_cmd.c

Macro hclgevf_ring_to_dma_dir and hclgevf_is_csq defined in
hclgevf_cmd.c, but not used, so remove them.

Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agonet: hns3: remove an unused macro hclge_is_csq
Huazhong Tan [Sat, 30 May 2020 01:08:28 +0000 (09:08 +0800)]
net: hns3: remove an unused macro hclge_is_csq

Macro hclge_is_csq defined in hcgle_cmd.c has not been used,
so remove it.

Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agonet: hns3: fix a print format issue in hclge_mac_mdio_config()
Huazhong Tan [Sat, 30 May 2020 01:08:27 +0000 (09:08 +0800)]
net: hns3: fix a print format issue in hclge_mac_mdio_config()

Use %d to print int variable 'ret' in hclge_mac_mdio_config().

Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
4 years agoMerge tag 'powerpc-5.7-6' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc...
Linus Torvalds [Sat, 30 May 2020 19:28:44 +0000 (12:28 -0700)]
Merge tag 'powerpc-5.7-6' of git://git./linux/kernel/git/powerpc/linux

Pull powerpc fixes from Michael Ellerman:

 - a fix for the recent change to how we restore non-volatile GPRs,
   which broke our emulation of reading from the DSCR (Data Stream
   Control Register).

 - a fix for the recent rewrite of interrupt/syscall exit in C, we need
   to exclude KCOV from that code, otherwise it can lead to
   unrecoverable faults.

Thanks to Daniel Axtens.

* tag 'powerpc-5.7-6' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
  powerpc/64s: Disable sanitisers for C syscall/interrupt entry/exit code
  powerpc/64s: Fix restore of NV GPRs after facility unavailable exception

4 years agoMerge tag 'gpio-v5.7-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux...
Linus Torvalds [Sat, 30 May 2020 19:26:21 +0000 (12:26 -0700)]
Merge tag 'gpio-v5.7-3' of git://git./linux/kernel/git/linusw/linux-gpio

Pull GPIO fixes from Linus Walleij:
 "Here are some (very) late fixes for GPIO, none of them very serious
  except the one tagged for stable for enabling IRQ on open drain lines:

   - Fix probing of mvebu chips without PWM

   - Fix error path on ida_get_simple() on the exar driver

   - Notify userspace properly about line status changes when flags are
     changed on lines.

   - Fix a sleeping while holding spinlock in the mellanox driver.

   - Fix return value of the PXA and Kona probe calls.

   - Fix IRQ locking of open drain lines, it is fine to have IRQs on
     open drain lines flagged for output"

* tag 'gpio-v5.7-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
  gpio: fix locking open drain IRQ lines
  gpio: bcm-kona: Fix return value of bcm_kona_gpio_probe()
  gpio: pxa: Fix return value of pxa_gpio_probe()
  gpio: mlxbf2: Fix sleeping while holding spinlock
  gpiolib: notify user-space about line status changes after flags are set
  gpio: exar: Fix bad handling for ida_simple_get error path
  gpio: mvebu: Fix probing for chips without PWM

4 years agoMerge ath-next from git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git
Kalle Valo [Sat, 30 May 2020 14:31:27 +0000 (17:31 +0300)]
Merge ath-next from git://git./linux/kernel/git/kvalo/ath.git

ath.git patches for v5.8. Major changes:

ath9k

* allow receive of broadcast Action frames

ath9k_htc

* allow receive of broadcast Action frames

4 years agoath11k: clear DCM max constellation tx value
Muna Sinada [Thu, 28 May 2020 23:10:17 +0000 (16:10 -0700)]
ath11k: clear DCM max constellation tx value

According to 11ax spec. draft 4.0. DCM Max Constellation Tx data
field should be set to "Reserved" for an AP, therefore bit is
cleared.

Signed-off-by: Muna Sinada <msinada@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1590707417-29672-1-git-send-email-msinada@codeaurora.org
4 years agoath11k: reset trigger frame MAC padding duration
Muna Sinada [Thu, 28 May 2020 22:54:43 +0000 (15:54 -0700)]
ath11k: reset trigger frame MAC padding duration

The value was 3 and it's reserved value. Corrected to maintain fw
defaults.

Signed-off-by: Muna Sinada <msinada@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1590706483-27609-1-git-send-email-msinada@codeaurora.org
4 years agoath10k: Remove ath10k_qmi_register_service_notifier() declaration
Douglas Anderson [Thu, 28 May 2020 19:21:09 +0000 (12:21 -0700)]
ath10k: Remove ath10k_qmi_register_service_notifier() declaration

The ath10k/qmi.h header file contains a declaration for the function
ath10k_qmi_register_service_notifier().  This function doesn't exist.
Remove the declaration.

This patch is a no-op and was just found by code inspection.

Fixes: ba94c753ccb4 ("ath10k: add QMI message handshake for wcn3990 client")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200528122105.1.I31937dce728b441fd72cbe23447bc4710fd56ddb@changeid
4 years agoath9k_htc: Set RX filter based to allow broadcast Action frame RX
Jouni Malinen [Sun, 26 Apr 2020 08:47:33 +0000 (11:47 +0300)]
ath9k_htc: Set RX filter based to allow broadcast Action frame RX

Advertise support for multicast frame registration and update the RX
filter based on the recently added FIF_MCAST_ACTION to allow broadcast
Action frames to be received. This is needed for Device Provisioning
Protocol (DPP) use cases that use broadcast Public Action frames.

Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200426084733.7889-2-jouni@codeaurora.org
4 years agoath9k: Set RX filter based to allow broadcast Action frame RX
Jouni Malinen [Sun, 26 Apr 2020 08:47:32 +0000 (11:47 +0300)]
ath9k: Set RX filter based to allow broadcast Action frame RX

Advertise support for multicast frame registration and update the RX
filter based on the recently added FIF_MCAST_ACTION to allow broadcast
Action frames to be received. This is needed for Device Provisioning
Protocol (DPP) use cases that use broadcast Public Action frames.

Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200426084733.7889-1-jouni@codeaurora.org
4 years agonet/mlx5e: Make mlx5e_dcbnl_ops static
Saeed Mahameed [Fri, 29 May 2020 07:36:10 +0000 (00:36 -0700)]
net/mlx5e: Make mlx5e_dcbnl_ops static

Fix sparse warning:
drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c:988:29:
error: symbol 'mlx5e_dcbnl_ops' was not declared. Should it be static?

Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
4 years agonet/mlx5e: en_tc: Fix cast to restricted __be32 warning
Saeed Mahameed [Thu, 28 May 2020 07:22:12 +0000 (00:22 -0700)]
net/mlx5e: en_tc: Fix cast to restricted __be32 warning

Fixes sparse warnings:
warning: cast to restricted __be32
warning: restricted __be32 degrades to integer

Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Reviewed-by: Mark Bloch <markb@mellanox.com>
4 years agonet/mlx5e: en_tc: Fix incorrect type in initializer warnings
Saeed Mahameed [Thu, 28 May 2020 06:41:03 +0000 (23:41 -0700)]
net/mlx5e: en_tc: Fix incorrect type in initializer warnings

Fix some trivial warnings of the type:
warning: incorrect type in initializer (different base types)

Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Reviewed-by: Mark Bloch <markb@mellanox.com>
4 years agonet/mlx5: IPSec: Fix incorrect type for spi
Saeed Mahameed [Fri, 29 May 2020 07:47:12 +0000 (00:47 -0700)]
net/mlx5: IPSec: Fix incorrect type for spi

spi is __be32, fix that.

Fixes sparse warning:
drivers/net/ethernet/mellanox/mlx5/core/accel/ipsec.c:74:64
warning: incorrect type

Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
4 years agonet/mlx5: Accel: fpga tls fix cast to __be64 and incorrect argument types
Saeed Mahameed [Fri, 29 May 2020 01:42:40 +0000 (18:42 -0700)]
net/mlx5: Accel: fpga tls fix cast to __be64 and incorrect argument types

tls handle and rcd_sn are actually big endian and not in host format.
Fix that.

Fix the following sparse warnings:
drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls.c:177:21:
warning: cast to restricted __be64

drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls.c:178:52:
warning: incorrect type in argument 2 (different base types)
    expected unsigned int [usertype] handle
    got restricted __be32 [usertype] handle

Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
4 years agonet/mlx5: cmd: Fix memset with byte count warning
Saeed Mahameed [Thu, 28 May 2020 06:16:02 +0000 (23:16 -0700)]
net/mlx5: cmd: Fix memset with byte count warning

Fix sparse warning:
drivers/net/ethernet/mellanox/mlx5/core/cmd.c:1949:15:
warning: memset with byte count of 271720

mlx5_cmd_stats array is too big to be held inline in mlx5_cmd.
Allocate it separately.

Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
4 years agonet/mlx5: DR: Fix incorrect type in return expression
Saeed Mahameed [Thu, 28 May 2020 08:14:31 +0000 (01:14 -0700)]
net/mlx5: DR: Fix incorrect type in return expression

dr_ste_crc32_calc() calculates crc32 and should return it in HW format.
It is being used to calculate a u32 index, hence we force the return value
of u32 to avoid the sparse warning:

drivers/net/ethernet/mellanox/mlx5/core/steering/dr_ste.c:115:16:
warning: incorrect type in return expression (different base types)
    expected unsigned int
    got restricted __be32 [usertype]

Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Reviewed-by: Mark Bloch <markb@mellanox.com>
4 years agonet/mlx5: DR: Fix cast to restricted __be32
Saeed Mahameed [Thu, 28 May 2020 08:11:37 +0000 (01:11 -0700)]
net/mlx5: DR: Fix cast to restricted __be32

raw_ip actual type is __be32 and not u32.
Fix that and get rid of the warning.

drivers/net/ethernet/mellanox/mlx5/core/steering/dr_ste.c:906:31:
warning: cast to restricted __be32

Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Reviewed-by: Mark Bloch <markb@mellanox.com>
4 years agonet/mlx5: DR: Fix incorrect type in argument
Saeed Mahameed [Thu, 28 May 2020 08:02:08 +0000 (01:02 -0700)]
net/mlx5: DR: Fix incorrect type in argument

HW spec objects should receive a void ptr to work on, the MLX5_SET/GET
macro will know how to handle it.

No need to provide explicit or wrong pointer type in this case.

warning: incorrect type in argument 1 (different base types)
    expected unsigned long long const [usertype] *sw_action
    got restricted __be64 [usertype] *[assigned] sw_action

Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Reviewed-by: Mark Bloch <markb@mellanox.com>
4 years agonet/mlx5e: Use generic API to build MPLS label
Eli Cohen [Wed, 27 May 2020 05:38:03 +0000 (08:38 +0300)]
net/mlx5e: Use generic API to build MPLS label

Make use of generic API mpls_entry_encode() to build mpls label and get
rid of local function.

Signed-off-by: Eli Cohen <eli@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
4 years agonet: Make mpls_entry_encode() available for generic users
Eli Cohen [Wed, 27 May 2020 05:35:03 +0000 (08:35 +0300)]
net: Make mpls_entry_encode() available for generic users

Move mpls_entry_encode() from net/mpls/internal.h to include/net/mpls.h
and make it available for other users. Specifically, hardware driver that
offload MPLS can benefit from that.

Suggested-by: Jakub Kicinski <kuba@kernel.org>
Suggested-by: David Ahern <dsahern@gmail.com>
Signed-off-by: Eli Cohen <eli@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
4 years agonet/mlx5: reduce stack usage in qp_read_field
Arnd Bergmann [Tue, 28 Apr 2020 21:23:47 +0000 (23:23 +0200)]
net/mlx5: reduce stack usage in qp_read_field

Moving the mlx5_ifc_query_qp_out_bits structure on the stack was a bit
excessive and now causes the compiler to complain on 32-bit architectures:

drivers/net/ethernet/mellanox/mlx5/core/debugfs.c: In function 'qp_read_field':
drivers/net/ethernet/mellanox/mlx5/core/debugfs.c:274:1: error: the frame size of 1104 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]

Revert the previous patch partially to use dynamically allocation as
the code did before. Unfortunately there is no good error handling
in case the allocation fails.

Fixes: 57a6c5e992f5 ("net/mlx5: Replace hand written QP context struct with automatic getters")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>