--- /dev/null
+From 3b9ea7206d7e1fdd7419cbd10badd3b2c80d04b4 Mon Sep 17 00:00:00 2001
+From: Felix Fietkau <nbd@nbd.name>
+Date: Sun, 14 Feb 2021 19:49:11 +0100
+Subject: ath9k: fix transmitting to stations in dynamic SMPS mode
+
+From: Felix Fietkau <nbd@nbd.name>
+
+commit 3b9ea7206d7e1fdd7419cbd10badd3b2c80d04b4 upstream.
+
+When transmitting to a receiver in dynamic SMPS mode, all transmissions that
+use multiple spatial streams need to be sent using CTS-to-self or RTS/CTS to
+give the receiver's extra chains some time to wake up.
+This fixes the tx rate getting stuck at <= MCS7 for some clients, especially
+Intel ones, which make aggressive use of SMPS.
+
+Cc: stable@vger.kernel.org
+Reported-by: Martin Kennedy <hurricos@gmail.com>
+Signed-off-by: Felix Fietkau <nbd@nbd.name>
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+Link: https://lore.kernel.org/r/20210214184911.96702-1-nbd@nbd.name
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/wireless/ath/ath9k/ath9k.h | 3 ++-
+ drivers/net/wireless/ath/ath9k/xmit.c | 6 ++++++
+ 2 files changed, 8 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/wireless/ath/ath9k/ath9k.h
++++ b/drivers/net/wireless/ath/ath9k/ath9k.h
+@@ -177,7 +177,8 @@ struct ath_frame_info {
+ s8 txq;
+ u8 keyix;
+ u8 rtscts_rate;
+- u8 retries : 7;
++ u8 retries : 6;
++ u8 dyn_smps : 1;
+ u8 baw_tracked : 1;
+ u8 tx_power;
+ enum ath9k_key_type keytype:2;
+--- a/drivers/net/wireless/ath/ath9k/xmit.c
++++ b/drivers/net/wireless/ath/ath9k/xmit.c
+@@ -1271,6 +1271,11 @@ static void ath_buf_set_rate(struct ath_
+ is_40, is_sgi, is_sp);
+ if (rix < 8 && (tx_info->flags & IEEE80211_TX_CTL_STBC))
+ info->rates[i].RateFlags |= ATH9K_RATESERIES_STBC;
++ if (rix >= 8 && fi->dyn_smps) {
++ info->rates[i].RateFlags |=
++ ATH9K_RATESERIES_RTS_CTS;
++ info->flags |= ATH9K_TXDESC_CTSENA;
++ }
+
+ info->txpower[i] = ath_get_rate_txpower(sc, bf, rix,
+ is_40, false);
+@@ -2114,6 +2119,7 @@ static void setup_frame_info(struct ieee
+ fi->keyix = an->ps_key;
+ else
+ fi->keyix = ATH9K_TXKEYIX_INVALID;
++ fi->dyn_smps = sta && sta->smps_mode == IEEE80211_SMPS_DYNAMIC;
+ fi->keytype = keytype;
+ fi->framelen = framelen;
+ fi->tx_power = txpower;
--- /dev/null
+From 6c810cf20feef0d4338e9b424ab7f2644a8b353e Mon Sep 17 00:00:00 2001
+From: "Maciej W. Rozycki" <macro@orcam.me.uk>
+Date: Wed, 3 Mar 2021 02:16:04 +0100
+Subject: crypto: mips/poly1305 - enable for all MIPS processors
+
+From: Maciej W. Rozycki <macro@orcam.me.uk>
+
+commit 6c810cf20feef0d4338e9b424ab7f2644a8b353e upstream.
+
+The MIPS Poly1305 implementation is generic MIPS code written such as to
+support down to the original MIPS I and MIPS III ISA for the 32-bit and
+64-bit variant respectively. Lift the current limitation then to enable
+code for MIPSr1 ISA or newer processors only and have it available for
+all MIPS processors.
+
+Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
+Fixes: a11d055e7a64 ("crypto: mips/poly1305 - incorporate OpenSSL/CRYPTOGAMS optimized implementation")
+Cc: stable@vger.kernel.org # v5.5+
+Acked-by: Jason A. Donenfeld <Jason@zx2c4.com>
+Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/mips/crypto/Makefile | 4 ++--
+ crypto/Kconfig | 2 +-
+ drivers/net/Kconfig | 2 +-
+ 3 files changed, 4 insertions(+), 4 deletions(-)
+
+--- a/arch/mips/crypto/Makefile
++++ b/arch/mips/crypto/Makefile
+@@ -12,8 +12,8 @@ AFLAGS_chacha-core.o += -O2 # needed to
+ obj-$(CONFIG_CRYPTO_POLY1305_MIPS) += poly1305-mips.o
+ poly1305-mips-y := poly1305-core.o poly1305-glue.o
+
+-perlasm-flavour-$(CONFIG_CPU_MIPS32) := o32
+-perlasm-flavour-$(CONFIG_CPU_MIPS64) := 64
++perlasm-flavour-$(CONFIG_32BIT) := o32
++perlasm-flavour-$(CONFIG_64BIT) := 64
+
+ quiet_cmd_perlasm = PERLASM $@
+ cmd_perlasm = $(PERL) $(<) $(perlasm-flavour-y) $(@)
+--- a/crypto/Kconfig
++++ b/crypto/Kconfig
+@@ -772,7 +772,7 @@ config CRYPTO_POLY1305_X86_64
+
+ config CRYPTO_POLY1305_MIPS
+ tristate "Poly1305 authenticator algorithm (MIPS optimized)"
+- depends on CPU_MIPS32 || (CPU_MIPS64 && 64BIT)
++ depends on MIPS
+ select CRYPTO_ARCH_HAVE_LIB_POLY1305
+
+ config CRYPTO_MD4
+--- a/drivers/net/Kconfig
++++ b/drivers/net/Kconfig
+@@ -92,7 +92,7 @@ config WIREGUARD
+ select CRYPTO_POLY1305_ARM if ARM
+ select CRYPTO_CURVE25519_NEON if ARM && KERNEL_MODE_NEON
+ select CRYPTO_CHACHA_MIPS if CPU_MIPS32_R2
+- select CRYPTO_POLY1305_MIPS if CPU_MIPS32 || (CPU_MIPS64 && 64BIT)
++ select CRYPTO_POLY1305_MIPS if MIPS
+ help
+ WireGuard is a secure, fast, and easy to use replacement for IPSec
+ that uses modern cryptography and clever networking tricks. It's
--- /dev/null
+From a4dcfbc4ee2218abd567d81d795082d8d4afcdf6 Mon Sep 17 00:00:00 2001
+From: Jakub Kicinski <kuba@kernel.org>
+Date: Fri, 5 Mar 2021 14:17:29 -0800
+Subject: ethernet: alx: fix order of calls on resume
+
+From: Jakub Kicinski <kuba@kernel.org>
+
+commit a4dcfbc4ee2218abd567d81d795082d8d4afcdf6 upstream.
+
+netif_device_attach() will unpause the queues so we can't call
+it before __alx_open(). This went undetected until
+commit b0999223f224 ("alx: add ability to allocate and free
+alx_napi structures") but now if stack tries to xmit immediately
+on resume before __alx_open() we'll crash on the NAPI being null:
+
+ BUG: kernel NULL pointer dereference, address: 0000000000000198
+ CPU: 0 PID: 12 Comm: ksoftirqd/0 Tainted: G OE 5.10.0-3-amd64 #1 Debian 5.10.13-1
+ Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./H77-D3H, BIOS F15 11/14/2013
+ RIP: 0010:alx_start_xmit+0x34/0x650 [alx]
+ Code: 41 56 41 55 41 54 55 53 48 83 ec 20 0f b7 57 7c 8b 8e b0
+0b 00 00 39 ca 72 06 89 d0 31 d2 f7 f1 89 d2 48 8b 84 df
+ RSP: 0018:ffffb09240083d28 EFLAGS: 00010297
+ RAX: 0000000000000000 RBX: ffffa04d80ae7800 RCX: 0000000000000004
+ RDX: 0000000000000000 RSI: ffffa04d80afa000 RDI: ffffa04e92e92a00
+ RBP: 0000000000000042 R08: 0000000000000100 R09: ffffa04ea3146700
+ R10: 0000000000000014 R11: 0000000000000000 R12: ffffa04e92e92100
+ R13: 0000000000000001 R14: ffffa04e92e92a00 R15: ffffa04e92e92a00
+ FS: 0000000000000000(0000) GS:ffffa0508f600000(0000) knlGS:0000000000000000
+ i915 0000:00:02.0: vblank wait timed out on crtc 0
+ CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+ CR2: 0000000000000198 CR3: 000000004460a001 CR4: 00000000001706f0
+ Call Trace:
+ dev_hard_start_xmit+0xc7/0x1e0
+ sch_direct_xmit+0x10f/0x310
+
+Cc: <stable@vger.kernel.org> # 4.9+
+Fixes: bc2bebe8de8e ("alx: remove WoL support")
+Reported-by: Zbynek Michl <zbynek.michl@gmail.com>
+Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983595
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Tested-by: Zbynek Michl <zbynek.michl@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/atheros/alx/main.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/drivers/net/ethernet/atheros/alx/main.c
++++ b/drivers/net/ethernet/atheros/alx/main.c
+@@ -1894,13 +1894,16 @@ static int alx_resume(struct device *dev
+
+ if (!netif_running(alx->dev))
+ return 0;
+- netif_device_attach(alx->dev);
+
+ rtnl_lock();
+ err = __alx_open(alx, true);
+ rtnl_unlock();
++ if (err)
++ return err;
++
++ netif_device_attach(alx->dev);
+
+- return err;
++ return 0;
+ }
+
+ static SIMPLE_DEV_PM_OPS(alx_pm_ops, alx_suspend, alx_resume);
--- /dev/null
+From d348ede32e99d3a04863e9f9b28d224456118c27 Mon Sep 17 00:00:00 2001
+From: Balazs Nemeth <bnemeth@redhat.com>
+Date: Tue, 9 Mar 2021 12:31:01 +0100
+Subject: net: avoid infinite loop in mpls_gso_segment when mpls_hlen == 0
+
+From: Balazs Nemeth <bnemeth@redhat.com>
+
+commit d348ede32e99d3a04863e9f9b28d224456118c27 upstream.
+
+A packet with skb_inner_network_header(skb) == skb_network_header(skb)
+and ETH_P_MPLS_UC will prevent mpls_gso_segment from pulling any headers
+from the packet. Subsequently, the call to skb_mac_gso_segment will
+again call mpls_gso_segment with the same packet leading to an infinite
+loop. In addition, ensure that the header length is a multiple of four,
+which should hold irrespective of the number of stacked labels.
+
+Signed-off-by: Balazs Nemeth <bnemeth@redhat.com>
+Acked-by: Willem de Bruijn <willemb@google.com>
+Reviewed-by: David Ahern <dsahern@kernel.org>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/mpls/mpls_gso.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/net/mpls/mpls_gso.c
++++ b/net/mpls/mpls_gso.c
+@@ -14,6 +14,7 @@
+ #include <linux/netdev_features.h>
+ #include <linux/netdevice.h>
+ #include <linux/skbuff.h>
++#include <net/mpls.h>
+
+ static struct sk_buff *mpls_gso_segment(struct sk_buff *skb,
+ netdev_features_t features)
+@@ -27,6 +28,8 @@ static struct sk_buff *mpls_gso_segment(
+
+ skb_reset_network_header(skb);
+ mpls_hlen = skb_inner_network_header(skb) - skb_network_header(skb);
++ if (unlikely(!mpls_hlen || mpls_hlen % MPLS_HLEN))
++ goto out;
+ if (unlikely(!pskb_may_pull(skb, mpls_hlen)))
+ goto out;
+
--- /dev/null
+From 924a9bc362a5223cd448ca08c3dde21235adc310 Mon Sep 17 00:00:00 2001
+From: Balazs Nemeth <bnemeth@redhat.com>
+Date: Tue, 9 Mar 2021 12:31:00 +0100
+Subject: net: check if protocol extracted by virtio_net_hdr_set_proto is correct
+
+From: Balazs Nemeth <bnemeth@redhat.com>
+
+commit 924a9bc362a5223cd448ca08c3dde21235adc310 upstream.
+
+For gso packets, virtio_net_hdr_set_proto sets the protocol (if it isn't
+set) based on the type in the virtio net hdr, but the skb could contain
+anything since it could come from packet_snd through a raw socket. If
+there is a mismatch between what virtio_net_hdr_set_proto sets and
+the actual protocol, then the skb could be handled incorrectly later
+on.
+
+An example where this poses an issue is with the subsequent call to
+skb_flow_dissect_flow_keys_basic which relies on skb->protocol being set
+correctly. A specially crafted packet could fool
+skb_flow_dissect_flow_keys_basic preventing EINVAL to be returned.
+
+Avoid blindly trusting the information provided by the virtio net header
+by checking that the protocol in the packet actually matches the
+protocol set by virtio_net_hdr_set_proto. Note that since the protocol
+is only checked if skb->dev implements header_ops->parse_protocol,
+packets from devices without the implementation are not checked at this
+stage.
+
+Fixes: 9274124f023b ("net: stricter validation of untrusted gso packets")
+Signed-off-by: Balazs Nemeth <bnemeth@redhat.com>
+Acked-by: Willem de Bruijn <willemb@google.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/linux/virtio_net.h | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/include/linux/virtio_net.h
++++ b/include/linux/virtio_net.h
+@@ -79,8 +79,13 @@ static inline int virtio_net_hdr_to_skb(
+ if (gso_type && skb->network_header) {
+ struct flow_keys_basic keys;
+
+- if (!skb->protocol)
++ if (!skb->protocol) {
++ __be16 protocol = dev_parse_header_protocol(skb);
++
+ virtio_net_hdr_set_proto(skb, hdr);
++ if (protocol && protocol != skb->protocol)
++ return -EINVAL;
++ }
+ retry:
+ if (!skb_flow_dissect_flow_keys_basic(NULL, skb, &keys,
+ NULL, 0, 0, 0,
--- /dev/null
+From 89e5c58fc1e2857ccdaae506fb8bc5fed57ee063 Mon Sep 17 00:00:00 2001
+From: Daniel Borkmann <daniel@iogearbox.net>
+Date: Fri, 26 Feb 2021 22:22:48 +0100
+Subject: net: Fix gro aggregation for udp encaps with zero csum
+
+From: Daniel Borkmann <daniel@iogearbox.net>
+
+commit 89e5c58fc1e2857ccdaae506fb8bc5fed57ee063 upstream.
+
+We noticed a GRO issue for UDP-based encaps such as vxlan/geneve when the
+csum for the UDP header itself is 0. In that case, GRO aggregation does
+not take place on the phys dev, but instead is deferred to the vxlan/geneve
+driver (see trace below).
+
+The reason is essentially that GRO aggregation bails out in udp_gro_receive()
+for such case when drivers marked the skb with CHECKSUM_UNNECESSARY (ice, i40e,
+others) where for non-zero csums 2abb7cdc0dc8 ("udp: Add support for doing
+checksum unnecessary conversion") promotes those skbs to CHECKSUM_COMPLETE
+and napi context has csum_valid set. This is however not the case for zero
+UDP csum (here: csum_cnt is still 0 and csum_valid continues to be false).
+
+At the same time 57c67ff4bd92 ("udp: additional GRO support") added matches
+on !uh->check ^ !uh2->check as part to determine candidates for aggregation,
+so it certainly is expected to handle zero csums in udp_gro_receive(). The
+purpose of the check added via 662880f44203 ("net: Allow GRO to use and set
+levels of checksum unnecessary") seems to catch bad csum and stop aggregation
+right away.
+
+One way to fix aggregation in the zero case is to only perform the !csum_valid
+check in udp_gro_receive() if uh->check is infact non-zero.
+
+Before:
+
+ [...]
+ swapper 0 [008] 731.946506: net:netif_receive_skb: dev=enp10s0f0 skbaddr=0xffff966497100400 len=1500 (1)
+ swapper 0 [008] 731.946507: net:netif_receive_skb: dev=enp10s0f0 skbaddr=0xffff966497100200 len=1500
+ swapper 0 [008] 731.946507: net:netif_receive_skb: dev=enp10s0f0 skbaddr=0xffff966497101100 len=1500
+ swapper 0 [008] 731.946508: net:netif_receive_skb: dev=enp10s0f0 skbaddr=0xffff966497101700 len=1500
+ swapper 0 [008] 731.946508: net:netif_receive_skb: dev=enp10s0f0 skbaddr=0xffff966497101b00 len=1500
+ swapper 0 [008] 731.946508: net:netif_receive_skb: dev=enp10s0f0 skbaddr=0xffff966497100600 len=1500
+ swapper 0 [008] 731.946508: net:netif_receive_skb: dev=enp10s0f0 skbaddr=0xffff966497100f00 len=1500
+ swapper 0 [008] 731.946509: net:netif_receive_skb: dev=enp10s0f0 skbaddr=0xffff966497100a00 len=1500
+ swapper 0 [008] 731.946516: net:netif_receive_skb: dev=enp10s0f0 skbaddr=0xffff966497100500 len=1500
+ swapper 0 [008] 731.946516: net:netif_receive_skb: dev=enp10s0f0 skbaddr=0xffff966497100700 len=1500
+ swapper 0 [008] 731.946516: net:netif_receive_skb: dev=enp10s0f0 skbaddr=0xffff966497101d00 len=1500 (2)
+ swapper 0 [008] 731.946517: net:netif_receive_skb: dev=enp10s0f0 skbaddr=0xffff966497101000 len=1500
+ swapper 0 [008] 731.946517: net:netif_receive_skb: dev=enp10s0f0 skbaddr=0xffff966497101c00 len=1500
+ swapper 0 [008] 731.946517: net:netif_receive_skb: dev=enp10s0f0 skbaddr=0xffff966497101400 len=1500
+ swapper 0 [008] 731.946518: net:netif_receive_skb: dev=enp10s0f0 skbaddr=0xffff966497100e00 len=1500
+ swapper 0 [008] 731.946518: net:netif_receive_skb: dev=enp10s0f0 skbaddr=0xffff966497101600 len=1500
+ swapper 0 [008] 731.946521: net:netif_receive_skb: dev=enp10s0f0 skbaddr=0xffff966497100800 len=774
+ swapper 0 [008] 731.946530: net:netif_receive_skb: dev=test_vxlan skbaddr=0xffff966497100400 len=14032 (1)
+ swapper 0 [008] 731.946530: net:netif_receive_skb: dev=test_vxlan skbaddr=0xffff966497101d00 len=9112 (2)
+ [...]
+
+ # netperf -H 10.55.10.4 -t TCP_STREAM -l 20
+ MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.55.10.4 () port 0 AF_INET : demo
+ Recv Send Send
+ Socket Socket Message Elapsed
+ Size Size Size Time Throughput
+ bytes bytes bytes secs. 10^6bits/sec
+
+ 87380 16384 16384 20.01 13129.24
+
+After:
+
+ [...]
+ swapper 0 [026] 521.862641: net:netif_receive_skb: dev=enp10s0f0 skbaddr=0xffff93ab0d479000 len=11286 (1)
+ swapper 0 [026] 521.862643: net:netif_receive_skb: dev=test_vxlan skbaddr=0xffff93ab0d479000 len=11236 (1)
+ swapper 0 [026] 521.862650: net:netif_receive_skb: dev=enp10s0f0 skbaddr=0xffff93ab0d478500 len=2898 (2)
+ swapper 0 [026] 521.862650: net:netif_receive_skb: dev=enp10s0f0 skbaddr=0xffff93ab0d479f00 len=8490 (3)
+ swapper 0 [026] 521.862653: net:netif_receive_skb: dev=test_vxlan skbaddr=0xffff93ab0d478500 len=2848 (2)
+ swapper 0 [026] 521.862653: net:netif_receive_skb: dev=test_vxlan skbaddr=0xffff93ab0d479f00 len=8440 (3)
+ [...]
+
+ # netperf -H 10.55.10.4 -t TCP_STREAM -l 20
+ MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.55.10.4 () port 0 AF_INET : demo
+ Recv Send Send
+ Socket Socket Message Elapsed
+ Size Size Size Time Throughput
+ bytes bytes bytes secs. 10^6bits/sec
+
+ 87380 16384 16384 20.01 24576.53
+
+Fixes: 57c67ff4bd92 ("udp: additional GRO support")
+Fixes: 662880f44203 ("net: Allow GRO to use and set levels of checksum unnecessary")
+Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
+Cc: Eric Dumazet <edumazet@google.com>
+Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
+Cc: Tom Herbert <tom@herbertland.com>
+Acked-by: Willem de Bruijn <willemb@google.com>
+Acked-by: John Fastabend <john.fastabend@gmail.com>
+Link: https://lore.kernel.org/r/20210226212248.8300-1-daniel@iogearbox.net
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ipv4/udp_offload.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/ipv4/udp_offload.c
++++ b/net/ipv4/udp_offload.c
+@@ -522,7 +522,7 @@ struct sk_buff *udp_gro_receive(struct l
+ }
+
+ if (!sk || NAPI_GRO_CB(skb)->encap_mark ||
+- (skb->ip_summed != CHECKSUM_PARTIAL &&
++ (uh->check && skb->ip_summed != CHECKSUM_PARTIAL &&
+ NAPI_GRO_CB(skb)->csum_cnt == 0 &&
+ !NAPI_GRO_CB(skb)->csum_valid) ||
+ !udp_sk(sk)->gro_receive)
--- /dev/null
+From 5ae5fbd2107959b68ac69a8b75412208663aea88 Mon Sep 17 00:00:00 2001
+From: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
+Date: Thu, 25 Feb 2021 05:10:39 -0500
+Subject: powerpc/perf: Fix handling of privilege level checks in perf interrupt context
+
+From: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
+
+commit 5ae5fbd2107959b68ac69a8b75412208663aea88 upstream.
+
+Running "perf mem record" in powerpc platforms with selinux enabled
+resulted in soft lockup's. Below call-trace was seen in the logs:
+
+ CPU: 58 PID: 3751 Comm: sssd_nss Not tainted 5.11.0-rc7+ #2
+ NIP: c000000000dff3d4 LR: c000000000dff3d0 CTR: 0000000000000000
+ REGS: c000007fffab7d60 TRAP: 0100 Not tainted (5.11.0-rc7+)
+ ...
+ NIP _raw_spin_lock_irqsave+0x94/0x120
+ LR _raw_spin_lock_irqsave+0x90/0x120
+ Call Trace:
+ 0xc00000000fd47260 (unreliable)
+ skb_queue_tail+0x3c/0x90
+ audit_log_end+0x6c/0x180
+ common_lsm_audit+0xb0/0xe0
+ slow_avc_audit+0xa4/0x110
+ avc_has_perm+0x1c4/0x260
+ selinux_perf_event_open+0x74/0xd0
+ security_perf_event_open+0x68/0xc0
+ record_and_restart+0x6e8/0x7f0
+ perf_event_interrupt+0x22c/0x560
+ performance_monitor_exception0x4c/0x60
+ performance_monitor_common_virt+0x1c8/0x1d0
+ interrupt: f00 at _raw_spin_lock_irqsave+0x38/0x120
+ NIP: c000000000dff378 LR: c000000000b5fbbc CTR: c0000000007d47f0
+ REGS: c00000000fd47860 TRAP: 0f00 Not tainted (5.11.0-rc7+)
+ ...
+ NIP _raw_spin_lock_irqsave+0x38/0x120
+ LR skb_queue_tail+0x3c/0x90
+ interrupt: f00
+ 0x38 (unreliable)
+ 0xc00000000aae6200
+ audit_log_end+0x6c/0x180
+ audit_log_exit+0x344/0xf80
+ __audit_syscall_exit+0x2c0/0x320
+ do_syscall_trace_leave+0x148/0x200
+ syscall_exit_prepare+0x324/0x390
+ system_call_common+0xfc/0x27c
+
+The above trace shows that while the CPU was handling a performance
+monitor exception, there was a call to security_perf_event_open()
+function. In powerpc core-book3s, this function is called from
+perf_allow_kernel() check during recording of data address in the
+sample via perf_get_data_addr().
+
+Commit da97e18458fb ("perf_event: Add support for LSM and SELinux
+checks") introduced security enhancements to perf. As part of this
+commit, the new security hook for perf_event_open() was added in all
+places where perf paranoid check was previously used. In powerpc
+core-book3s code, originally had paranoid checks in
+perf_get_data_addr() and power_pmu_bhrb_read(). So
+perf_paranoid_kernel() checks were replaced with perf_allow_kernel()
+in these PMU helper functions as well.
+
+The intention of paranoid checks in core-book3s was to verify
+privilege access before capturing some of the sample data. Along with
+paranoid checks, perf_allow_kernel() also does a
+security_perf_event_open(). Since these functions are accessed while
+recording a sample, we end up calling selinux_perf_event_open() in PMI
+context. Some of the security functions use spinlock like
+sidtab_sid2str_put(). If a perf interrupt hits under a spin lock and
+if we end up in calling selinux hook functions in PMI handler, this
+could cause a dead lock.
+
+Since the purpose of this security hook is to control access to
+perf_event_open(), it is not right to call this in interrupt context.
+
+The paranoid checks in powerpc core-book3s were done at interrupt time
+which is also not correct.
+
+Reference commits:
+ Commit cd1231d7035f ("powerpc/perf: Prevent kernel address leak via perf_get_data_addr()")
+ Commit bb19af816025 ("powerpc/perf: Prevent kernel address leak to userspace via BHRB buffer")
+
+We only allow creation of events that have already passed the
+privilege checks in perf_event_open(). So these paranoid checks are
+not needed at event time. As a fix, patch uses
+'event->attr.exclude_kernel' check to prevent exposing kernel address
+for userspace only sampling.
+
+Fixes: cd1231d7035f ("powerpc/perf: Prevent kernel address leak via perf_get_data_addr()")
+Cc: stable@vger.kernel.org # v4.17+
+Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
+Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/1614247839-1428-1-git-send-email-atrajeev@linux.vnet.ibm.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/powerpc/perf/core-book3s.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/powerpc/perf/core-book3s.c
++++ b/arch/powerpc/perf/core-book3s.c
+@@ -211,7 +211,7 @@ static inline void perf_get_data_addr(st
+ if (!(mmcra & MMCRA_SAMPLE_ENABLE) || sdar_valid)
+ *addrp = mfspr(SPRN_SDAR);
+
+- if (is_kernel_addr(mfspr(SPRN_SDAR)) && perf_allow_kernel(&event->attr) != 0)
++ if (is_kernel_addr(mfspr(SPRN_SDAR)) && event->attr.exclude_kernel)
+ *addrp = 0;
+ }
+
+@@ -477,7 +477,7 @@ static void power_pmu_bhrb_read(struct p
+ * addresses, hence include a check before filtering code
+ */
+ if (!(ppmu->flags & PPMU_ARCH_31) &&
+- is_kernel_addr(addr) && perf_allow_kernel(&event->attr) != 0)
++ is_kernel_addr(addr) && event->attr.exclude_kernel)
+ continue;
+
+ /* Branches are read most recent first (ie. mfbhrb 0 is
--- /dev/null
+From f9619d5e5174867536b7e558683bc4408eab833f Mon Sep 17 00:00:00 2001
+From: Greg Kurz <groug@kaod.org>
+Date: Mon, 15 Feb 2021 10:45:06 +0100
+Subject: powerpc/pseries: Don't enforce MSI affinity with kdump
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Greg Kurz <groug@kaod.org>
+
+commit f9619d5e5174867536b7e558683bc4408eab833f upstream.
+
+Depending on the number of online CPUs in the original kernel, it is
+likely for CPU #0 to be offline in a kdump kernel. The associated IRQs
+in the affinity mappings provided by irq_create_affinity_masks() are
+thus not started by irq_startup(), as per-design with managed IRQs.
+
+This can be a problem with multi-queue block devices driven by blk-mq :
+such a non-started IRQ is very likely paired with the single queue
+enforced by blk-mq during kdump (see blk_mq_alloc_tag_set()). This
+causes the device to remain silent and likely hangs the guest at
+some point.
+
+This is a regression caused by commit 9ea69a55b3b9 ("powerpc/pseries:
+Pass MSI affinity to irq_create_mapping()"). Note that this only happens
+with the XIVE interrupt controller because XICS has a workaround to bypass
+affinity, which is activated during kdump with the "noirqdistrib" kernel
+parameter.
+
+The issue comes from a combination of factors:
+- discrepancy between the number of queues detected by the multi-queue
+ block driver, that was used to create the MSI vectors, and the single
+ queue mode enforced later on by blk-mq because of kdump (i.e. keeping
+ all queues fixes the issue)
+- CPU#0 offline (i.e. kdump always succeed with CPU#0)
+
+Given that I couldn't reproduce on x86, which seems to always have CPU#0
+online even during kdump, I'm not sure where this should be fixed. Hence
+going for another approach : fine-grained affinity is for performance
+and we don't really care about that during kdump. Simply revert to the
+previous working behavior of ignoring affinity masks in this case only.
+
+Fixes: 9ea69a55b3b9 ("powerpc/pseries: Pass MSI affinity to irq_create_mapping()")
+Cc: stable@vger.kernel.org # v5.10+
+Signed-off-by: Greg Kurz <groug@kaod.org>
+Reviewed-by: Laurent Vivier <lvivier@redhat.com>
+Reviewed-by: Cédric Le Goater <clg@kaod.org>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20210215094506.1196119-1-groug@kaod.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/powerpc/platforms/pseries/msi.c | 25 +++++++++++++++++++++++--
+ 1 file changed, 23 insertions(+), 2 deletions(-)
+
+--- a/arch/powerpc/platforms/pseries/msi.c
++++ b/arch/powerpc/platforms/pseries/msi.c
+@@ -4,6 +4,7 @@
+ * Copyright 2006-2007 Michael Ellerman, IBM Corp.
+ */
+
++#include <linux/crash_dump.h>
+ #include <linux/device.h>
+ #include <linux/irq.h>
+ #include <linux/msi.h>
+@@ -458,8 +459,28 @@ again:
+ return hwirq;
+ }
+
+- virq = irq_create_mapping_affinity(NULL, hwirq,
+- entry->affinity);
++ /*
++ * Depending on the number of online CPUs in the original
++ * kernel, it is likely for CPU #0 to be offline in a kdump
++ * kernel. The associated IRQs in the affinity mappings
++ * provided by irq_create_affinity_masks() are thus not
++ * started by irq_startup(), as per-design for managed IRQs.
++ * This can be a problem with multi-queue block devices driven
++ * by blk-mq : such a non-started IRQ is very likely paired
++ * with the single queue enforced by blk-mq during kdump (see
++ * blk_mq_alloc_tag_set()). This causes the device to remain
++ * silent and likely hangs the guest at some point.
++ *
++ * We don't really care for fine-grained affinity when doing
++ * kdump actually : simply ignore the pre-computed affinity
++ * masks in this case and let the default mask with all CPUs
++ * be used when creating the IRQ mappings.
++ */
++ if (is_kdump_kernel())
++ virq = irq_create_mapping(NULL, hwirq);
++ else
++ virq = irq_create_mapping_affinity(NULL, hwirq,
++ entry->affinity);
+
+ if (!virq) {
+ pr_debug("rtas_msi: Failed mapping hwirq %d\n", hwirq);
--- /dev/null
+uapi-nfnetlink_cthelper.h-fix-userspace-compilation-error.patch
+powerpc-perf-fix-handling-of-privilege-level-checks-in-perf-interrupt-context.patch
+powerpc-pseries-don-t-enforce-msi-affinity-with-kdump.patch
+ethernet-alx-fix-order-of-calls-on-resume.patch
+crypto-mips-poly1305-enable-for-all-mips-processors.patch
+ath9k-fix-transmitting-to-stations-in-dynamic-smps-mode.patch
+net-fix-gro-aggregation-for-udp-encaps-with-zero-csum.patch
+net-check-if-protocol-extracted-by-virtio_net_hdr_set_proto-is-correct.patch
+net-avoid-infinite-loop-in-mpls_gso_segment-when-mpls_hlen-0.patch
--- /dev/null
+From c33cb0020ee6dd96cc9976d6085a7d8422f6dbed Mon Sep 17 00:00:00 2001
+From: "Dmitry V. Levin" <ldv@altlinux.org>
+Date: Mon, 22 Feb 2021 08:00:00 +0000
+Subject: uapi: nfnetlink_cthelper.h: fix userspace compilation error
+
+From: Dmitry V. Levin <ldv@altlinux.org>
+
+commit c33cb0020ee6dd96cc9976d6085a7d8422f6dbed upstream.
+
+Apparently, <linux/netfilter/nfnetlink_cthelper.h> and
+<linux/netfilter/nfnetlink_acct.h> could not be included into the same
+compilation unit because of a cut-and-paste typo in the former header.
+
+Fixes: 12f7a505331e6 ("netfilter: add user-space connection tracking helper infrastructure")
+Cc: <stable@vger.kernel.org> # v3.6
+Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
+Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/uapi/linux/netfilter/nfnetlink_cthelper.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/include/uapi/linux/netfilter/nfnetlink_cthelper.h
++++ b/include/uapi/linux/netfilter/nfnetlink_cthelper.h
+@@ -5,7 +5,7 @@
+ #define NFCT_HELPER_STATUS_DISABLED 0
+ #define NFCT_HELPER_STATUS_ENABLED 1
+
+-enum nfnl_acct_msg_types {
++enum nfnl_cthelper_msg_types {
+ NFNL_MSG_CTHELPER_NEW,
+ NFNL_MSG_CTHELPER_GET,
+ NFNL_MSG_CTHELPER_DEL,
projects / thirdparty / kernel / stable-queue.git / commitdiff
