--- /dev/null
+From foo@baz Sat Oct 24 10:56:27 AM CEST 2020
+From: Vinay Kumar Yadav <vinay.yadav@chelsio.com>
+Date: Mon, 19 Oct 2020 17:20:24 +0530
+Subject: [PATCH stable 5.8 07/25] chelsio/chtls: correct function return and return type
+
+From: Vinay Kumar Yadav <vinay.yadav@chelsio.com>
+
+[ Upstream commit 8580a61aede28d441e1c80588803411ee86aa299 ]
+
+csk_mem_free() should return true if send buffer is available,
+false otherwise.
+
+Fixes: 3b8305f5c844 ("crypto: chtls - wait for memory sendmsg, sendpage")
+Signed-off-by: Vinay Kumar Yadav <vinay.yadav@chelsio.com>
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/crypto/chelsio/chtls/chtls_io.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/crypto/chelsio/chtls/chtls_io.c
++++ b/drivers/crypto/chelsio/chtls/chtls_io.c
+@@ -902,9 +902,9 @@ static int chtls_skb_copy_to_page_nocach
+ return 0;
+ }
+
+-static int csk_mem_free(struct chtls_dev *cdev, struct sock *sk)
++static bool csk_mem_free(struct chtls_dev *cdev, struct sock *sk)
+ {
+- return (cdev->max_host_sndbuf - sk->sk_wmem_queued);
++ return (cdev->max_host_sndbuf - sk->sk_wmem_queued > 0);
+ }
+
+ static int csk_wait_memory(struct chtls_dev *cdev,
--- /dev/null
+From foo@baz Sat Oct 24 10:56:27 AM CEST 2020
+From: Vinay Kumar Yadav <vinay.yadav@chelsio.com>
+Date: Mon, 19 Oct 2020 17:20:21 +0530
+Subject: [PATCH stable 5.8 04/25] chelsio/chtls: correct netdevice for vlan interface
+
+From: Vinay Kumar Yadav <vinay.yadav@chelsio.com>
+
+[ Upstream commit 81519d1f7df7ed1bd5b1397540c8884438f57ae2 ]
+
+Check if netdevice is a vlan interface and find real vlan netdevice.
+
+Fixes: cc35c88ae4db ("crypto : chtls - CPL handler definition")
+Signed-off-by: Venkatesh Ellapu <venkatesh.e@chelsio.com>
+Signed-off-by: Vinay Kumar Yadav <vinay.yadav@chelsio.com>
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/crypto/chelsio/chtls/chtls_cm.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/crypto/chelsio/chtls/chtls_cm.c
++++ b/drivers/crypto/chelsio/chtls/chtls_cm.c
+@@ -1156,6 +1156,9 @@ static struct sock *chtls_recv_sock(stru
+ ndev = n->dev;
+ if (!ndev)
+ goto free_dst;
++ if (is_vlan_dev(ndev))
++ ndev = vlan_dev_real_dev(ndev);
++
+ port_id = cxgb4_port_idx(ndev);
+
+ csk = chtls_sock_create(cdev);
--- /dev/null
+From foo@baz Sat Oct 24 10:56:27 AM CEST 2020
+From: Vinay Kumar Yadav <vinay.yadav@chelsio.com>
+Date: Mon, 19 Oct 2020 17:20:23 +0530
+Subject: [PATCH stable 5.8 06/25] chelsio/chtls: Fix panic when listen on multiadapter
+
+From: Vinay Kumar Yadav <vinay.yadav@chelsio.com>
+
+[ Upstream commit 9819f22c410b4bf6589d3126e8bc3952db507cbf ]
+
+Add the logic to compare net_device returned by ip_dev_find()
+with the net_device list in cdev->ports[] array and return
+net_device if matched else NULL.
+
+Fixes: 6abde0b24122 ("crypto/chtls: IPv6 support for inline TLS")
+Signed-off-by: Venkatesh Ellapu <venkatesh.e@chelsio.com>
+Signed-off-by: Vinay Kumar Yadav <vinay.yadav@chelsio.com>
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/crypto/chelsio/chtls/chtls_cm.c | 10 ++++++++--
+ 1 file changed, 8 insertions(+), 2 deletions(-)
+
+--- a/drivers/crypto/chelsio/chtls/chtls_cm.c
++++ b/drivers/crypto/chelsio/chtls/chtls_cm.c
+@@ -92,11 +92,13 @@ static void chtls_sock_release(struct kr
+ static struct net_device *chtls_find_netdev(struct chtls_dev *cdev,
+ struct sock *sk)
+ {
++ struct adapter *adap = pci_get_drvdata(cdev->pdev);
+ struct net_device *ndev = cdev->ports[0];
+ #if IS_ENABLED(CONFIG_IPV6)
+ struct net_device *temp;
+ int addr_type;
+ #endif
++ int i;
+
+ switch (sk->sk_family) {
+ case PF_INET:
+@@ -127,8 +129,12 @@ static struct net_device *chtls_find_net
+ return NULL;
+
+ if (is_vlan_dev(ndev))
+- return vlan_dev_real_dev(ndev);
+- return ndev;
++ ndev = vlan_dev_real_dev(ndev);
++
++ for_each_port(adap, i)
++ if (cdev->ports[i] == ndev)
++ return ndev;
++ return NULL;
+ }
+
+ static void assign_rxopt(struct sock *sk, unsigned int opt)
--- /dev/null
+From foo@baz Sat Oct 24 10:56:27 AM CEST 2020
+From: Vinay Kumar Yadav <vinay.yadav@chelsio.com>
+Date: Mon, 19 Oct 2020 17:20:22 +0530
+Subject: [PATCH stable 5.8 05/25] chelsio/chtls: fix panic when server is on ipv6
+
+From: Vinay Kumar Yadav <vinay.yadav@chelsio.com>
+
+[ Upstream commit 86cdf9ca4409d997a391103e480b3f77b7ccc19b ]
+
+Netdev is filled in egress_dev when connection is established,
+If connection is closed before establishment, then egress_dev
+is NULL, Fix it using ip_dev_find() rather then extracting from
+egress_dev.
+
+Fixes: 6abde0b24122 ("crypto/chtls: IPv6 support for inline TLS")
+Signed-off-by: Venkatesh Ellapu <venkatesh.e@chelsio.com>
+Signed-off-by: Vinay Kumar Yadav <vinay.yadav@chelsio.com>
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/crypto/chelsio/chtls/chtls_cm.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+--- a/drivers/crypto/chelsio/chtls/chtls_cm.c
++++ b/drivers/crypto/chelsio/chtls/chtls_cm.c
+@@ -736,14 +736,13 @@ void chtls_listen_stop(struct chtls_dev
+
+ #if IS_ENABLED(CONFIG_IPV6)
+ if (sk->sk_family == PF_INET6) {
+- struct chtls_sock *csk;
++ struct net_device *ndev = chtls_find_netdev(cdev, sk);
+ int addr_type = 0;
+
+- csk = rcu_dereference_sk_user_data(sk);
+ addr_type = ipv6_addr_type((const struct in6_addr *)
+ &sk->sk_v6_rcv_saddr);
+ if (addr_type != IPV6_ADDR_ANY)
+- cxgb4_clip_release(csk->egress_dev, (const u32 *)
++ cxgb4_clip_release(ndev, (const u32 *)
+ &sk->sk_v6_rcv_saddr, 1);
+ }
+ #endif
--- /dev/null
+From foo@baz Sat Oct 24 10:56:27 AM CEST 2020
+From: Vinay Kumar Yadav <vinay.yadav@chelsio.com>
+Date: Mon, 19 Oct 2020 17:20:20 +0530
+Subject: [PATCH stable 5.8 03/25] chelsio/chtls: fix socket lock
+
+From: Vinay Kumar Yadav <vinay.yadav@chelsio.com>
+
+[ Upstream commit 0fb5f0160a36d7acaa8e84ce873af99f94b60484 ]
+
+In chtls_sendpage() socket lock is released but not acquired,
+fix it by taking lock.
+
+Fixes: 36bedb3f2e5b ("crypto: chtls - Inline TLS record Tx")
+Signed-off-by: Vinay Kumar Yadav <vinay.yadav@chelsio.com>
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/crypto/chelsio/chtls/chtls_io.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/crypto/chelsio/chtls/chtls_io.c
++++ b/drivers/crypto/chelsio/chtls/chtls_io.c
+@@ -1240,6 +1240,7 @@ int chtls_sendpage(struct sock *sk, stru
+ copied = 0;
+ csk = rcu_dereference_sk_user_data(sk);
+ cdev = csk->cdev;
++ lock_sock(sk);
+ timeo = sock_sndtimeo(sk, flags & MSG_DONTWAIT);
+
+ err = sk_stream_wait_connect(sk, &timeo);
--- /dev/null
+From foo@baz Sat Oct 24 10:56:27 AM CEST 2020
+From: Vinay Kumar Yadav <vinay.yadav@chelsio.com>
+Date: Mon, 19 Oct 2020 17:20:25 +0530
+Subject: [PATCH stable 5.8 08/25] chelsio/chtls: fix writing freed memory
+
+From: Vinay Kumar Yadav <vinay.yadav@chelsio.com>
+
+[ Upstream commit da1a039bcf293e4699d413c9f65d975da2d7c0bd ]
+
+When chtls_sock *csk is freed, same memory can be allocated
+to different csk in chtls_sock_create().
+csk->cdev = NULL; statement might ends up modifying wrong
+csk, eventually causing kernel panic.
+removing (csk->cdev = NULL) statement as it is not required.
+
+Fixes: 3a0a97838923 ("crypto/chtls: Fix chtls crash in connection cleanup")
+Signed-off-by: Vinay Kumar Yadav <vinay.yadav@chelsio.com>
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/crypto/chelsio/chtls/chtls_cm.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/drivers/crypto/chelsio/chtls/chtls_cm.c
++++ b/drivers/crypto/chelsio/chtls/chtls_cm.c
+@@ -483,7 +483,6 @@ void chtls_destroy_sock(struct sock *sk)
+ chtls_purge_write_queue(sk);
+ free_tls_keyid(sk);
+ kref_put(&csk->kref, chtls_sock_release);
+- csk->cdev = NULL;
+ if (sk->sk_family == AF_INET)
+ sk->sk_prot = &tcp_prot;
+ #if IS_ENABLED(CONFIG_IPV6)
--- /dev/null
+From foo@baz Sat Oct 24 10:56:27 AM CEST 2020
+From: Lijun Pan <ljp@linux.ibm.com>
+Date: Tue, 20 Oct 2020 17:39:19 -0500
+Subject: [PATCH stable 5.8 09/25] ibmvnic: save changed mac address to adapter->mac_addr
+
+From: Lijun Pan <ljp@linux.ibm.com>
+
+[ Upstream commit d9b0e599b2b892422f1cbc5d2658049b895b2b58 ]
+
+After mac address change request completes successfully, the new mac
+address need to be saved to adapter->mac_addr as well as
+netdev->dev_addr. Otherwise, adapter->mac_addr still holds old
+data.
+
+Fixes: 62740e97881c ("net/ibmvnic: Update MAC address settings after adapter reset")
+Signed-off-by: Lijun Pan <ljp@linux.ibm.com>
+Link: https://lore.kernel.org/r/20201020223919.46106-1-ljp@linux.ibm.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/ibm/ibmvnic.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/net/ethernet/ibm/ibmvnic.c
++++ b/drivers/net/ethernet/ibm/ibmvnic.c
+@@ -4194,8 +4194,13 @@ static int handle_change_mac_rsp(union i
+ dev_err(dev, "Error %ld in CHANGE_MAC_ADDR_RSP\n", rc);
+ goto out;
+ }
++ /* crq->change_mac_addr.mac_addr is the requested one
++ * crq->change_mac_addr_rsp.mac_addr is the returned valid one.
++ */
+ ether_addr_copy(netdev->dev_addr,
+ &crq->change_mac_addr_rsp.mac_addr[0]);
++ ether_addr_copy(adapter->mac_addr,
++ &crq->change_mac_addr_rsp.mac_addr[0]);
+ out:
+ complete(&adapter->fw_done);
+ return rc;
--- /dev/null
+From foo@baz Sat Oct 24 10:56:27 AM CEST 2020
+From: Eric Dumazet <edumazet@google.com>
+Date: Thu, 15 Oct 2020 11:42:00 -0700
+Subject: [PATCH stable 5.8 10/25] icmp: randomize the global rate limiter
+
+From: Eric Dumazet <edumazet@google.com>
+
+[ Upstream commit b38e7819cae946e2edf869e604af1e65a5d241c5 ]
+
+Keyu Man reported that the ICMP rate limiter could be used
+by attackers to get useful signal. Details will be provided
+in an upcoming academic publication.
+
+Our solution is to add some noise, so that the attackers
+no longer can get help from the predictable token bucket limiter.
+
+Fixes: 4cdf507d5452 ("icmp: add a global rate limitation")
+Signed-off-by: Eric Dumazet <edumazet@google.com>
+Reported-by: Keyu Man <kman001@ucr.edu>
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ Documentation/networking/ip-sysctl.rst | 4 +++-
+ net/ipv4/icmp.c | 7 +++++--
+ 2 files changed, 8 insertions(+), 3 deletions(-)
+
+--- a/Documentation/networking/ip-sysctl.rst
++++ b/Documentation/networking/ip-sysctl.rst
+@@ -1142,13 +1142,15 @@ icmp_ratelimit - INTEGER
+ icmp_msgs_per_sec - INTEGER
+ Limit maximal number of ICMP packets sent per second from this host.
+ Only messages whose type matches icmp_ratemask (see below) are
+- controlled by this limit.
++ controlled by this limit. For security reasons, the precise count
++ of messages per second is randomized.
+
+ Default: 1000
+
+ icmp_msgs_burst - INTEGER
+ icmp_msgs_per_sec controls number of ICMP packets sent per second,
+ while icmp_msgs_burst controls the burst size of these packets.
++ For security reasons, the precise burst size is randomized.
+
+ Default: 50
+
+--- a/net/ipv4/icmp.c
++++ b/net/ipv4/icmp.c
+@@ -239,7 +239,7 @@ static struct {
+ /**
+ * icmp_global_allow - Are we allowed to send one more ICMP message ?
+ *
+- * Uses a token bucket to limit our ICMP messages to sysctl_icmp_msgs_per_sec.
++ * Uses a token bucket to limit our ICMP messages to ~sysctl_icmp_msgs_per_sec.
+ * Returns false if we reached the limit and can not send another packet.
+ * Note: called with BH disabled
+ */
+@@ -267,7 +267,10 @@ bool icmp_global_allow(void)
+ }
+ credit = min_t(u32, icmp_global.credit + incr, sysctl_icmp_msgs_burst);
+ if (credit) {
+- credit--;
++ /* We want to use a credit of one in average, but need to randomize
++ * it for security reasons.
++ */
++ credit = max_t(int, credit - prandom_u32_max(3), 0);
+ rc = true;
+ }
+ WRITE_ONCE(icmp_global.credit, credit);
--- /dev/null
+From foo@baz Sat Oct 24 10:56:27 AM CEST 2020
+From: Geliang Tang <geliangtang@gmail.com>
+Date: Mon, 19 Oct 2020 18:23:15 +0800
+Subject: [PATCH stable 5.8 11/25] mptcp: initialize mptcp_options_received's ahmac
+
+From: Geliang Tang <geliangtang@gmail.com>
+
+[ Upstream commit fe2d9b1a0e7805384770ec0ddd34c9f1e9fe6fa8 ]
+
+Initialize mptcp_options_received's ahmac to zero, otherwise it
+will be a random number when receiving ADD_ADDR suboption with echo-flag=1.
+
+Fixes: 3df523ab582c5 ("mptcp: Add ADD_ADDR handling")
+Signed-off-by: Geliang Tang <geliangtang@gmail.com>
+Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net>
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/mptcp/options.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/net/mptcp/options.c
++++ b/net/mptcp/options.c
+@@ -296,6 +296,7 @@ void mptcp_get_options(const struct sk_b
+ mp_opt->mp_capable = 0;
+ mp_opt->mp_join = 0;
+ mp_opt->add_addr = 0;
++ mp_opt->ahmac = 0;
+ mp_opt->rm_addr = 0;
+ mp_opt->dss = 0;
+
--- /dev/null
+From foo@baz Sat Oct 24 10:56:27 AM CEST 2020
+From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
+Date: Tue, 20 Oct 2020 09:35:15 +0200
+Subject: [PATCH stable 5.8 24/25] net: ethernet: mtk-star-emac: select REGMAP_MMIO
+
+From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
+
+[ Upstream commit 5403caf21648d739bf2b1266c33e34384c313379 ]
+
+The driver depends on mmio regmap API but doesn't select the appropriate
+Kconfig option. This fixes it.
+
+Fixes: 8c7bd5a454ff ("net: ethernet: mtk-star-emac: new driver")
+Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
+Link: https://lore.kernel.org/r/20201020073515.22769-1-brgl@bgdev.pl
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/mediatek/Kconfig | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/net/ethernet/mediatek/Kconfig
++++ b/drivers/net/ethernet/mediatek/Kconfig
+@@ -17,6 +17,7 @@ config NET_MEDIATEK_SOC
+ config NET_MEDIATEK_STAR_EMAC
+ tristate "MediaTek STAR Ethernet MAC support"
+ select PHYLIB
++ select REGMAP_MMIO
+ help
+ This driver supports the ethernet MAC IP first used on
+ MediaTek MT85** SoCs.
--- /dev/null
+From foo@baz Sat Oct 24 10:56:27 AM CEST 2020
+From: Dylan Hung <dylan_hung@aspeedtech.com>
+Date: Wed, 14 Oct 2020 14:06:32 +0800
+Subject: [PATCH stable 5.8 12/25] net: ftgmac100: Fix Aspeed ast2600 TX hang issue
+
+From: Dylan Hung <dylan_hung@aspeedtech.com>
+
+[ Upstream commit 137d23cea1c044b2d4853ac71bc68126b25fdbb2 ]
+
+The new HW arbitration feature on Aspeed ast2600 will cause MAC TX to
+hang when handling scatter-gather DMA. Disable the problematic feature
+by setting MAC register 0x58 bit28 and bit27.
+
+Fixes: 39bfab8844a0 ("net: ftgmac100: Add support for DT phy-handle property")
+Signed-off-by: Dylan Hung <dylan_hung@aspeedtech.com>
+Reviewed-by: Joel Stanley <joel@jms.id.au>
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/faraday/ftgmac100.c | 5 +++++
+ drivers/net/ethernet/faraday/ftgmac100.h | 8 ++++++++
+ 2 files changed, 13 insertions(+)
+
+--- a/drivers/net/ethernet/faraday/ftgmac100.c
++++ b/drivers/net/ethernet/faraday/ftgmac100.c
+@@ -1817,6 +1817,11 @@ static int ftgmac100_probe(struct platfo
+ priv->rxdes0_edorr_mask = BIT(30);
+ priv->txdes0_edotr_mask = BIT(30);
+ priv->is_aspeed = true;
++ /* Disable ast2600 problematic HW arbitration */
++ if (of_device_is_compatible(np, "aspeed,ast2600-mac")) {
++ iowrite32(FTGMAC100_TM_DEFAULT,
++ priv->base + FTGMAC100_OFFSET_TM);
++ }
+ } else {
+ priv->rxdes0_edorr_mask = BIT(15);
+ priv->txdes0_edotr_mask = BIT(15);
+--- a/drivers/net/ethernet/faraday/ftgmac100.h
++++ b/drivers/net/ethernet/faraday/ftgmac100.h
+@@ -170,6 +170,14 @@
+ #define FTGMAC100_MACCR_SW_RST (1 << 31)
+
+ /*
++ * test mode control register
++ */
++#define FTGMAC100_TM_RQ_TX_VALID_DIS (1 << 28)
++#define FTGMAC100_TM_RQ_RR_IDLE_PREV (1 << 27)
++#define FTGMAC100_TM_DEFAULT \
++ (FTGMAC100_TM_RQ_TX_VALID_DIS | FTGMAC100_TM_RQ_RR_IDLE_PREV)
++
++/*
+ * PHY control register
+ */
+ #define FTGMAC100_PHYCR_MDC_CYCTHR_MASK 0x3f
--- /dev/null
+From foo@baz Sat Oct 24 10:56:27 AM CEST 2020
+From: Xie He <xie.he.0141@gmail.com>
+Date: Mon, 19 Oct 2020 18:31:52 -0700
+Subject: [PATCH stable 5.8 13/25] net: hdlc: In hdlc_rcv, check to make sure dev is an HDLC device
+
+From: Xie He <xie.he.0141@gmail.com>
+
+[ Upstream commit 01c4ceae0a38a0bdbfea6896f41efcd985a9c064 ]
+
+The hdlc_rcv function is used as hdlc_packet_type.func to process any
+skb received in the kernel with skb->protocol == htons(ETH_P_HDLC).
+The purpose of this function is to provide second-stage processing for
+skbs not assigned a "real" L3 skb->protocol value in the first stage.
+
+This function assumes the device from which the skb is received is an
+HDLC device (a device created by this module). It assumes that
+netdev_priv(dev) returns a pointer to "struct hdlc_device".
+
+However, it is possible that some driver in the kernel (not necessarily
+in our control) submits a received skb with skb->protocol ==
+htons(ETH_P_HDLC), from a non-HDLC device. In this case, the skb would
+still be received by hdlc_rcv. This will cause problems.
+
+hdlc_rcv should be able to recognize and drop invalid skbs. It should
+first make sure "dev" is actually an HDLC device, before starting its
+processing. This patch adds this check to hdlc_rcv.
+
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Cc: Krzysztof Halasa <khc@pm.waw.pl>
+Signed-off-by: Xie He <xie.he.0141@gmail.com>
+Link: https://lore.kernel.org/r/20201020013152.89259-1-xie.he.0141@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/wan/hdlc.c | 10 +++++++++-
+ 1 file changed, 9 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/wan/hdlc.c
++++ b/drivers/net/wan/hdlc.c
+@@ -46,7 +46,15 @@ static struct hdlc_proto *first_proto;
+ static int hdlc_rcv(struct sk_buff *skb, struct net_device *dev,
+ struct packet_type *p, struct net_device *orig_dev)
+ {
+- struct hdlc_device *hdlc = dev_to_hdlc(dev);
++ struct hdlc_device *hdlc;
++
++ /* First make sure "dev" is an HDLC device */
++ if (!(dev->priv_flags & IFF_WAN_HDLC)) {
++ kfree_skb(skb);
++ return NET_RX_SUCCESS;
++ }
++
++ hdlc = dev_to_hdlc(dev);
+
+ if (!net_eq(dev_net(dev), &init_net)) {
+ kfree_skb(skb);
--- /dev/null
+From foo@baz Sat Oct 24 10:56:27 AM CEST 2020
+From: Xie He <xie.he.0141@gmail.com>
+Date: Mon, 19 Oct 2020 23:34:20 -0700
+Subject: [PATCH stable 5.8 14/25] net: hdlc_raw_eth: Clear the IFF_TX_SKB_SHARING flag after calling ether_setup
+
+From: Xie He <xie.he.0141@gmail.com>
+
+[ Upstream commit 5fce1e43e2d5bf2f7e3224d7b99b1c65ab2c26e2 ]
+
+This driver calls ether_setup to set up the network device.
+The ether_setup function would add the IFF_TX_SKB_SHARING flag to the
+device. This flag indicates that it is safe to transmit shared skbs to
+the device.
+
+However, this is not true. This driver may pad the frame (in eth_tx)
+before transmission, so the skb may be modified.
+
+Fixes: 550fd08c2ceb ("net: Audit drivers to identify those needing IFF_TX_SKB_SHARING cleared")
+Cc: Neil Horman <nhorman@tuxdriver.com>
+Cc: Krzysztof Halasa <khc@pm.waw.pl>
+Signed-off-by: Xie He <xie.he.0141@gmail.com>
+Link: https://lore.kernel.org/r/20201020063420.187497-1-xie.he.0141@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/wan/hdlc_raw_eth.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/net/wan/hdlc_raw_eth.c
++++ b/drivers/net/wan/hdlc_raw_eth.c
+@@ -99,6 +99,7 @@ static int raw_eth_ioctl(struct net_devi
+ old_qlen = dev->tx_queue_len;
+ ether_setup(dev);
+ dev->tx_queue_len = old_qlen;
++ dev->priv_flags &= ~IFF_TX_SKB_SHARING;
+ eth_hw_addr_random(dev);
+ call_netdevice_notifiers(NETDEV_POST_TYPE_CHANGE, dev);
+ netif_dormant_off(dev);
--- /dev/null
+From foo@baz Sat Oct 24 10:56:27 AM CEST 2020
+From: Ke Li <keli@akamai.com>
+Date: Thu, 22 Oct 2020 02:41:46 -0400
+Subject: [PATCH stable 5.8 15/25] net: Properly typecast int values to set sk_max_pacing_rate
+
+From: Ke Li <keli@akamai.com>
+
+[ Upstream commit 700465fd338fe5df08a1b2e27fa16981f562547f ]
+
+In setsockopt(SO_MAX_PACING_RATE) on 64bit systems, sk_max_pacing_rate,
+after extended from 'u32' to 'unsigned long', takes unintentionally
+hiked value whenever assigned from an 'int' value with MSB=1, due to
+binary sign extension in promoting s32 to u64, e.g. 0x80000000 becomes
+0xFFFFFFFF80000000.
+
+Thus inflated sk_max_pacing_rate causes subsequent getsockopt to return
+~0U unexpectedly. It may also result in increased pacing rate.
+
+Fix by explicitly casting the 'int' value to 'unsigned int' before
+assigning it to sk_max_pacing_rate, for zero extension to happen.
+
+Fixes: 76a9ebe811fb ("net: extend sk_pacing_rate to unsigned long")
+Signed-off-by: Ji Li <jli@akamai.com>
+Signed-off-by: Ke Li <keli@akamai.com>
+Reviewed-by: Eric Dumazet <edumazet@google.com>
+Link: https://lore.kernel.org/r/20201022064146.79873-1-keli@akamai.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/core/filter.c | 3 ++-
+ net/core/sock.c | 2 +-
+ 2 files changed, 3 insertions(+), 2 deletions(-)
+
+--- a/net/core/filter.c
++++ b/net/core/filter.c
+@@ -4323,7 +4323,8 @@ static int _bpf_setsockopt(struct sock *
+ cmpxchg(&sk->sk_pacing_status,
+ SK_PACING_NONE,
+ SK_PACING_NEEDED);
+- sk->sk_max_pacing_rate = (val == ~0U) ? ~0UL : val;
++ sk->sk_max_pacing_rate = (val == ~0U) ?
++ ~0UL : (unsigned int)val;
+ sk->sk_pacing_rate = min(sk->sk_pacing_rate,
+ sk->sk_max_pacing_rate);
+ break;
+--- a/net/core/sock.c
++++ b/net/core/sock.c
+@@ -1184,7 +1184,7 @@ set_sndbuf:
+
+ case SO_MAX_PACING_RATE:
+ {
+- unsigned long ulval = (val == ~0U) ? ~0UL : val;
++ unsigned long ulval = (val == ~0U) ? ~0UL : (unsigned int)val;
+
+ if (sizeof(ulval) != sizeof(val) &&
+ optlen >= sizeof(ulval) &&
--- /dev/null
+From foo@baz Sat Oct 24 10:56:27 AM CEST 2020
+From: Roi Dayan <roid@nvidia.com>
+Date: Mon, 19 Oct 2020 12:02:44 +0300
+Subject: [PATCH stable 5.8 16/25] net/sched: act_ct: Fix adding udp port mangle operation
+
+From: Roi Dayan <roid@nvidia.com>
+
+[ Upstream commit 47b5d2a107396ab05e83a4dfbd30b563ecbc83af ]
+
+Need to use the udp header type and not tcp.
+
+Fixes: 9c26ba9b1f45 ("net/sched: act_ct: Instantiate flow table entry actions")
+Signed-off-by: Roi Dayan <roid@nvidia.com>
+Reviewed-by: Paul Blakey <paulb@nvidia.com>
+Link: https://lore.kernel.org/r/20201019090244.3015186-1-roid@nvidia.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/sched/act_ct.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/net/sched/act_ct.c
++++ b/net/sched/act_ct.c
+@@ -156,11 +156,11 @@ tcf_ct_flow_table_add_action_nat_udp(con
+ __be16 target_dst = target.dst.u.udp.port;
+
+ if (target_src != tuple->src.u.udp.port)
+- tcf_ct_add_mangle_action(action, FLOW_ACT_MANGLE_HDR_TYPE_TCP,
++ tcf_ct_add_mangle_action(action, FLOW_ACT_MANGLE_HDR_TYPE_UDP,
+ offsetof(struct udphdr, source),
+ 0xFFFF, be16_to_cpu(target_src));
+ if (target_dst != tuple->dst.u.udp.port)
+- tcf_ct_add_mangle_action(action, FLOW_ACT_MANGLE_HDR_TYPE_TCP,
++ tcf_ct_add_mangle_action(action, FLOW_ACT_MANGLE_HDR_TYPE_UDP,
+ offsetof(struct udphdr, dest),
+ 0xFFFF, be16_to_cpu(target_dst));
+ }
--- /dev/null
+From foo@baz Sat Oct 24 10:56:27 AM CEST 2020
+From: Guillaume Nault <gnault@redhat.com>
+Date: Tue, 20 Oct 2020 17:34:31 +0200
+Subject: [PATCH stable 5.8 25/25] net/sched: act_gate: Unlock ->tcfa_lock in tc_setup_flow_action()
+
+From: Guillaume Nault <gnault@redhat.com>
+
+[ Upstream commit b130762161374b1ef31549bef8ebd4abeb998d94 ]
+
+We need to jump to the "err_out_locked" label when
+tcf_gate_get_entries() fails. Otherwise, tc_setup_flow_action() exits
+with ->tcfa_lock still held.
+
+Fixes: d29bdd69ecdd ("net: schedule: add action gate offloading")
+Signed-off-by: Guillaume Nault <gnault@redhat.com>
+Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
+Link: https://lore.kernel.org/r/12f60e385584c52c22863701c0185e40ab08a7a7.1603207948.git.gnault@redhat.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/sched/cls_api.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/sched/cls_api.c
++++ b/net/sched/cls_api.c
+@@ -3707,7 +3707,7 @@ int tc_setup_flow_action(struct flow_act
+ entry->gate.num_entries = tcf_gate_num_entries(act);
+ err = tcf_gate_get_entries(entry, act);
+ if (err)
+- goto err_out;
++ goto err_out_locked;
+ } else {
+ err = -EOPNOTSUPP;
+ goto err_out_locked;
--- /dev/null
+From foo@baz Sat Oct 24 10:56:27 AM CEST 2020
+From: Davide Caratti <dcaratti@redhat.com>
+Date: Wed, 21 Oct 2020 00:02:40 +0200
+Subject: [PATCH stable 5.8 17/25] net/sched: act_tunnel_key: fix OOB write in case of IPv6 ERSPAN tunnels
+
+From: Davide Caratti <dcaratti@redhat.com>
+
+[ Upstream commit a7a12b5a0f950bc6b9f7153390634ea798738db9 ]
+
+the following command
+
+ # tc action add action tunnel_key \
+ > set src_ip 2001:db8::1 dst_ip 2001:db8::2 id 10 erspan_opts 1:6789:0:0
+
+generates the following splat:
+
+ BUG: KASAN: slab-out-of-bounds in tunnel_key_copy_opts+0xcc9/0x1010 [act_tunnel_key]
+ Write of size 4 at addr ffff88813f5f1cc8 by task tc/873
+
+ CPU: 2 PID: 873 Comm: tc Not tainted 5.9.0+ #282
+ Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014
+ Call Trace:
+ dump_stack+0x99/0xcb
+ print_address_description.constprop.7+0x1e/0x230
+ kasan_report.cold.13+0x37/0x7c
+ tunnel_key_copy_opts+0xcc9/0x1010 [act_tunnel_key]
+ tunnel_key_init+0x160c/0x1f40 [act_tunnel_key]
+ tcf_action_init_1+0x5b5/0x850
+ tcf_action_init+0x15d/0x370
+ tcf_action_add+0xd9/0x2f0
+ tc_ctl_action+0x29b/0x3a0
+ rtnetlink_rcv_msg+0x341/0x8d0
+ netlink_rcv_skb+0x120/0x380
+ netlink_unicast+0x439/0x630
+ netlink_sendmsg+0x719/0xbf0
+ sock_sendmsg+0xe2/0x110
+ ____sys_sendmsg+0x5ba/0x890
+ ___sys_sendmsg+0xe9/0x160
+ __sys_sendmsg+0xd3/0x170
+ do_syscall_64+0x33/0x40
+ entry_SYSCALL_64_after_hwframe+0x44/0xa9
+ RIP: 0033:0x7f872a96b338
+ Code: 89 02 48 c7 c0 ff ff ff ff eb b5 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 25 43 2c 00 8b 00 85 c0 75 17 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 41 89 d4 55
+ RSP: 002b:00007ffffe367518 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
+ RAX: ffffffffffffffda RBX: 000000005f8f5aed RCX: 00007f872a96b338
+ RDX: 0000000000000000 RSI: 00007ffffe367580 RDI: 0000000000000003
+ RBP: 0000000000000000 R08: 0000000000000001 R09: 000000000000001c
+ R10: 000000000000000b R11: 0000000000000246 R12: 0000000000000001
+ R13: 0000000000686760 R14: 0000000000000601 R15: 0000000000000000
+
+ Allocated by task 873:
+ kasan_save_stack+0x19/0x40
+ __kasan_kmalloc.constprop.7+0xc1/0xd0
+ __kmalloc+0x151/0x310
+ metadata_dst_alloc+0x20/0x40
+ tunnel_key_init+0xfff/0x1f40 [act_tunnel_key]
+ tcf_action_init_1+0x5b5/0x850
+ tcf_action_init+0x15d/0x370
+ tcf_action_add+0xd9/0x2f0
+ tc_ctl_action+0x29b/0x3a0
+ rtnetlink_rcv_msg+0x341/0x8d0
+ netlink_rcv_skb+0x120/0x380
+ netlink_unicast+0x439/0x630
+ netlink_sendmsg+0x719/0xbf0
+ sock_sendmsg+0xe2/0x110
+ ____sys_sendmsg+0x5ba/0x890
+ ___sys_sendmsg+0xe9/0x160
+ __sys_sendmsg+0xd3/0x170
+ do_syscall_64+0x33/0x40
+ entry_SYSCALL_64_after_hwframe+0x44/0xa9
+
+ The buggy address belongs to the object at ffff88813f5f1c00
+ which belongs to the cache kmalloc-256 of size 256
+ The buggy address is located 200 bytes inside of
+ 256-byte region [ffff88813f5f1c00, ffff88813f5f1d00)
+ The buggy address belongs to the page:
+ page:0000000011b48a19 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x13f5f0
+ head:0000000011b48a19 order:1 compound_mapcount:0
+ flags: 0x17ffffc0010200(slab|head)
+ raw: 0017ffffc0010200 0000000000000000 0000000d00000001 ffff888107c43400
+ raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000
+ page dumped because: kasan: bad access detected
+
+ Memory state around the buggy address:
+ ffff88813f5f1b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
+ ffff88813f5f1c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+ >ffff88813f5f1c80: 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc
+ ^
+ ffff88813f5f1d00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
+ ffff88813f5f1d80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
+
+using IPv6 tunnels, act_tunnel_key allocates a fixed amount of memory for
+the tunnel metadata, but then it expects additional bytes to store tunnel
+specific metadata with tunnel_key_copy_opts().
+
+Fix the arguments of __ipv6_tun_set_dst(), so that 'md_size' contains the
+size previously computed by tunnel_key_get_opts_len(), like it's done for
+IPv4 tunnels.
+
+Fixes: 0ed5269f9e41 ("net/sched: add tunnel option support to act_tunnel_key")
+Reported-by: Shuang Li <shuali@redhat.com>
+Signed-off-by: Davide Caratti <dcaratti@redhat.com>
+Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
+Link: https://lore.kernel.org/r/36ebe969f6d13ff59912d6464a4356fe6f103766.1603231100.git.dcaratti@redhat.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/sched/act_tunnel_key.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/sched/act_tunnel_key.c
++++ b/net/sched/act_tunnel_key.c
+@@ -458,7 +458,7 @@ static int tunnel_key_init(struct net *n
+
+ metadata = __ipv6_tun_set_dst(&saddr, &daddr, tos, ttl, dst_port,
+ 0, flags,
+- key_id, 0);
++ key_id, opts_len);
+ } else {
+ NL_SET_ERR_MSG(extack, "Missing either ipv4 or ipv6 src and dst");
+ ret = -EINVAL;
--- /dev/null
+From foo@baz Sat Oct 24 10:56:27 AM CEST 2020
+From: Ido Schimmel <idosch@nvidia.com>
+Date: Fri, 16 Oct 2020 20:29:14 +0300
+Subject: [PATCH stable 5.8 18/25] nexthop: Fix performance regression in nexthop deletion
+
+From: Ido Schimmel <idosch@nvidia.com>
+
+[ Upstream commit df6afe2f7c19349de2ee560dc62ea4d9ad3ff889 ]
+
+While insertion of 16k nexthops all using the same netdev ('dummy10')
+takes less than a second, deletion takes about 130 seconds:
+
+# time -p ip -b nexthop.batch
+real 0.29
+user 0.01
+sys 0.15
+
+# time -p ip link set dev dummy10 down
+real 131.03
+user 0.06
+sys 0.52
+
+This is because of repeated calls to synchronize_rcu() whenever a
+nexthop is removed from a nexthop group:
+
+# /usr/share/bcc/tools/offcputime -p `pgrep -nx ip` -K
+...
+ b'finish_task_switch'
+ b'schedule'
+ b'schedule_timeout'
+ b'wait_for_completion'
+ b'__wait_rcu_gp'
+ b'synchronize_rcu.part.0'
+ b'synchronize_rcu'
+ b'__remove_nexthop'
+ b'remove_nexthop'
+ b'nexthop_flush_dev'
+ b'nh_netdev_event'
+ b'raw_notifier_call_chain'
+ b'call_netdevice_notifiers_info'
+ b'__dev_notify_flags'
+ b'dev_change_flags'
+ b'do_setlink'
+ b'__rtnl_newlink'
+ b'rtnl_newlink'
+ b'rtnetlink_rcv_msg'
+ b'netlink_rcv_skb'
+ b'rtnetlink_rcv'
+ b'netlink_unicast'
+ b'netlink_sendmsg'
+ b'____sys_sendmsg'
+ b'___sys_sendmsg'
+ b'__sys_sendmsg'
+ b'__x64_sys_sendmsg'
+ b'do_syscall_64'
+ b'entry_SYSCALL_64_after_hwframe'
+ - ip (277)
+ 126554955
+
+Since nexthops are always deleted under RTNL, synchronize_net() can be
+used instead. It will call synchronize_rcu_expedited() which only blocks
+for several microseconds as opposed to multiple milliseconds like
+synchronize_rcu().
+
+With this patch deletion of 16k nexthops takes less than a second:
+
+# time -p ip link set dev dummy10 down
+real 0.12
+user 0.00
+sys 0.04
+
+Tested with fib_nexthops.sh which includes torture tests that prompted
+the initial change:
+
+# ./fib_nexthops.sh
+...
+Tests passed: 134
+Tests failed: 0
+
+Fixes: 90f33bffa382 ("nexthops: don't modify published nexthop groups")
+Signed-off-by: Ido Schimmel <idosch@nvidia.com>
+Reviewed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
+Reviewed-by: David Ahern <dsahern@gmail.com>
+Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com>
+Link: https://lore.kernel.org/r/20201016172914.643282-1-idosch@idosch.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ipv4/nexthop.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/ipv4/nexthop.c
++++ b/net/ipv4/nexthop.c
+@@ -842,7 +842,7 @@ static void remove_nexthop_from_groups(s
+ remove_nh_grp_entry(net, nhge, nlinfo);
+
+ /* make sure all see the newly published array before releasing rtnl */
+- synchronize_rcu();
++ synchronize_net();
+ }
+
+ static void remove_nexthop_group(struct nexthop *nh, struct nl_info *nlinfo)
--- /dev/null
+From foo@baz Sat Oct 24 10:56:27 AM CEST 2020
+From: Defang Bo <bodefang@126.com>
+Date: Mon, 19 Oct 2020 19:38:58 +0800
+Subject: [PATCH stable 5.8 19/25] nfc: Ensure presence of NFC_ATTR_FIRMWARE_NAME attribute in nfc_genl_fw_download()
+
+From: Defang Bo <bodefang@126.com>
+
+[ Upstream commit 280e3ebdafb863b3cb50d5842f056267e15bf40c ]
+
+Check that the NFC_ATTR_FIRMWARE_NAME attributes are provided by
+the netlink client prior to accessing them.This prevents potential
+unhandled NULL pointer dereference exceptions which can be triggered
+by malicious user-mode programs, if they omit one or both of these
+attributes.
+
+Similar to commit a0323b979f81 ("nfc: Ensure presence of required attributes in the activate_target handler").
+
+Fixes: 9674da8759df ("NFC: Add firmware upload netlink command")
+Signed-off-by: Defang Bo <bodefang@126.com>
+Link: https://lore.kernel.org/r/1603107538-4744-1-git-send-email-bodefang@126.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/nfc/netlink.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/nfc/netlink.c
++++ b/net/nfc/netlink.c
+@@ -1217,7 +1217,7 @@ static int nfc_genl_fw_download(struct s
+ u32 idx;
+ char firmware_name[NFC_FIRMWARE_NAME_MAXSIZE + 1];
+
+- if (!info->attrs[NFC_ATTR_DEVICE_INDEX])
++ if (!info->attrs[NFC_ATTR_DEVICE_INDEX] || !info->attrs[NFC_ATTR_FIRMWARE_NAME])
+ return -EINVAL;
+
+ idx = nla_get_u32(info->attrs[NFC_ATTR_DEVICE_INDEX]);
--- /dev/null
+From foo@baz Sat Oct 24 10:56:27 AM CEST 2020
+From: Heiner Kallweit <hkallweit1@gmail.com>
+Date: Sun, 18 Oct 2020 18:38:59 +0200
+Subject: [PATCH stable 5.8 20/25] r8169: fix operation under forced interrupt threading
+
+From: Heiner Kallweit <hkallweit1@gmail.com>
+
+[ Upstream commit 424a646e072a887aa87283b53aa6f8b19c2a7bef ]
+
+For several network drivers it was reported that using
+__napi_schedule_irqoff() is unsafe with forced threading. One way to
+fix this is switching back to __napi_schedule, but then we lose the
+benefit of the irqoff version in general. As stated by Eric it doesn't
+make sense to make the minimal hard irq handlers in drivers using NAPI
+a thread. Therefore ensure that the hard irq handler is never
+thread-ified.
+
+Fixes: 9a899a35b0d6 ("r8169: switch to napi_schedule_irqoff")
+Link: https://lkml.org/lkml/2020/10/18/19
+Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
+Link: https://lore.kernel.org/r/4d3ef84a-c812-5072-918a-22a6f6468310@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/realtek/r8169_main.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/drivers/net/ethernet/realtek/r8169_main.c
++++ b/drivers/net/ethernet/realtek/r8169_main.c
+@@ -4675,7 +4675,7 @@ static int rtl8169_close(struct net_devi
+
+ phy_disconnect(tp->phydev);
+
+- pci_free_irq(pdev, 0, tp);
++ free_irq(pci_irq_vector(pdev, 0), tp);
+
+ dma_free_coherent(&pdev->dev, R8169_RX_RING_BYTES, tp->RxDescArray,
+ tp->RxPhyAddr);
+@@ -4726,8 +4726,8 @@ static int rtl_open(struct net_device *d
+
+ rtl_request_firmware(tp);
+
+- retval = pci_request_irq(pdev, 0, rtl8169_interrupt, NULL, tp,
+- dev->name);
++ retval = request_irq(pci_irq_vector(pdev, 0), rtl8169_interrupt,
++ IRQF_NO_THREAD | IRQF_SHARED, dev->name, tp);
+ if (retval < 0)
+ goto err_release_fw_2;
+
+@@ -4759,7 +4759,7 @@ out:
+ return retval;
+
+ err_free_irq:
+- pci_free_irq(pdev, 0, tp);
++ free_irq(pci_irq_vector(pdev, 0), tp);
+ err_release_fw_2:
+ rtl_release_firmware(tp);
+ rtl8169_rx_clear(tp);
--- /dev/null
+From foo@baz Sat Oct 24 10:56:27 AM CEST 2020
+From: Ido Schimmel <idosch@nvidia.com>
+Date: Thu, 15 Oct 2020 11:45:25 +0300
+Subject: [PATCH stable 5.8 21/25] selftests: forwarding: Add missing 'rp_filter' configuration
+
+From: Ido Schimmel <idosch@nvidia.com>
+
+[ Upstream commit 71a0e29e99405d89b695882d52eec60844173697 ]
+
+When 'rp_filter' is configured in strict mode (1) the tests fail because
+packets received from the macvlan netdevs would not be forwarded through
+them on the reverse path.
+
+Fix this by disabling the 'rp_filter', meaning no source validation is
+performed.
+
+Fixes: 1538812e0880 ("selftests: forwarding: Add a test for VXLAN asymmetric routing")
+Fixes: 438a4f5665b2 ("selftests: forwarding: Add a test for VXLAN symmetric routing")
+Signed-off-by: Ido Schimmel <idosch@nvidia.com>
+Reported-by: Hangbin Liu <liuhangbin@gmail.com>
+Tested-by: Hangbin Liu <liuhangbin@gmail.com>
+Link: https://lore.kernel.org/r/20201015084525.135121-1-idosch@idosch.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ tools/testing/selftests/net/forwarding/vxlan_asymmetric.sh | 10 ++++++++++
+ tools/testing/selftests/net/forwarding/vxlan_symmetric.sh | 10 ++++++++++
+ 2 files changed, 20 insertions(+)
+
+--- a/tools/testing/selftests/net/forwarding/vxlan_asymmetric.sh
++++ b/tools/testing/selftests/net/forwarding/vxlan_asymmetric.sh
+@@ -215,10 +215,16 @@ switch_create()
+
+ bridge fdb add 00:00:5e:00:01:01 dev br1 self local vlan 10
+ bridge fdb add 00:00:5e:00:01:01 dev br1 self local vlan 20
++
++ sysctl_set net.ipv4.conf.all.rp_filter 0
++ sysctl_set net.ipv4.conf.vlan10-v.rp_filter 0
++ sysctl_set net.ipv4.conf.vlan20-v.rp_filter 0
+ }
+
+ switch_destroy()
+ {
++ sysctl_restore net.ipv4.conf.all.rp_filter
++
+ bridge fdb del 00:00:5e:00:01:01 dev br1 self local vlan 20
+ bridge fdb del 00:00:5e:00:01:01 dev br1 self local vlan 10
+
+@@ -359,6 +365,10 @@ ns_switch_create()
+
+ bridge fdb add 00:00:5e:00:01:01 dev br1 self local vlan 10
+ bridge fdb add 00:00:5e:00:01:01 dev br1 self local vlan 20
++
++ sysctl_set net.ipv4.conf.all.rp_filter 0
++ sysctl_set net.ipv4.conf.vlan10-v.rp_filter 0
++ sysctl_set net.ipv4.conf.vlan20-v.rp_filter 0
+ }
+ export -f ns_switch_create
+
+--- a/tools/testing/selftests/net/forwarding/vxlan_symmetric.sh
++++ b/tools/testing/selftests/net/forwarding/vxlan_symmetric.sh
+@@ -237,10 +237,16 @@ switch_create()
+
+ bridge fdb add 00:00:5e:00:01:01 dev br1 self local vlan 10
+ bridge fdb add 00:00:5e:00:01:01 dev br1 self local vlan 20
++
++ sysctl_set net.ipv4.conf.all.rp_filter 0
++ sysctl_set net.ipv4.conf.vlan10-v.rp_filter 0
++ sysctl_set net.ipv4.conf.vlan20-v.rp_filter 0
+ }
+
+ switch_destroy()
+ {
++ sysctl_restore net.ipv4.conf.all.rp_filter
++
+ bridge fdb del 00:00:5e:00:01:01 dev br1 self local vlan 20
+ bridge fdb del 00:00:5e:00:01:01 dev br1 self local vlan 10
+
+@@ -402,6 +408,10 @@ ns_switch_create()
+
+ bridge fdb add 00:00:5e:00:01:01 dev br1 self local vlan 10
+ bridge fdb add 00:00:5e:00:01:01 dev br1 self local vlan 20
++
++ sysctl_set net.ipv4.conf.all.rp_filter 0
++ sysctl_set net.ipv4.conf.vlan10-v.rp_filter 0
++ sysctl_set net.ipv4.conf.vlan20-v.rp_filter 0
+ }
+ export -f ns_switch_create
+
--- /dev/null
+From foo@baz Sat Oct 24 10:56:27 AM CEST 2020
+From: Po-Hsu Lin <po-hsu.lin@canonical.com>
+Date: Mon, 19 Oct 2020 11:09:28 +0800
+Subject: [PATCH stable 5.8 22/25] selftests: rtnetlink: load fou module for kci_test_encap_fou() test
+
+From: Po-Hsu Lin <po-hsu.lin@canonical.com>
+
+[ Upstream commit 26ebd6fed9bb3aa480c7c0f147ac0e7b11000f65 ]
+
+The kci_test_encap_fou() test from kci_test_encap() in rtnetlink.sh
+needs the fou module to work. Otherwise it will fail with:
+
+ $ ip netns exec "$testns" ip fou add port 7777 ipproto 47
+ RTNETLINK answers: No such file or directory
+ Error talking to the kernel
+
+Add the CONFIG_NET_FOU into the config file as well. Which needs at
+least to be set as a loadable module.
+
+Fixes: 6227efc1a20b ("selftests: rtnetlink.sh: add vxlan and fou test cases")
+Signed-off-by: Po-Hsu Lin <po-hsu.lin@canonical.com>
+Link: https://lore.kernel.org/r/20201019030928.9859-1-po-hsu.lin@canonical.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ tools/testing/selftests/net/config | 1 +
+ tools/testing/selftests/net/rtnetlink.sh | 5 +++++
+ 2 files changed, 6 insertions(+)
+
+--- a/tools/testing/selftests/net/config
++++ b/tools/testing/selftests/net/config
+@@ -31,3 +31,4 @@ CONFIG_NET_SCH_ETF=m
+ CONFIG_NET_SCH_NETEM=y
+ CONFIG_TEST_BLACKHOLE_DEV=m
+ CONFIG_KALLSYMS=y
++CONFIG_NET_FOU=m
+--- a/tools/testing/selftests/net/rtnetlink.sh
++++ b/tools/testing/selftests/net/rtnetlink.sh
+@@ -521,6 +521,11 @@ kci_test_encap_fou()
+ return $ksft_skip
+ fi
+
++ if ! /sbin/modprobe -q -n fou; then
++ echo "SKIP: module fou is not found"
++ return $ksft_skip
++ fi
++ /sbin/modprobe -q fou
+ ip -netns "$testns" fou add port 7777 ipproto 47 2>/dev/null
+ if [ $? -ne 0 ];then
+ echo "FAIL: can't add fou port 7777, skipping test"
alsa-bebob-potential-info-leak-in-hwdep_read.patch
alsa-hda-fix-jack-detection-with-realtek-codecs-when-in-d3.patch
alsa-hda-hdmi-fix-incorrect-locking-in-hdmi_pcm_close.patch
+tipc-re-configure-queue-limit-for-broadcast-link.patch
+tipc-fix-incorrect-setting-window-for-bcast-link.patch
+chelsio-chtls-fix-socket-lock.patch
+chelsio-chtls-correct-netdevice-for-vlan-interface.patch
+chelsio-chtls-fix-panic-when-server-is-on-ipv6.patch
+chelsio-chtls-fix-panic-when-listen-on-multiadapter.patch
+chelsio-chtls-correct-function-return-and-return-type.patch
+chelsio-chtls-fix-writing-freed-memory.patch
+ibmvnic-save-changed-mac-address-to-adapter-mac_addr.patch
+icmp-randomize-the-global-rate-limiter.patch
+mptcp-initialize-mptcp_options_received-s-ahmac.patch
+net-ftgmac100-fix-aspeed-ast2600-tx-hang-issue.patch
+net-hdlc-in-hdlc_rcv-check-to-make-sure-dev-is-an-hdlc-device.patch
+net-hdlc_raw_eth-clear-the-iff_tx_skb_sharing-flag-after-calling-ether_setup.patch
+net-properly-typecast-int-values-to-set-sk_max_pacing_rate.patch
+net-sched-act_ct-fix-adding-udp-port-mangle-operation.patch
+net-sched-act_tunnel_key-fix-oob-write-in-case-of-ipv6-erspan-tunnels.patch
+nexthop-fix-performance-regression-in-nexthop-deletion.patch
+nfc-ensure-presence-of-nfc_attr_firmware_name-attribute-in-nfc_genl_fw_download.patch
+r8169-fix-operation-under-forced-interrupt-threading.patch
+selftests-forwarding-add-missing-rp_filter-configuration.patch
+selftests-rtnetlink-load-fou-module-for-kci_test_encap_fou-test.patch
+tcp-fix-to-update-snd_wl1-in-bulk-receiver-fast-path.patch
+net-ethernet-mtk-star-emac-select-regmap_mmio.patch
+net-sched-act_gate-unlock-tcfa_lock-in-tc_setup_flow_action.patch
--- /dev/null
+From foo@baz Sat Oct 24 10:56:27 AM CEST 2020
+From: Neal Cardwell <ncardwell@google.com>
+Date: Thu, 22 Oct 2020 10:33:31 -0400
+Subject: [PATCH stable 5.8 23/25] tcp: fix to update snd_wl1 in bulk receiver fast path
+
+From: Neal Cardwell <ncardwell@google.com>
+
+[ Upstream commit 18ded910b589839e38a51623a179837ab4cc3789 ]
+
+In the header prediction fast path for a bulk data receiver, if no
+data is newly acknowledged then we do not call tcp_ack() and do not
+call tcp_ack_update_window(). This means that a bulk receiver that
+receives large amounts of data can have the incoming sequence numbers
+wrap, so that the check in tcp_may_update_window fails:
+ after(ack_seq, tp->snd_wl1)
+
+If the incoming receive windows are zero in this state, and then the
+connection that was a bulk data receiver later wants to send data,
+that connection can find itself persistently rejecting the window
+updates in incoming ACKs. This means the connection can persistently
+fail to discover that the receive window has opened, which in turn
+means that the connection is unable to send anything, and the
+connection's sending process can get permanently "stuck".
+
+The fix is to update snd_wl1 in the header prediction fast path for a
+bulk data receiver, so that it keeps up and does not see wrapping
+problems.
+
+This fix is based on a very nice and thorough analysis and diagnosis
+by Apollon Oikonomopoulos (see link below).
+
+This is a stable candidate but there is no Fixes tag here since the
+bug predates current git history. Just for fun: looks like the bug
+dates back to when header prediction was added in Linux v2.1.8 in Nov
+1996. In that version tcp_rcv_established() was added, and the code
+only updates snd_wl1 in tcp_ack(), and in the new "Bulk data transfer:
+receiver" code path it does not call tcp_ack(). This fix seems to
+apply cleanly at least as far back as v3.2.
+
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Signed-off-by: Neal Cardwell <ncardwell@google.com>
+Reported-by: Apollon Oikonomopoulos <apoikos@dmesg.gr>
+Tested-by: Apollon Oikonomopoulos <apoikos@dmesg.gr>
+Link: https://www.spinics.net/lists/netdev/msg692430.html
+Acked-by: Soheil Hassas Yeganeh <soheil@google.com>
+Acked-by: Yuchung Cheng <ycheng@google.com>
+Signed-off-by: Eric Dumazet <edumazet@google.com>
+Link: https://lore.kernel.org/r/20201022143331.1887495-1-ncardwell.kernel@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ipv4/tcp_input.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/net/ipv4/tcp_input.c
++++ b/net/ipv4/tcp_input.c
+@@ -5716,6 +5716,8 @@ void tcp_rcv_established(struct sock *sk
+ tcp_data_snd_check(sk);
+ if (!inet_csk_ack_scheduled(sk))
+ goto no_ack;
++ } else {
++ tcp_update_wl(tp, TCP_SKB_CB(skb)->seq);
+ }
+
+ __tcp_ack_snd_check(sk, 0);
--- /dev/null
+From foo@baz Sat Oct 24 10:56:27 AM CEST 2020
+From: Hoang Huu Le <hoang.h.le@dektech.com.au>
+Date: Fri, 16 Oct 2020 09:31:19 +0700
+Subject: [PATCH stable 5.8 02/25] tipc: fix incorrect setting window for bcast link
+
+From: Hoang Huu Le <hoang.h.le@dektech.com.au>
+
+[ Upstream commit ec78e31852c9bb7d96b6557468fecb6f6f3b28f3 ]
+
+In commit 16ad3f4022bb
+("tipc: introduce variable window congestion control"), we applied
+the algorithm to select window size from minimum window to the
+configured maximum window for unicast link, and, besides we chose
+to keep the window size for broadcast link unchanged and equal (i.e
+fix window 50)
+
+However, when setting maximum window variable via command, the window
+variable was re-initialized to unexpect value (i.e 32).
+
+We fix this by updating the fix window for broadcast as we stated.
+
+Fixes: 16ad3f4022bb ("tipc: introduce variable window congestion control")
+Acked-by: Jon Maloy <jmaloy@redhat.com>
+Signed-off-by: Hoang Huu Le <hoang.h.le@dektech.com.au>
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/tipc/bcast.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/net/tipc/bcast.c
++++ b/net/tipc/bcast.c
+@@ -109,6 +109,7 @@ static void tipc_bcbase_select_primary(s
+ struct tipc_bc_base *bb = tipc_bc_base(net);
+ int all_dests = tipc_link_bc_peers(bb->link);
+ int max_win = tipc_link_max_win(bb->link);
++ int min_win = tipc_link_min_win(bb->link);
+ int i, mtu, prim;
+
+ bb->primary_bearer = INVALID_BEARER_ID;
+@@ -124,7 +125,8 @@ static void tipc_bcbase_select_primary(s
+ mtu = tipc_bearer_mtu(net, i);
+ if (mtu < tipc_link_mtu(bb->link)) {
+ tipc_link_set_mtu(bb->link, mtu);
+- tipc_link_set_queue_limits(bb->link, max_win,
++ tipc_link_set_queue_limits(bb->link,
++ min_win,
+ max_win);
+ }
+ bb->bcast_support &= tipc_bearer_bcast_support(net, i);
+@@ -589,7 +591,7 @@ static int tipc_bc_link_set_queue_limits
+ if (max_win > TIPC_MAX_LINK_WIN)
+ return -EINVAL;
+ tipc_bcast_lock(net);
+- tipc_link_set_queue_limits(l, BCLINK_WIN_MIN, max_win);
++ tipc_link_set_queue_limits(l, tipc_link_min_win(l), max_win);
+ tipc_bcast_unlock(net);
+ return 0;
+ }
--- /dev/null
+From foo@baz Sat Oct 24 10:56:27 AM CEST 2020
+From: Hoang Huu Le <hoang.h.le@dektech.com.au>
+Date: Fri, 16 Oct 2020 09:31:18 +0700
+Subject: [PATCH stable 5.8 01/25] tipc: re-configure queue limit for broadcast link
+
+From: Hoang Huu Le <hoang.h.le@dektech.com.au>
+
+[ Upstream commit 75cee397ae6f1020fbb75db90aa22a51bc3318ac ]
+
+The queue limit of the broadcast link is being calculated base on initial
+MTU. However, when MTU value changed (e.g manual changing MTU on NIC
+device, MTU negotiation etc.,) we do not re-calculate queue limit.
+This gives throughput does not reflect with the change.
+
+So fix it by calling the function to re-calculate queue limit of the
+broadcast link.
+
+Acked-by: Jon Maloy <jmaloy@redhat.com>
+Signed-off-by: Hoang Huu Le <hoang.h.le@dektech.com.au>
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/tipc/bcast.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/net/tipc/bcast.c
++++ b/net/tipc/bcast.c
+@@ -108,6 +108,7 @@ static void tipc_bcbase_select_primary(s
+ {
+ struct tipc_bc_base *bb = tipc_bc_base(net);
+ int all_dests = tipc_link_bc_peers(bb->link);
++ int max_win = tipc_link_max_win(bb->link);
+ int i, mtu, prim;
+
+ bb->primary_bearer = INVALID_BEARER_ID;
+@@ -121,8 +122,11 @@ static void tipc_bcbase_select_primary(s
+ continue;
+
+ mtu = tipc_bearer_mtu(net, i);
+- if (mtu < tipc_link_mtu(bb->link))
++ if (mtu < tipc_link_mtu(bb->link)) {
+ tipc_link_set_mtu(bb->link, mtu);
++ tipc_link_set_queue_limits(bb->link, max_win,
++ max_win);
++ }
+ bb->bcast_support &= tipc_bearer_bcast_support(net, i);
+ if (bb->dests[i] < all_dests)
+ continue;
projects / thirdparty / kernel / stable-queue.git / commitdiff
