--- /dev/null
+From c9e143084d1a602f829115612e1ec79df3727c8b Mon Sep 17 00:00:00 2001
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Date: Mon, 1 Nov 2021 21:00:08 +0200
+Subject: mfd: intel-lpss: Fix too early PM enablement in the ACPI ->probe()
+
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+
+commit c9e143084d1a602f829115612e1ec79df3727c8b upstream.
+
+The runtime PM callback may be called as soon as the runtime PM facility
+is enabled and activated. It means that ->suspend() may be called before
+we finish probing the device in the ACPI case. Hence, NULL pointer
+dereference:
+
+ intel-lpss INT34BA:00: IRQ index 0 not found
+ BUG: kernel NULL pointer dereference, address: 0000000000000030
+ ...
+ Workqueue: pm pm_runtime_work
+ RIP: 0010:intel_lpss_suspend+0xb/0x40 [intel_lpss]
+
+To fix this, first try to register the device and only after that enable
+runtime PM facility.
+
+Fixes: 4b45efe85263 ("mfd: Add support for Intel Sunrisepoint LPSS devices")
+Reported-by: Orlando Chamberlain <redecorating@protonmail.com>
+Reported-by: Aditya Garg <gargaditya08@live.com>
+Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Tested-by: Aditya Garg <gargaditya08@live.com>
+Signed-off-by: Lee Jones <lee.jones@linaro.org>
+Link: https://lore.kernel.org/r/20211101190008.86473-1-andriy.shevchenko@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mfd/intel-lpss-acpi.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/drivers/mfd/intel-lpss-acpi.c
++++ b/drivers/mfd/intel-lpss-acpi.c
+@@ -102,6 +102,7 @@ static int intel_lpss_acpi_probe(struct
+ {
+ struct intel_lpss_platform_info *info;
+ const struct acpi_device_id *id;
++ int ret;
+
+ id = acpi_match_device(intel_lpss_acpi_ids, &pdev->dev);
+ if (!id)
+@@ -115,10 +116,14 @@ static int intel_lpss_acpi_probe(struct
+ info->mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ info->irq = platform_get_irq(pdev, 0);
+
++ ret = intel_lpss_probe(&pdev->dev, info);
++ if (ret)
++ return ret;
++
+ pm_runtime_set_active(&pdev->dev);
+ pm_runtime_enable(&pdev->dev);
+
+- return intel_lpss_probe(&pdev->dev, info);
++ return 0;
+ }
+
+ static int intel_lpss_acpi_remove(struct platform_device *pdev)
--- /dev/null
+From 710ad98c363a66a0cd8526465426c5c5f8377ee0 Mon Sep 17 00:00:00 2001
+From: Daniel Borkmann <daniel@iogearbox.net>
+Date: Thu, 6 Jan 2022 01:46:06 +0100
+Subject: veth: Do not record rx queue hint in veth_xmit
+
+From: Daniel Borkmann <daniel@iogearbox.net>
+
+commit 710ad98c363a66a0cd8526465426c5c5f8377ee0 upstream.
+
+Laurent reported that they have seen a significant amount of TCP retransmissions
+at high throughput from applications residing in network namespaces talking to
+the outside world via veths. The drops were seen on the qdisc layer (fq_codel,
+as per systemd default) of the phys device such as ena or virtio_net due to all
+traffic hitting a _single_ TX queue _despite_ multi-queue device. (Note that the
+setup was _not_ using XDP on veths as the issue is generic.)
+
+More specifically, after edbea9220251 ("veth: Store queue_mapping independently
+of XDP prog presence") which made it all the way back to v4.19.184+,
+skb_record_rx_queue() would set skb->queue_mapping to 1 (given 1 RX and 1 TX
+queue by default for veths) instead of leaving at 0.
+
+This is eventually retained and callbacks like ena_select_queue() will also pick
+single queue via netdev_core_pick_tx()'s ndo_select_queue() once all the traffic
+is forwarded to that device via upper stack or other means. Similarly, for others
+not implementing ndo_select_queue() if XPS is disabled, netdev_pick_tx() might
+call into the skb_tx_hash() and check for prior skb_rx_queue_recorded() as well.
+
+In general, it is a _bad_ idea for virtual devices like veth to mess around with
+queue selection [by default]. Given dev->real_num_tx_queues is by default 1,
+the skb->queue_mapping was left untouched, and so prior to edbea9220251 the
+netdev_core_pick_tx() could do its job upon __dev_queue_xmit() on the phys device.
+
+Unbreak this and restore prior behavior by removing the skb_record_rx_queue()
+from veth_xmit() altogether.
+
+If the veth peer has an XDP program attached, then it would return the first RX
+queue index in xdp_md->rx_queue_index (unless configured in non-default manner).
+However, this is still better than breaking the generic case.
+
+Fixes: edbea9220251 ("veth: Store queue_mapping independently of XDP prog presence")
+Fixes: 638264dc9022 ("veth: Support per queue XDP ring")
+Reported-by: Laurent Bernaille <laurent.bernaille@datadoghq.com>
+Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
+Cc: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
+Cc: Toshiaki Makita <toshiaki.makita1@gmail.com>
+Cc: Eric Dumazet <eric.dumazet@gmail.com>
+Cc: Paolo Abeni <pabeni@redhat.com>
+Cc: John Fastabend <john.fastabend@gmail.com>
+Cc: Willem de Bruijn <willemb@google.com>
+Acked-by: John Fastabend <john.fastabend@gmail.com>
+Reviewed-by: Eric Dumazet <edumazet@google.com>
+Acked-by: Toshiaki Makita <toshiaki.makita1@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/veth.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/drivers/net/veth.c
++++ b/drivers/net/veth.c
+@@ -301,7 +301,6 @@ static netdev_tx_t veth_xmit(struct sk_b
+ if (rxq < rcv->real_num_rx_queues) {
+ rq = &rcv_priv->rq[rxq];
+ rcv_xdp = rcu_access_pointer(rq->xdp_prog);
+- skb_record_rx_queue(skb, rxq);
+ }
+
+ skb_tx_timestamp(skb);
projects / thirdparty / kernel / stable-queue.git / commitdiff
