From d9df439cc731033067dc8c22088e54fbf358b957 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Fri, 10 Dec 2021 17:46:23 +0100 Subject: [PATCH] 5.4-stable patches added patches: iavf-fix-reporting-when-setting-descriptor-count.patch iavf-restore-msi-state-on-reset.patch ib-hfi1-correct-guard-on-eager-buffer-deallocation.patch seg6-fix-the-iif-in-the-ipv6-socket-control-block.patch udp-using-datalen-to-cap-max-gso-segments.patch --- ...orting-when-setting-descriptor-count.patch | 93 +++++++++++++++++++ .../iavf-restore-msi-state-on-reset.patch | 37 ++++++++ ...t-guard-on-eager-buffer-deallocation.patch | 35 +++++++ ...iif-in-the-ipv6-socket-control-block.patch | 63 +++++++++++++ queue-5.4/series | 5 + ...sing-datalen-to-cap-max-gso-segments.patch | 41 ++++++++ 6 files changed, 274 insertions(+) create mode 100644 queue-5.4/iavf-fix-reporting-when-setting-descriptor-count.patch create mode 100644 queue-5.4/iavf-restore-msi-state-on-reset.patch create mode 100644 queue-5.4/ib-hfi1-correct-guard-on-eager-buffer-deallocation.patch create mode 100644 queue-5.4/seg6-fix-the-iif-in-the-ipv6-socket-control-block.patch create mode 100644 queue-5.4/udp-using-datalen-to-cap-max-gso-segments.patch diff --git a/queue-5.4/iavf-fix-reporting-when-setting-descriptor-count.patch b/queue-5.4/iavf-fix-reporting-when-setting-descriptor-count.patch new file mode 100644 index 00000000000..b51c5c793ea --- /dev/null +++ b/queue-5.4/iavf-fix-reporting-when-setting-descriptor-count.patch @@ -0,0 +1,93 @@ +From 1a1aa356ddf3f16539f5962c01c5f702686dfc15 Mon Sep 17 00:00:00 2001 +From: Michal Maloszewski +Date: Tue, 26 Oct 2021 12:59:09 +0000 +Subject: iavf: Fix reporting when setting descriptor count + +From: Michal Maloszewski + +commit 1a1aa356ddf3f16539f5962c01c5f702686dfc15 upstream. + +iavf_set_ringparams doesn't communicate to the user that + +1. The user requested descriptor count is out of range. Instead it + just quietly sets descriptors to the "clamped" value and calls it + done. This makes it look an invalid value was successfully set as + the descriptor count when this isn't actually true. + +2. The user provided descriptor count needs to be inflated for alignment + reasons. + +This behavior is confusing. The ice driver has already addressed this +by rejecting invalid values for descriptor count and +messaging for alignment adjustments. +Do the same thing here by adding the error and info messages. + +Fixes: fbb7ddfef253 ("i40evf: core ethtool functionality") +Signed-off-by: Anirudh Venkataramanan +Signed-off-by: Michal Maloszewski +Tested-by: Konrad Jankowski +Signed-off-by: Tony Nguyen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/intel/iavf/iavf_ethtool.c | 45 ++++++++++++++++++------- + 1 file changed, 33 insertions(+), 12 deletions(-) + +--- a/drivers/net/ethernet/intel/iavf/iavf_ethtool.c ++++ b/drivers/net/ethernet/intel/iavf/iavf_ethtool.c +@@ -612,23 +612,44 @@ static int iavf_set_ringparam(struct net + if ((ring->rx_mini_pending) || (ring->rx_jumbo_pending)) + return -EINVAL; + +- new_tx_count = clamp_t(u32, ring->tx_pending, +- IAVF_MIN_TXD, +- IAVF_MAX_TXD); +- new_tx_count = ALIGN(new_tx_count, IAVF_REQ_DESCRIPTOR_MULTIPLE); +- +- new_rx_count = clamp_t(u32, ring->rx_pending, +- IAVF_MIN_RXD, +- IAVF_MAX_RXD); +- new_rx_count = ALIGN(new_rx_count, IAVF_REQ_DESCRIPTOR_MULTIPLE); ++ if (ring->tx_pending > IAVF_MAX_TXD || ++ ring->tx_pending < IAVF_MIN_TXD || ++ ring->rx_pending > IAVF_MAX_RXD || ++ ring->rx_pending < IAVF_MIN_RXD) { ++ netdev_err(netdev, "Descriptors requested (Tx: %d / Rx: %d) out of range [%d-%d] (increment %d)\n", ++ ring->tx_pending, ring->rx_pending, IAVF_MIN_TXD, ++ IAVF_MAX_RXD, IAVF_REQ_DESCRIPTOR_MULTIPLE); ++ return -EINVAL; ++ } ++ ++ new_tx_count = ALIGN(ring->tx_pending, IAVF_REQ_DESCRIPTOR_MULTIPLE); ++ if (new_tx_count != ring->tx_pending) ++ netdev_info(netdev, "Requested Tx descriptor count rounded up to %d\n", ++ new_tx_count); ++ ++ new_rx_count = ALIGN(ring->rx_pending, IAVF_REQ_DESCRIPTOR_MULTIPLE); ++ if (new_rx_count != ring->rx_pending) ++ netdev_info(netdev, "Requested Rx descriptor count rounded up to %d\n", ++ new_rx_count); + + /* if nothing to do return success */ + if ((new_tx_count == adapter->tx_desc_count) && +- (new_rx_count == adapter->rx_desc_count)) ++ (new_rx_count == adapter->rx_desc_count)) { ++ netdev_dbg(netdev, "Nothing to change, descriptor count is same as requested\n"); + return 0; ++ } ++ ++ if (new_tx_count != adapter->tx_desc_count) { ++ netdev_dbg(netdev, "Changing Tx descriptor count from %d to %d\n", ++ adapter->tx_desc_count, new_tx_count); ++ adapter->tx_desc_count = new_tx_count; ++ } + +- adapter->tx_desc_count = new_tx_count; +- adapter->rx_desc_count = new_rx_count; ++ if (new_rx_count != adapter->rx_desc_count) { ++ netdev_dbg(netdev, "Changing Rx descriptor count from %d to %d\n", ++ adapter->rx_desc_count, new_rx_count); ++ adapter->rx_desc_count = new_rx_count; ++ } + + if (netif_running(netdev)) { + adapter->flags |= IAVF_FLAG_RESET_NEEDED; diff --git a/queue-5.4/iavf-restore-msi-state-on-reset.patch b/queue-5.4/iavf-restore-msi-state-on-reset.patch new file mode 100644 index 00000000000..ba3623df9c3 --- /dev/null +++ b/queue-5.4/iavf-restore-msi-state-on-reset.patch @@ -0,0 +1,37 @@ +From 7e4dcc13965c57869684d57a1dc6dd7be589488c Mon Sep 17 00:00:00 2001 +From: Mitch Williams +Date: Fri, 4 Jun 2021 09:53:28 -0700 +Subject: iavf: restore MSI state on reset + +From: Mitch Williams + +commit 7e4dcc13965c57869684d57a1dc6dd7be589488c upstream. + +If the PF experiences an FLR, the VF's MSI and MSI-X configuration will +be conveniently and silently removed in the process. When this happens, +reset recovery will appear to complete normally but no traffic will +pass. The netdev watchdog will helpfully notify everyone of this issue. + +To prevent such public embarrassment, restore MSI configuration at every +reset. For normal resets, this will do no harm, but for VF resets +resulting from a PF FLR, this will keep the VF working. + +Fixes: 5eae00c57f5e ("i40evf: main driver core") +Signed-off-by: Mitch Williams +Tested-by: George Kuruvinakunnel +Signed-off-by: Tony Nguyen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/intel/iavf/iavf_main.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/net/ethernet/intel/iavf/iavf_main.c ++++ b/drivers/net/ethernet/intel/iavf/iavf_main.c +@@ -2151,6 +2151,7 @@ static void iavf_reset_task(struct work_ + } + + pci_set_master(adapter->pdev); ++ pci_restore_msi_state(adapter->pdev); + + if (i == IAVF_RESET_WAIT_COUNT) { + dev_err(&adapter->pdev->dev, "Reset never finished (%x)\n", diff --git a/queue-5.4/ib-hfi1-correct-guard-on-eager-buffer-deallocation.patch b/queue-5.4/ib-hfi1-correct-guard-on-eager-buffer-deallocation.patch new file mode 100644 index 00000000000..a1a37bd93e1 --- /dev/null +++ b/queue-5.4/ib-hfi1-correct-guard-on-eager-buffer-deallocation.patch @@ -0,0 +1,35 @@ +From 9292f8f9a2ac42eb320bced7153aa2e63d8cc13a Mon Sep 17 00:00:00 2001 +From: Mike Marciniszyn +Date: Mon, 29 Nov 2021 14:19:52 -0500 +Subject: IB/hfi1: Correct guard on eager buffer deallocation + +From: Mike Marciniszyn + +commit 9292f8f9a2ac42eb320bced7153aa2e63d8cc13a upstream. + +The code tests the dma address which legitimately can be 0. + +The code should test the kernel logical address to avoid leaking eager +buffer allocations that happen to map to a dma address of 0. + +Fixes: 60368186fd85 ("IB/hfi1: Fix user-space buffers mapping with IOMMU enabled") +Link: https://lore.kernel.org/r/20211129191952.101968.17137.stgit@awfm-01.cornelisnetworks.com +Signed-off-by: Mike Marciniszyn +Signed-off-by: Dennis Dalessandro +Signed-off-by: Jason Gunthorpe +Signed-off-by: Greg Kroah-Hartman +--- + drivers/infiniband/hw/hfi1/init.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/infiniband/hw/hfi1/init.c ++++ b/drivers/infiniband/hw/hfi1/init.c +@@ -1175,7 +1175,7 @@ void hfi1_free_ctxtdata(struct hfi1_devd + rcd->egrbufs.rcvtids = NULL; + + for (e = 0; e < rcd->egrbufs.alloced; e++) { +- if (rcd->egrbufs.buffers[e].dma) ++ if (rcd->egrbufs.buffers[e].addr) + dma_free_coherent(&dd->pcidev->dev, + rcd->egrbufs.buffers[e].len, + rcd->egrbufs.buffers[e].addr, diff --git a/queue-5.4/seg6-fix-the-iif-in-the-ipv6-socket-control-block.patch b/queue-5.4/seg6-fix-the-iif-in-the-ipv6-socket-control-block.patch new file mode 100644 index 00000000000..5ee9d1c10e2 --- /dev/null +++ b/queue-5.4/seg6-fix-the-iif-in-the-ipv6-socket-control-block.patch @@ -0,0 +1,63 @@ +From ae68d93354e5bf5191ee673982251864ea24dd5c Mon Sep 17 00:00:00 2001 +From: Andrea Mayer +Date: Wed, 8 Dec 2021 20:54:09 +0100 +Subject: seg6: fix the iif in the IPv6 socket control block + +From: Andrea Mayer + +commit ae68d93354e5bf5191ee673982251864ea24dd5c upstream. + +When an IPv4 packet is received, the ip_rcv_core(...) sets the receiving +interface index into the IPv4 socket control block (v5.16-rc4, +net/ipv4/ip_input.c line 510): + + IPCB(skb)->iif = skb->skb_iif; + +If that IPv4 packet is meant to be encapsulated in an outer IPv6+SRH +header, the seg6_do_srh_encap(...) performs the required encapsulation. +In this case, the seg6_do_srh_encap function clears the IPv6 socket control +block (v5.16-rc4 net/ipv6/seg6_iptunnel.c line 163): + + memset(IP6CB(skb), 0, sizeof(*IP6CB(skb))); + +The memset(...) was introduced in commit ef489749aae5 ("ipv6: sr: clear +IP6CB(skb) on SRH ip4ip6 encapsulation") a long time ago (2019-01-29). + +Since the IPv6 socket control block and the IPv4 socket control block share +the same memory area (skb->cb), the receiving interface index info is lost +(IP6CB(skb)->iif is set to zero). + +As a side effect, that condition triggers a NULL pointer dereference if +commit 0857d6f8c759 ("ipv6: When forwarding count rx stats on the orig +netdev") is applied. + +To fix that issue, we set the IP6CB(skb)->iif with the index of the +receiving interface once again. + +Fixes: ef489749aae5 ("ipv6: sr: clear IP6CB(skb) on SRH ip4ip6 encapsulation") +Signed-off-by: Andrea Mayer +Reviewed-by: David Ahern +Link: https://lore.kernel.org/r/20211208195409.12169-1-andrea.mayer@uniroma2.it +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/ipv6/seg6_iptunnel.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/net/ipv6/seg6_iptunnel.c ++++ b/net/ipv6/seg6_iptunnel.c +@@ -143,6 +143,14 @@ int seg6_do_srh_encap(struct sk_buff *sk + hdr->hop_limit = ip6_dst_hoplimit(skb_dst(skb)); + + memset(IP6CB(skb), 0, sizeof(*IP6CB(skb))); ++ ++ /* the control block has been erased, so we have to set the ++ * iif once again. ++ * We read the receiving interface index directly from the ++ * skb->skb_iif as it is done in the IPv4 receiving path (i.e.: ++ * ip_rcv_core(...)). ++ */ ++ IP6CB(skb)->iif = skb->skb_iif; + } + + hdr->nexthdr = NEXTHDR_ROUTING; diff --git a/queue-5.4/series b/queue-5.4/series index 02f05bea87f..825eb834594 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -19,3 +19,8 @@ bpf-fix-the-off-by-two-error-in-range-markings.patch ice-ignore-dropped-packets-during-init.patch bonding-make-tx_rebalance_counter-an-atomic.patch nfp-fix-memory-leak-in-nfp_cpp_area_cache_add.patch +seg6-fix-the-iif-in-the-ipv6-socket-control-block.patch +udp-using-datalen-to-cap-max-gso-segments.patch +iavf-restore-msi-state-on-reset.patch +iavf-fix-reporting-when-setting-descriptor-count.patch +ib-hfi1-correct-guard-on-eager-buffer-deallocation.patch diff --git a/queue-5.4/udp-using-datalen-to-cap-max-gso-segments.patch b/queue-5.4/udp-using-datalen-to-cap-max-gso-segments.patch new file mode 100644 index 00000000000..5ac25456937 --- /dev/null +++ b/queue-5.4/udp-using-datalen-to-cap-max-gso-segments.patch @@ -0,0 +1,41 @@ +From 158390e45612ef0fde160af0826f1740c36daf21 Mon Sep 17 00:00:00 2001 +From: Jianguo Wu +Date: Wed, 8 Dec 2021 18:03:33 +0800 +Subject: udp: using datalen to cap max gso segments + +From: Jianguo Wu + +commit 158390e45612ef0fde160af0826f1740c36daf21 upstream. + +The max number of UDP gso segments is intended to cap to UDP_MAX_SEGMENTS, +this is checked in udp_send_skb(): + + if (skb->len > cork->gso_size * UDP_MAX_SEGMENTS) { + kfree_skb(skb); + return -EINVAL; + } + +skb->len contains network and transport header len here, we should use +only data len instead. + +Fixes: bec1f6f69736 ("udp: generate gso with UDP_SEGMENT") +Signed-off-by: Jianguo Wu +Reviewed-by: Willem de Bruijn +Link: https://lore.kernel.org/r/900742e5-81fb-30dc-6e0b-375c6cdd7982@163.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/ipv4/udp.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/net/ipv4/udp.c ++++ b/net/ipv4/udp.c +@@ -845,7 +845,7 @@ static int udp_send_skb(struct sk_buff * + kfree_skb(skb); + return -EINVAL; + } +- if (skb->len > cork->gso_size * UDP_MAX_SEGMENTS) { ++ if (datalen > cork->gso_size * UDP_MAX_SEGMENTS) { + kfree_skb(skb); + return -EINVAL; + } -- 2.47.2