--- /dev/null
+From 1a1aa356ddf3f16539f5962c01c5f702686dfc15 Mon Sep 17 00:00:00 2001
+From: Michal Maloszewski <michal.maloszewski@intel.com>
+Date: Tue, 26 Oct 2021 12:59:09 +0000
+Subject: iavf: Fix reporting when setting descriptor count
+
+From: Michal Maloszewski <michal.maloszewski@intel.com>
+
+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 <anirudh.venkataramanan@intel.com>
+Signed-off-by: Michal Maloszewski <michal.maloszewski@intel.com>
+Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com>
+Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From 7e4dcc13965c57869684d57a1dc6dd7be589488c Mon Sep 17 00:00:00 2001
+From: Mitch Williams <mitch.a.williams@intel.com>
+Date: Fri, 4 Jun 2021 09:53:28 -0700
+Subject: iavf: restore MSI state on reset
+
+From: Mitch Williams <mitch.a.williams@intel.com>
+
+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 <mitch.a.williams@intel.com>
+Tested-by: George Kuruvinakunnel <george.kuruvinakunnel@intel.com>
+Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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",
--- /dev/null
+From 9292f8f9a2ac42eb320bced7153aa2e63d8cc13a Mon Sep 17 00:00:00 2001
+From: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com>
+Date: Mon, 29 Nov 2021 14:19:52 -0500
+Subject: IB/hfi1: Correct guard on eager buffer deallocation
+
+From: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com>
+
+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 <mike.marciniszyn@cornelisnetworks.com>
+Signed-off-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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,
--- /dev/null
+From ae68d93354e5bf5191ee673982251864ea24dd5c Mon Sep 17 00:00:00 2001
+From: Andrea Mayer <andrea.mayer@uniroma2.it>
+Date: Wed, 8 Dec 2021 20:54:09 +0100
+Subject: seg6: fix the iif in the IPv6 socket control block
+
+From: Andrea Mayer <andrea.mayer@uniroma2.it>
+
+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 <andrea.mayer@uniroma2.it>
+Reviewed-by: David Ahern <dsahern@kernel.org>
+Link: https://lore.kernel.org/r/20211208195409.12169-1-andrea.mayer@uniroma2.it
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
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
--- /dev/null
+From 158390e45612ef0fde160af0826f1740c36daf21 Mon Sep 17 00:00:00 2001
+From: Jianguo Wu <wujianguo@chinatelecom.cn>
+Date: Wed, 8 Dec 2021 18:03:33 +0800
+Subject: udp: using datalen to cap max gso segments
+
+From: Jianguo Wu <wujianguo@chinatelecom.cn>
+
+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 <wujianguo@chinatelecom.cn>
+Reviewed-by: Willem de Bruijn <willemb@google.com>
+Link: https://lore.kernel.org/r/900742e5-81fb-30dc-6e0b-375c6cdd7982@163.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
projects / thirdparty / kernel / stable-queue.git / commitdiff
