From 2126097fff5c70e5a392be30f0bcc5df49828ccb Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Sat, 31 Oct 2020 09:06:37 +0100 Subject: [PATCH] 5.9-stable patches added patches: bnxt_en-check-abort-error-state-in-bnxt_open_nic.patch bnxt_en-fix-regression-in-workqueue-cleanup-logic-in-bnxt_remove_one.patch bnxt_en-invoke-cancel_delayed_work_sync-for-pfs-also.patch bnxt_en-re-write-pci-bars-after-pci-fatal-error.patch bnxt_en-send-hwrm_func_reset-fw-command-unconditionally.patch chelsio-chtls-fix-deadlock-issue.patch chelsio-chtls-fix-memory-leaks-in-cpl-handlers.patch chelsio-chtls-fix-tls-record-info-to-user.patch cxgb4-set-up-filter-action-after-rewrites.patch gtp-fix-an-use-before-init-in-gtp_newlink.patch ibmveth-fix-use-of-ibmveth-in-a-bridge.patch ibmvnic-fix-ibmvnic_set_mac.patch mlxsw-core-fix-memory-leak-on-module-removal.patch mlxsw-only-advertise-link-modes-supported-by-both-driver-and-device.patch net-hns3-clear-the-cmdq-registers-before-unmapping-bar-region.patch net-ipa-command-payloads-already-mapped.patch net-protect-tcf_block_unbind-with-block-lock.patch net-sched-act_mpls-add-softdep-on-mpls_gso.ko.patch net-smc-fix-invalid-return-code-in-smcd_new_buf_create.patch net-smc-fix-suppressed-return-code.patch netem-fix-zero-division-in-tabledist.patch r8169-fix-issue-with-forced-threading-in-combination-with-shared-interrupts.patch ravb-fix-bit-fields-checking-in-ravb_hwtstamp_get.patch tcp-prevent-low-rmem-stalls-with-so_rcvlowat.patch tipc-fix-memory-leak-caused-by-tipc_buf_append.patch --- ...k-abort-error-state-in-bnxt_open_nic.patch | 85 ++++++++++ ...eue-cleanup-logic-in-bnxt_remove_one.patch | 51 ++++++ ...ancel_delayed_work_sync-for-pfs-also.patch | 65 ++++++++ ...write-pci-bars-after-pci-fatal-error.patch | 82 ++++++++++ ...unc_reset-fw-command-unconditionally.patch | 42 +++++ .../chelsio-chtls-fix-deadlock-issue.patch | 40 +++++ ...tls-fix-memory-leaks-in-cpl-handlers.patch | 67 ++++++++ ...io-chtls-fix-tls-record-info-to-user.patch | 51 ++++++ ...-set-up-filter-action-after-rewrites.patch | 153 ++++++++++++++++++ ...ix-an-use-before-init-in-gtp_newlink.patch | 86 ++++++++++ ...mveth-fix-use-of-ibmveth-in-a-bridge.patch | 39 +++++ queue-5.9/ibmvnic-fix-ibmvnic_set_mac.patch | 50 ++++++ ...re-fix-memory-leak-on-module-removal.patch | 56 +++++++ ...-supported-by-both-driver-and-device.patch | 141 ++++++++++++++++ ...egisters-before-unmapping-bar-region.patch | 94 +++++++++++ ...-ipa-command-payloads-already-mapped.patch | 84 ++++++++++ ...ect-tcf_block_unbind-with-block-lock.patch | 90 +++++++++++ ...-act_mpls-add-softdep-on-mpls_gso.ko.patch | 32 ++++ ...d-return-code-in-smcd_new_buf_create.patch | 35 ++++ .../net-smc-fix-suppressed-return-code.patch | 38 +++++ ...netem-fix-zero-division-in-tabledist.patch | 70 ++++++++ ...n-combination-with-shared-interrupts.patch | 49 ++++++ ...fields-checking-in-ravb_hwtstamp_get.patch | 69 ++++++++ queue-5.9/series | 25 +++ ...ent-low-rmem-stalls-with-so_rcvlowat.patch | 63 ++++++++ ...emory-leak-caused-by-tipc_buf_append.patch | 72 +++++++++ 26 files changed, 1729 insertions(+) create mode 100644 queue-5.9/bnxt_en-check-abort-error-state-in-bnxt_open_nic.patch create mode 100644 queue-5.9/bnxt_en-fix-regression-in-workqueue-cleanup-logic-in-bnxt_remove_one.patch create mode 100644 queue-5.9/bnxt_en-invoke-cancel_delayed_work_sync-for-pfs-also.patch create mode 100644 queue-5.9/bnxt_en-re-write-pci-bars-after-pci-fatal-error.patch create mode 100644 queue-5.9/bnxt_en-send-hwrm_func_reset-fw-command-unconditionally.patch create mode 100644 queue-5.9/chelsio-chtls-fix-deadlock-issue.patch create mode 100644 queue-5.9/chelsio-chtls-fix-memory-leaks-in-cpl-handlers.patch create mode 100644 queue-5.9/chelsio-chtls-fix-tls-record-info-to-user.patch create mode 100644 queue-5.9/cxgb4-set-up-filter-action-after-rewrites.patch create mode 100644 queue-5.9/gtp-fix-an-use-before-init-in-gtp_newlink.patch create mode 100644 queue-5.9/ibmveth-fix-use-of-ibmveth-in-a-bridge.patch create mode 100644 queue-5.9/ibmvnic-fix-ibmvnic_set_mac.patch create mode 100644 queue-5.9/mlxsw-core-fix-memory-leak-on-module-removal.patch create mode 100644 queue-5.9/mlxsw-only-advertise-link-modes-supported-by-both-driver-and-device.patch create mode 100644 queue-5.9/net-hns3-clear-the-cmdq-registers-before-unmapping-bar-region.patch create mode 100644 queue-5.9/net-ipa-command-payloads-already-mapped.patch create mode 100644 queue-5.9/net-protect-tcf_block_unbind-with-block-lock.patch create mode 100644 queue-5.9/net-sched-act_mpls-add-softdep-on-mpls_gso.ko.patch create mode 100644 queue-5.9/net-smc-fix-invalid-return-code-in-smcd_new_buf_create.patch create mode 100644 queue-5.9/net-smc-fix-suppressed-return-code.patch create mode 100644 queue-5.9/netem-fix-zero-division-in-tabledist.patch create mode 100644 queue-5.9/r8169-fix-issue-with-forced-threading-in-combination-with-shared-interrupts.patch create mode 100644 queue-5.9/ravb-fix-bit-fields-checking-in-ravb_hwtstamp_get.patch create mode 100644 queue-5.9/tcp-prevent-low-rmem-stalls-with-so_rcvlowat.patch create mode 100644 queue-5.9/tipc-fix-memory-leak-caused-by-tipc_buf_append.patch diff --git a/queue-5.9/bnxt_en-check-abort-error-state-in-bnxt_open_nic.patch b/queue-5.9/bnxt_en-check-abort-error-state-in-bnxt_open_nic.patch new file mode 100644 index 00000000000..ff4ee20dfac --- /dev/null +++ b/queue-5.9/bnxt_en-check-abort-error-state-in-bnxt_open_nic.patch @@ -0,0 +1,85 @@ +From foo@baz Sat Oct 31 09:05:46 AM CET 2020 +From: Michael Chan +Date: Mon, 26 Oct 2020 00:18:20 -0400 +Subject: [PATCH stable 5.9 01/25] bnxt_en: Check abort error state in bnxt_open_nic(). + +From: Michael Chan + +[ Upstream commit a1301f08c5acf992d9c1fafddc84c3a822844b04 ] + +bnxt_open_nic() is called during configuration changes that require +the NIC to be closed and then opened. This call is protected by +rtnl_lock. Firmware reset can be happening at the same time. Only +critical portions of the entire firmware reset sequence are protected +by the rtnl_lock. It is possible that bnxt_open_nic() can be called +when the firmware reset sequence is aborting. In that case, +bnxt_open_nic() needs to check if the ABORT_ERR flag is set and +abort if it is. The configuration change that resulted in the +bnxt_open_nic() call will fail but the NIC will be brought to a +consistent IF_DOWN state. + +Without this patch, if bnxt_open_nic() were to continue in this error +state, it may crash like this: + +[ 1648.659736] BUG: unable to handle kernel NULL pointer dereference at (null) +[ 1648.659768] IP: [] bnxt_alloc_mem+0x50a/0x1140 [bnxt_en] +[ 1648.659796] PGD 101e1b3067 PUD 101e1b2067 PMD 0 +[ 1648.659813] Oops: 0000 [#1] SMP +[ 1648.659825] Modules linked in: xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 tun bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter sunrpc dell_smbios dell_wmi_descriptor dcdbas amd64_edac_mod edac_mce_amd kvm_amd kvm irqbypass crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper vfat cryptd fat pcspkr ipmi_ssif sg k10temp i2c_piix4 wmi ipmi_si ipmi_devintf ipmi_msghandler tpm_crb acpi_power_meter sch_fq_codel ip_tables xfs libcrc32c sd_mod crc_t10dif crct10dif_generic mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm ahci drm libahci megaraid_sas crct10dif_pclmul crct10dif_common +[ 1648.660063] tg3 libata crc32c_intel bnxt_en(OE) drm_panel_orientation_quirks devlink ptp pps_core dm_mirror dm_region_hash dm_log dm_mod fuse +[ 1648.660105] CPU: 13 PID: 3867 Comm: ethtool Kdump: loaded Tainted: G OE ------------ 3.10.0-1152.el7.x86_64 #1 +[ 1648.660911] Hardware name: Dell Inc. PowerEdge R7515/0R4CNN, BIOS 1.2.14 01/28/2020 +[ 1648.661662] task: ffff94e64cbc9080 ti: ffff94f55df1c000 task.ti: ffff94f55df1c000 +[ 1648.662409] RIP: 0010:[] [] bnxt_alloc_mem+0x50a/0x1140 [bnxt_en] +[ 1648.663171] RSP: 0018:ffff94f55df1fba8 EFLAGS: 00010202 +[ 1648.663927] RAX: 0000000000000000 RBX: ffff94e6827e0000 RCX: 0000000000000000 +[ 1648.664684] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff94e6827e08c0 +[ 1648.665433] RBP: ffff94f55df1fc20 R08: 00000000000001ff R09: 0000000000000008 +[ 1648.666184] R10: 0000000000000d53 R11: ffff94f55df1f7ce R12: ffff94e6827e08c0 +[ 1648.666940] R13: ffff94e6827e08c0 R14: ffff94e6827e08c0 R15: ffffffffb9115e40 +[ 1648.667695] FS: 00007f8aadba5740(0000) GS:ffff94f57eb40000(0000) knlGS:0000000000000000 +[ 1648.668447] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 1648.669202] CR2: 0000000000000000 CR3: 0000001022772000 CR4: 0000000000340fe0 +[ 1648.669966] Call Trace: +[ 1648.670730] [] ? bnxt_need_reserve_rings+0x9d/0x170 [bnxt_en] +[ 1648.671496] [] __bnxt_open_nic+0x8a/0x9a0 [bnxt_en] +[ 1648.672263] [] ? bnxt_close_nic+0x59/0x1b0 [bnxt_en] +[ 1648.673031] [] bnxt_open_nic+0x1b/0x50 [bnxt_en] +[ 1648.673793] [] bnxt_set_ringparam+0x6c/0xa0 [bnxt_en] +[ 1648.674550] [] dev_ethtool+0x1334/0x21a0 +[ 1648.675306] [] dev_ioctl+0x1ef/0x5f0 +[ 1648.676061] [] sock_do_ioctl+0x4d/0x60 +[ 1648.676810] [] sock_ioctl+0x1eb/0x2d0 +[ 1648.677548] [] do_vfs_ioctl+0x3a0/0x5b0 +[ 1648.678282] [] ? __do_page_fault+0x238/0x500 +[ 1648.679016] [] SyS_ioctl+0xa1/0xc0 +[ 1648.679745] [] system_call_fastpath+0x25/0x2a +[ 1648.680461] Code: 9e 60 01 00 00 0f 1f 40 00 45 8b 8e 48 01 00 00 31 c9 45 85 c9 0f 8e 73 01 00 00 66 0f 1f 44 00 00 49 8b 86 a8 00 00 00 48 63 d1 <48> 8b 14 d0 48 85 d2 0f 84 46 01 00 00 41 8b 86 44 01 00 00 c7 +[ 1648.681986] RIP [] bnxt_alloc_mem+0x50a/0x1140 [bnxt_en] +[ 1648.682724] RSP +[ 1648.683451] CR2: 0000000000000000 + +Fixes: ec5d31e3c15d ("bnxt_en: Handle firmware reset status during IF_UP.") +Reviewed-by: Vasundhara Volam +Reviewed-by: Pavan Chebbi +Signed-off-by: Michael Chan +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/broadcom/bnxt/bnxt.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c ++++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c +@@ -9566,7 +9566,10 @@ int bnxt_open_nic(struct bnxt *bp, bool + { + int rc = 0; + +- rc = __bnxt_open_nic(bp, irq_re_init, link_re_init); ++ if (test_bit(BNXT_STATE_ABORT_ERR, &bp->state)) ++ rc = -EIO; ++ if (!rc) ++ rc = __bnxt_open_nic(bp, irq_re_init, link_re_init); + if (rc) { + netdev_err(bp->dev, "nic open fail (rc: %x)\n", rc); + dev_close(bp->dev); diff --git a/queue-5.9/bnxt_en-fix-regression-in-workqueue-cleanup-logic-in-bnxt_remove_one.patch b/queue-5.9/bnxt_en-fix-regression-in-workqueue-cleanup-logic-in-bnxt_remove_one.patch new file mode 100644 index 00000000000..2b2dee07c83 --- /dev/null +++ b/queue-5.9/bnxt_en-fix-regression-in-workqueue-cleanup-logic-in-bnxt_remove_one.patch @@ -0,0 +1,51 @@ +From foo@baz Sat Oct 31 09:05:46 AM CET 2020 +From: Vasundhara Volam +Date: Mon, 26 Oct 2020 00:18:17 -0400 +Subject: [PATCH stable 5.9 02/25] bnxt_en: Fix regression in workqueue cleanup logic in bnxt_remove_one(). + +From: Vasundhara Volam + +[ Upstream commit 21d6a11e2cadfb8446265a3efff0e2aad206e15e ] + +A recent patch has moved the workqueue cleanup logic before +calling unregister_netdev() in bnxt_remove_one(). This caused a +regression because the workqueue can be restarted if the device is +still open. Workqueue cleanup must be done after unregister_netdev(). +The workqueue will not restart itself after the device is closed. + +Call bnxt_cancel_sp_work() after unregister_netdev() and +call bnxt_dl_fw_reporters_destroy() after that. This fixes the +regession and the original NULL ptr dereference issue. + +Fixes: b16939b59cc0 ("bnxt_en: Fix NULL ptr dereference crash in bnxt_fw_reset_task()") +Signed-off-by: Vasundhara Volam +Signed-off-by: Michael Chan +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/broadcom/bnxt/bnxt.c | 9 +++++---- + 1 file changed, 5 insertions(+), 4 deletions(-) + +--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c ++++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c +@@ -11790,15 +11790,16 @@ static void bnxt_remove_one(struct pci_d + if (BNXT_PF(bp)) + bnxt_sriov_disable(bp); + ++ if (BNXT_PF(bp)) ++ devlink_port_type_clear(&bp->dl_port); ++ pci_disable_pcie_error_reporting(pdev); ++ unregister_netdev(dev); + clear_bit(BNXT_STATE_IN_FW_RESET, &bp->state); ++ /* Flush any pending tasks */ + bnxt_cancel_sp_work(bp); + bp->sp_event = 0; + + bnxt_dl_fw_reporters_destroy(bp, true); +- if (BNXT_PF(bp)) +- devlink_port_type_clear(&bp->dl_port); +- pci_disable_pcie_error_reporting(pdev); +- unregister_netdev(dev); + bnxt_dl_unregister(bp); + bnxt_shutdown_tc(bp); + diff --git a/queue-5.9/bnxt_en-invoke-cancel_delayed_work_sync-for-pfs-also.patch b/queue-5.9/bnxt_en-invoke-cancel_delayed_work_sync-for-pfs-also.patch new file mode 100644 index 00000000000..53281aacf56 --- /dev/null +++ b/queue-5.9/bnxt_en-invoke-cancel_delayed_work_sync-for-pfs-also.patch @@ -0,0 +1,65 @@ +From foo@baz Sat Oct 31 09:05:46 AM CET 2020 +From: Vasundhara Volam +Date: Mon, 26 Oct 2020 00:18:18 -0400 +Subject: [PATCH stable 5.9 03/25] bnxt_en: Invoke cancel_delayed_work_sync() for PFs also. + +From: Vasundhara Volam + +[ Upstream commit 631ce27a3006fc0b732bfd589c6df505f62eadd9 ] + +As part of the commit b148bb238c02 +("bnxt_en: Fix possible crash in bnxt_fw_reset_task()."), +cancel_delayed_work_sync() is called only for VFs to fix a possible +crash by cancelling any pending delayed work items. It was assumed +by mistake that the flush_workqueue() call on the PF would flush +delayed work items as well. + +As flush_workqueue() does not cancel the delayed workqueue, extend +the fix for PFs. This fix will avoid the system crash, if there are +any pending delayed work items in fw_reset_task() during driver's +.remove() call. + +Unify the workqueue cleanup logic for both PF and VF by calling +cancel_work_sync() and cancel_delayed_work_sync() directly in +bnxt_remove_one(). + +Fixes: b148bb238c02 ("bnxt_en: Fix possible crash in bnxt_fw_reset_task().") +Reviewed-by: Pavan Chebbi +Reviewed-by: Andy Gospodarek +Signed-off-by: Vasundhara Volam +Signed-off-by: Michael Chan +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/broadcom/bnxt/bnxt.c | 13 ++----------- + 1 file changed, 2 insertions(+), 11 deletions(-) + +--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c ++++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c +@@ -1158,16 +1158,6 @@ static void bnxt_queue_sp_work(struct bn + schedule_work(&bp->sp_task); + } + +-static void bnxt_cancel_sp_work(struct bnxt *bp) +-{ +- if (BNXT_PF(bp)) { +- flush_workqueue(bnxt_pf_wq); +- } else { +- cancel_work_sync(&bp->sp_task); +- cancel_delayed_work_sync(&bp->fw_reset_task); +- } +-} +- + static void bnxt_sched_reset(struct bnxt *bp, struct bnxt_rx_ring_info *rxr) + { + if (!rxr->bnapi->in_reset) { +@@ -11796,7 +11786,8 @@ static void bnxt_remove_one(struct pci_d + unregister_netdev(dev); + clear_bit(BNXT_STATE_IN_FW_RESET, &bp->state); + /* Flush any pending tasks */ +- bnxt_cancel_sp_work(bp); ++ cancel_work_sync(&bp->sp_task); ++ cancel_delayed_work_sync(&bp->fw_reset_task); + bp->sp_event = 0; + + bnxt_dl_fw_reporters_destroy(bp, true); diff --git a/queue-5.9/bnxt_en-re-write-pci-bars-after-pci-fatal-error.patch b/queue-5.9/bnxt_en-re-write-pci-bars-after-pci-fatal-error.patch new file mode 100644 index 00000000000..1886145dab9 --- /dev/null +++ b/queue-5.9/bnxt_en-re-write-pci-bars-after-pci-fatal-error.patch @@ -0,0 +1,82 @@ +From foo@baz Sat Oct 31 09:05:46 AM CET 2020 +From: Vasundhara Volam +Date: Mon, 26 Oct 2020 00:18:19 -0400 +Subject: [PATCH stable 5.9 04/25] bnxt_en: Re-write PCI BARs after PCI fatal error. + +From: Vasundhara Volam + +[ Upstream commit f75d9a0aa96721d20011cd5f8c7a24eb32728589 ] + +When a PCIe fatal error occurs, the internal latched BAR addresses +in the chip get reset even though the BAR register values in config +space are retained. + +pci_restore_state() will not rewrite the BAR addresses if the +BAR address values are valid, causing the chip's internal BAR addresses +to stay invalid. So we need to zero the BAR registers during PCIe fatal +error to force pci_restore_state() to restore the BAR addresses. These +write cycles to the BAR registers will cause the proper BAR addresses to +latch internally. + +Fixes: 6316ea6db93d ("bnxt_en: Enable AER support.") +Signed-off-by: Vasundhara Volam +Signed-off-by: Michael Chan +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/broadcom/bnxt/bnxt.c | 19 ++++++++++++++++++- + drivers/net/ethernet/broadcom/bnxt/bnxt.h | 1 + + 2 files changed, 19 insertions(+), 1 deletion(-) + +--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c ++++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c +@@ -12530,6 +12530,9 @@ static pci_ers_result_t bnxt_io_error_de + return PCI_ERS_RESULT_DISCONNECT; + } + ++ if (state == pci_channel_io_frozen) ++ set_bit(BNXT_STATE_PCI_CHANNEL_IO_FROZEN, &bp->state); ++ + if (netif_running(netdev)) + bnxt_close(netdev); + +@@ -12556,7 +12559,7 @@ static pci_ers_result_t bnxt_io_slot_res + { + struct net_device *netdev = pci_get_drvdata(pdev); + struct bnxt *bp = netdev_priv(netdev); +- int err = 0; ++ int err = 0, off; + pci_ers_result_t result = PCI_ERS_RESULT_DISCONNECT; + + netdev_info(bp->dev, "PCI Slot Reset\n"); +@@ -12568,6 +12571,20 @@ static pci_ers_result_t bnxt_io_slot_res + "Cannot re-enable PCI device after reset.\n"); + } else { + pci_set_master(pdev); ++ /* Upon fatal error, our device internal logic that latches to ++ * BAR value is getting reset and will restore only upon ++ * rewritting the BARs. ++ * ++ * As pci_restore_state() does not re-write the BARs if the ++ * value is same as saved value earlier, driver needs to ++ * write the BARs to 0 to force restore, in case of fatal error. ++ */ ++ if (test_and_clear_bit(BNXT_STATE_PCI_CHANNEL_IO_FROZEN, ++ &bp->state)) { ++ for (off = PCI_BASE_ADDRESS_0; ++ off <= PCI_BASE_ADDRESS_5; off += 4) ++ pci_write_config_dword(bp->pdev, off, 0); ++ } + pci_restore_state(pdev); + pci_save_state(pdev); + +--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.h ++++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.h +@@ -1736,6 +1736,7 @@ struct bnxt { + #define BNXT_STATE_ABORT_ERR 5 + #define BNXT_STATE_FW_FATAL_COND 6 + #define BNXT_STATE_DRV_REGISTERED 7 ++#define BNXT_STATE_PCI_CHANNEL_IO_FROZEN 8 + + #define BNXT_NO_FW_ACCESS(bp) \ + (test_bit(BNXT_STATE_FW_FATAL_COND, &(bp)->state) || \ diff --git a/queue-5.9/bnxt_en-send-hwrm_func_reset-fw-command-unconditionally.patch b/queue-5.9/bnxt_en-send-hwrm_func_reset-fw-command-unconditionally.patch new file mode 100644 index 00000000000..c760e276cf9 --- /dev/null +++ b/queue-5.9/bnxt_en-send-hwrm_func_reset-fw-command-unconditionally.patch @@ -0,0 +1,42 @@ +From foo@baz Sat Oct 31 09:05:46 AM CET 2020 +From: Vasundhara Volam +Date: Mon, 26 Oct 2020 00:18:21 -0400 +Subject: [PATCH stable 5.9 05/25] bnxt_en: Send HWRM_FUNC_RESET fw command unconditionally. + +From: Vasundhara Volam + +[ Upstream commit 825741b071722f1c8ad692cead562c4b5f5eaa93 ] + +In the AER or firmware reset flow, if we are in fatal error state or +if pci_channel_offline() is true, we don't send any commands to the +firmware because the commands will likely not reach the firmware and +most commands don't matter much because the firmware is likely to be +reset imminently. + +However, the HWRM_FUNC_RESET command is different and we should always +attempt to send it. In the AER flow for example, the .slot_reset() +call will trigger this fw command and we need to try to send it to +effect the proper reset. + +Fixes: b340dc680ed4 ("bnxt_en: Avoid sending firmware messages when AER error is detected.") +Reviewed-by: Edwin Peer +Signed-off-by: Vasundhara Volam +Signed-off-by: Michael Chan +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/broadcom/bnxt/bnxt.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c ++++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c +@@ -4296,7 +4296,8 @@ static int bnxt_hwrm_do_send_msg(struct + u32 bar_offset = BNXT_GRCPF_REG_CHIMP_COMM; + u16 dst = BNXT_HWRM_CHNL_CHIMP; + +- if (BNXT_NO_FW_ACCESS(bp)) ++ if (BNXT_NO_FW_ACCESS(bp) && ++ le16_to_cpu(req->req_type) != HWRM_FUNC_RESET) + return -EBUSY; + + if (msg_len > BNXT_HWRM_MAX_REQ_LEN) { diff --git a/queue-5.9/chelsio-chtls-fix-deadlock-issue.patch b/queue-5.9/chelsio-chtls-fix-deadlock-issue.patch new file mode 100644 index 00000000000..cde463ded9e --- /dev/null +++ b/queue-5.9/chelsio-chtls-fix-deadlock-issue.patch @@ -0,0 +1,40 @@ +From foo@baz Sat Oct 31 09:05:46 AM CET 2020 +From: Vinay Kumar Yadav +Date: Mon, 26 Oct 2020 01:05:39 +0530 +Subject: [PATCH stable 5.9 06/25] chelsio/chtls: fix deadlock issue + +From: Vinay Kumar Yadav + +[ Upstream commit 28e9dcd9172028263c8225c15c4e329e08475e89 ] + +In chtls_pass_establish() we hold child socket lock using bh_lock_sock +and we are again trying bh_lock_sock in add_to_reap_list, causing deadlock. +Remove bh_lock_sock in add_to_reap_list() as lock is already held. + +Fixes: cc35c88ae4db ("crypto : chtls - CPL handler definition") +Signed-off-by: Vinay Kumar Yadav +Link: https://lore.kernel.org/r/20201025193538.31112-1-vinay.yadav@chelsio.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/crypto/chelsio/chtls/chtls_cm.c | 2 -- + 1 file changed, 2 deletions(-) + +--- a/drivers/crypto/chelsio/chtls/chtls_cm.c ++++ b/drivers/crypto/chelsio/chtls/chtls_cm.c +@@ -1514,7 +1514,6 @@ static void add_to_reap_list(struct sock + struct chtls_sock *csk = sk->sk_user_data; + + local_bh_disable(); +- bh_lock_sock(sk); + release_tcp_port(sk); /* release the port immediately */ + + spin_lock(&reap_list_lock); +@@ -1523,7 +1522,6 @@ static void add_to_reap_list(struct sock + if (!csk->passive_reap_next) + schedule_work(&reap_task); + spin_unlock(&reap_list_lock); +- bh_unlock_sock(sk); + local_bh_enable(); + } + diff --git a/queue-5.9/chelsio-chtls-fix-memory-leaks-in-cpl-handlers.patch b/queue-5.9/chelsio-chtls-fix-memory-leaks-in-cpl-handlers.patch new file mode 100644 index 00000000000..bb5ea523ecf --- /dev/null +++ b/queue-5.9/chelsio-chtls-fix-memory-leaks-in-cpl-handlers.patch @@ -0,0 +1,67 @@ +From foo@baz Sat Oct 31 09:05:46 AM CET 2020 +From: Vinay Kumar Yadav +Date: Mon, 26 Oct 2020 01:12:29 +0530 +Subject: [PATCH stable 5.9 07/25] chelsio/chtls: fix memory leaks in CPL handlers + +From: Vinay Kumar Yadav + +[ Upstream commit 6daa1da4e262b0cd52ef0acc1989ff22b5540264 ] + +CPL handler functions chtls_pass_open_rpl() and +chtls_close_listsrv_rpl() should return CPL_RET_BUF_DONE +so that caller function will do skb free to avoid leak. + +Fixes: cc35c88ae4db ("crypto : chtls - CPL handler definition") +Signed-off-by: Vinay Kumar Yadav +Link: https://lore.kernel.org/r/20201025194228.31271-1-vinay.yadav@chelsio.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/crypto/chelsio/chtls/chtls_cm.c | 27 ++++++++++++--------------- + 1 file changed, 12 insertions(+), 15 deletions(-) + +--- a/drivers/crypto/chelsio/chtls/chtls_cm.c ++++ b/drivers/crypto/chelsio/chtls/chtls_cm.c +@@ -772,14 +772,13 @@ static int chtls_pass_open_rpl(struct ch + if (rpl->status != CPL_ERR_NONE) { + pr_info("Unexpected PASS_OPEN_RPL status %u for STID %u\n", + rpl->status, stid); +- return CPL_RET_BUF_DONE; ++ } else { ++ cxgb4_free_stid(cdev->tids, stid, listen_ctx->lsk->sk_family); ++ sock_put(listen_ctx->lsk); ++ kfree(listen_ctx); ++ module_put(THIS_MODULE); + } +- cxgb4_free_stid(cdev->tids, stid, listen_ctx->lsk->sk_family); +- sock_put(listen_ctx->lsk); +- kfree(listen_ctx); +- module_put(THIS_MODULE); +- +- return 0; ++ return CPL_RET_BUF_DONE; + } + + static int chtls_close_listsrv_rpl(struct chtls_dev *cdev, struct sk_buff *skb) +@@ -796,15 +795,13 @@ static int chtls_close_listsrv_rpl(struc + if (rpl->status != CPL_ERR_NONE) { + pr_info("Unexpected CLOSE_LISTSRV_RPL status %u for STID %u\n", + rpl->status, stid); +- return CPL_RET_BUF_DONE; ++ } else { ++ cxgb4_free_stid(cdev->tids, stid, listen_ctx->lsk->sk_family); ++ sock_put(listen_ctx->lsk); ++ kfree(listen_ctx); ++ module_put(THIS_MODULE); + } +- +- cxgb4_free_stid(cdev->tids, stid, listen_ctx->lsk->sk_family); +- sock_put(listen_ctx->lsk); +- kfree(listen_ctx); +- module_put(THIS_MODULE); +- +- return 0; ++ return CPL_RET_BUF_DONE; + } + + static void chtls_purge_wr_queue(struct sock *sk) diff --git a/queue-5.9/chelsio-chtls-fix-tls-record-info-to-user.patch b/queue-5.9/chelsio-chtls-fix-tls-record-info-to-user.patch new file mode 100644 index 00000000000..d439939bd84 --- /dev/null +++ b/queue-5.9/chelsio-chtls-fix-tls-record-info-to-user.patch @@ -0,0 +1,51 @@ +From foo@baz Sat Oct 31 09:05:46 AM CET 2020 +From: Vinay Kumar Yadav +Date: Fri, 23 Oct 2020 00:35:57 +0530 +Subject: [PATCH stable 5.9 08/25] chelsio/chtls: fix tls record info to user + +From: Vinay Kumar Yadav + +[ Upstream commit 4f3391ce8f5a69e7e6d66d0a3fc654eb6dbdc919 ] + +chtls_pt_recvmsg() receives a skb with tls header and subsequent +skb with data, need to finalize the data copy whenever next skb +with tls header is available. but here current tls header is +overwritten by next available tls header, ends up corrupting +user buffer data. fixing it by finalizing current record whenever +next skb contains tls header. + +v1->v2: +- Improved commit message. + +Fixes: 17a7d24aa89d ("crypto: chtls - generic handling of data and hdr") +Signed-off-by: Vinay Kumar Yadav +Link: https://lore.kernel.org/r/20201022190556.21308-1-vinay.yadav@chelsio.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/crypto/chelsio/chtls/chtls_io.c | 7 +++++-- + 1 file changed, 5 insertions(+), 2 deletions(-) + +--- a/drivers/crypto/chelsio/chtls/chtls_io.c ++++ b/drivers/crypto/chelsio/chtls/chtls_io.c +@@ -1585,6 +1585,7 @@ skip_copy: + tp->urg_data = 0; + + if ((avail + offset) >= skb->len) { ++ struct sk_buff *next_skb; + if (ULP_SKB_CB(skb)->flags & ULPCB_FLAG_TLS_HDR) { + tp->copied_seq += skb->len; + hws->rcvpld = skb->hdr_len; +@@ -1595,8 +1596,10 @@ skip_copy: + chtls_free_skb(sk, skb); + buffers_freed++; + hws->copied_seq = 0; +- if (copied >= target && +- !skb_peek(&sk->sk_receive_queue)) ++ next_skb = skb_peek(&sk->sk_receive_queue); ++ if (copied >= target && !next_skb) ++ break; ++ if (ULP_SKB_CB(next_skb)->flags & ULPCB_FLAG_TLS_HDR) + break; + } + } while (len > 0); diff --git a/queue-5.9/cxgb4-set-up-filter-action-after-rewrites.patch b/queue-5.9/cxgb4-set-up-filter-action-after-rewrites.patch new file mode 100644 index 00000000000..196ecd8c090 --- /dev/null +++ b/queue-5.9/cxgb4-set-up-filter-action-after-rewrites.patch @@ -0,0 +1,153 @@ +From foo@baz Sat Oct 31 09:05:46 AM CET 2020 +From: Raju Rangoju +Date: Fri, 23 Oct 2020 17:28:52 +0530 +Subject: [PATCH stable 5.9 09/25] cxgb4: set up filter action after rewrites + +From: Raju Rangoju + +[ Upstream commit 937d8420588421eaa5c7aa5c79b26b42abb288ef ] + +The current code sets up the filter action field before +rewrites are set up. When the action 'switch' is used +with rewrites, this may result in initial few packets +that get switched out don't have rewrites applied +on them. + +So, make sure filter action is set up along with rewrites +or only after everything else is set up for rewrites. + +Fixes: 12b276fbf6e0 ("cxgb4: add support to create hash filters") +Signed-off-by: Raju Rangoju +Link: https://lore.kernel.org/r/20201023115852.18262-1-rajur@chelsio.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c | 56 ++++++++++------------ + drivers/net/ethernet/chelsio/cxgb4/t4_tcb.h | 4 + + 2 files changed, 31 insertions(+), 29 deletions(-) + +--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c ++++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_filter.c +@@ -145,13 +145,13 @@ static int configure_filter_smac(struct + int err; + + /* do a set-tcb for smac-sel and CWR bit.. */ +- err = set_tcb_tflag(adap, f, f->tid, TF_CCTRL_CWR_S, 1, 1); +- if (err) +- goto smac_err; +- + err = set_tcb_field(adap, f, f->tid, TCB_SMAC_SEL_W, + TCB_SMAC_SEL_V(TCB_SMAC_SEL_M), + TCB_SMAC_SEL_V(f->smt->idx), 1); ++ if (err) ++ goto smac_err; ++ ++ err = set_tcb_tflag(adap, f, f->tid, TF_CCTRL_CWR_S, 1, 1); + if (!err) + return 0; + +@@ -865,6 +865,7 @@ int set_filter_wr(struct adapter *adapte + FW_FILTER_WR_DIRSTEERHASH_V(f->fs.dirsteerhash) | + FW_FILTER_WR_LPBK_V(f->fs.action == FILTER_SWITCH) | + FW_FILTER_WR_DMAC_V(f->fs.newdmac) | ++ FW_FILTER_WR_SMAC_V(f->fs.newsmac) | + FW_FILTER_WR_INSVLAN_V(f->fs.newvlan == VLAN_INSERT || + f->fs.newvlan == VLAN_REWRITE) | + FW_FILTER_WR_RMVLAN_V(f->fs.newvlan == VLAN_REMOVE || +@@ -882,7 +883,7 @@ int set_filter_wr(struct adapter *adapte + FW_FILTER_WR_OVLAN_VLD_V(f->fs.val.ovlan_vld) | + FW_FILTER_WR_IVLAN_VLDM_V(f->fs.mask.ivlan_vld) | + FW_FILTER_WR_OVLAN_VLDM_V(f->fs.mask.ovlan_vld)); +- fwr->smac_sel = 0; ++ fwr->smac_sel = f->smt->idx; + fwr->rx_chan_rx_rpl_iq = + htons(FW_FILTER_WR_RX_CHAN_V(0) | + FW_FILTER_WR_RX_RPL_IQ_V(adapter->sge.fw_evtq.abs_id)); +@@ -1326,11 +1327,8 @@ static void mk_act_open_req6(struct filt + TX_QUEUE_V(f->fs.nat_mode) | + T5_OPT_2_VALID_F | + RX_CHANNEL_V(cxgb4_port_e2cchan(f->dev)) | +- CONG_CNTRL_V((f->fs.action == FILTER_DROP) | +- (f->fs.dirsteer << 1)) | + PACE_V((f->fs.maskhash) | +- ((f->fs.dirsteerhash) << 1)) | +- CCTRL_ECN_V(f->fs.action == FILTER_SWITCH)); ++ ((f->fs.dirsteerhash) << 1))); + } + + static void mk_act_open_req(struct filter_entry *f, struct sk_buff *skb, +@@ -1366,11 +1364,8 @@ static void mk_act_open_req(struct filte + TX_QUEUE_V(f->fs.nat_mode) | + T5_OPT_2_VALID_F | + RX_CHANNEL_V(cxgb4_port_e2cchan(f->dev)) | +- CONG_CNTRL_V((f->fs.action == FILTER_DROP) | +- (f->fs.dirsteer << 1)) | + PACE_V((f->fs.maskhash) | +- ((f->fs.dirsteerhash) << 1)) | +- CCTRL_ECN_V(f->fs.action == FILTER_SWITCH)); ++ ((f->fs.dirsteerhash) << 1))); + } + + static int cxgb4_set_hash_filter(struct net_device *dev, +@@ -2042,6 +2037,20 @@ void hash_filter_rpl(struct adapter *ada + } + return; + } ++ switch (f->fs.action) { ++ case FILTER_PASS: ++ if (f->fs.dirsteer) ++ set_tcb_tflag(adap, f, tid, ++ TF_DIRECT_STEER_S, 1, 1); ++ break; ++ case FILTER_DROP: ++ set_tcb_tflag(adap, f, tid, TF_DROP_S, 1, 1); ++ break; ++ case FILTER_SWITCH: ++ set_tcb_tflag(adap, f, tid, TF_LPBK_S, 1, 1); ++ break; ++ } ++ + break; + + default: +@@ -2109,22 +2118,11 @@ void filter_rpl(struct adapter *adap, co + if (ctx) + ctx->result = 0; + } else if (ret == FW_FILTER_WR_FLT_ADDED) { +- int err = 0; +- +- if (f->fs.newsmac) +- err = configure_filter_smac(adap, f); +- +- if (!err) { +- f->pending = 0; /* async setup completed */ +- f->valid = 1; +- if (ctx) { +- ctx->result = 0; +- ctx->tid = idx; +- } +- } else { +- clear_filter(adap, f); +- if (ctx) +- ctx->result = err; ++ f->pending = 0; /* async setup completed */ ++ f->valid = 1; ++ if (ctx) { ++ ctx->result = 0; ++ ctx->tid = idx; + } + } else { + /* Something went wrong. Issue a warning about the +--- a/drivers/net/ethernet/chelsio/cxgb4/t4_tcb.h ++++ b/drivers/net/ethernet/chelsio/cxgb4/t4_tcb.h +@@ -50,6 +50,10 @@ + #define TCB_T_FLAGS_M 0xffffffffffffffffULL + #define TCB_T_FLAGS_V(x) ((__u64)(x) << TCB_T_FLAGS_S) + ++#define TF_DROP_S 22 ++#define TF_DIRECT_STEER_S 23 ++#define TF_LPBK_S 59 ++ + #define TF_CCTRL_ECE_S 60 + #define TF_CCTRL_CWR_S 61 + #define TF_CCTRL_RFR_S 62 diff --git a/queue-5.9/gtp-fix-an-use-before-init-in-gtp_newlink.patch b/queue-5.9/gtp-fix-an-use-before-init-in-gtp_newlink.patch new file mode 100644 index 00000000000..388eff6e010 --- /dev/null +++ b/queue-5.9/gtp-fix-an-use-before-init-in-gtp_newlink.patch @@ -0,0 +1,86 @@ +From foo@baz Sat Oct 31 09:05:46 AM CET 2020 +From: Masahiro Fujiwara +Date: Tue, 27 Oct 2020 20:48:46 +0900 +Subject: [PATCH stable 5.9 10/25] gtp: fix an use-before-init in gtp_newlink() + +From: Masahiro Fujiwara + +[ Upstream commit 51467431200b91682b89d31317e35dcbca1469ce ] + +*_pdp_find() from gtp_encap_recv() would trigger a crash when a peer +sends GTP packets while creating new GTP device. + +RIP: 0010:gtp1_pdp_find.isra.0+0x68/0x90 [gtp] + +Call Trace: + + gtp_encap_recv+0xc2/0x2e0 [gtp] + ? gtp1_pdp_find.isra.0+0x90/0x90 [gtp] + udp_queue_rcv_one_skb+0x1fe/0x530 + udp_queue_rcv_skb+0x40/0x1b0 + udp_unicast_rcv_skb.isra.0+0x78/0x90 + __udp4_lib_rcv+0x5af/0xc70 + udp_rcv+0x1a/0x20 + ip_protocol_deliver_rcu+0xc5/0x1b0 + ip_local_deliver_finish+0x48/0x50 + ip_local_deliver+0xe5/0xf0 + ? ip_protocol_deliver_rcu+0x1b0/0x1b0 + +gtp_encap_enable() should be called after gtp_hastable_new() otherwise +*_pdp_find() will access the uninitialized hash table. + +Fixes: 1e3a3abd8b28 ("gtp: make GTP sockets in gtp_newlink optional") +Signed-off-by: Masahiro Fujiwara +Link: https://lore.kernel.org/r/20201027114846.3924-1-fujiwara.masahiro@gmail.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/gtp.c | 16 ++++++++-------- + 1 file changed, 8 insertions(+), 8 deletions(-) + +--- a/drivers/net/gtp.c ++++ b/drivers/net/gtp.c +@@ -663,10 +663,6 @@ static int gtp_newlink(struct net *src_n + + gtp = netdev_priv(dev); + +- err = gtp_encap_enable(gtp, data); +- if (err < 0) +- return err; +- + if (!data[IFLA_GTP_PDP_HASHSIZE]) { + hashsize = 1024; + } else { +@@ -677,12 +673,16 @@ static int gtp_newlink(struct net *src_n + + err = gtp_hashtable_new(gtp, hashsize); + if (err < 0) +- goto out_encap; ++ return err; ++ ++ err = gtp_encap_enable(gtp, data); ++ if (err < 0) ++ goto out_hashtable; + + err = register_netdevice(dev); + if (err < 0) { + netdev_dbg(dev, "failed to register new netdev %d\n", err); +- goto out_hashtable; ++ goto out_encap; + } + + gn = net_generic(dev_net(dev), gtp_net_id); +@@ -693,11 +693,11 @@ static int gtp_newlink(struct net *src_n + + return 0; + ++out_encap: ++ gtp_encap_disable(gtp); + out_hashtable: + kfree(gtp->addr_hash); + kfree(gtp->tid_hash); +-out_encap: +- gtp_encap_disable(gtp); + return err; + } + diff --git a/queue-5.9/ibmveth-fix-use-of-ibmveth-in-a-bridge.patch b/queue-5.9/ibmveth-fix-use-of-ibmveth-in-a-bridge.patch new file mode 100644 index 00000000000..7e21cdaaa43 --- /dev/null +++ b/queue-5.9/ibmveth-fix-use-of-ibmveth-in-a-bridge.patch @@ -0,0 +1,39 @@ +From foo@baz Sat Oct 31 09:05:46 AM CET 2020 +From: Thomas Bogendoerfer +Date: Mon, 26 Oct 2020 11:42:21 +0100 +Subject: [PATCH stable 5.9 11/25] ibmveth: Fix use of ibmveth in a bridge. + +From: Thomas Bogendoerfer + +[ Upstream commit 2ac8af0967aaa2b67cb382727e784900d2f4d0da ] + +The check for src mac address in ibmveth_is_packet_unsupported is wrong. +Commit 6f2275433a2f wanted to shut down messages for loopback packets, +but now suppresses bridged frames, which are accepted by the hypervisor +otherwise bridging won't work at all. + +Fixes: 6f2275433a2f ("ibmveth: Detect unsupported packets before sending to the hypervisor") +Signed-off-by: Michal Suchanek +Signed-off-by: Thomas Bogendoerfer +Link: https://lore.kernel.org/r/20201026104221.26570-1-msuchanek@suse.de +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/ibm/ibmveth.c | 6 ------ + 1 file changed, 6 deletions(-) + +--- a/drivers/net/ethernet/ibm/ibmveth.c ++++ b/drivers/net/ethernet/ibm/ibmveth.c +@@ -1031,12 +1031,6 @@ static int ibmveth_is_packet_unsupported + ret = -EOPNOTSUPP; + } + +- if (!ether_addr_equal(ether_header->h_source, netdev->dev_addr)) { +- netdev_dbg(netdev, "source packet MAC address does not match veth device's, dropping packet.\n"); +- netdev->stats.tx_dropped++; +- ret = -EOPNOTSUPP; +- } +- + return ret; + } + diff --git a/queue-5.9/ibmvnic-fix-ibmvnic_set_mac.patch b/queue-5.9/ibmvnic-fix-ibmvnic_set_mac.patch new file mode 100644 index 00000000000..14c9c897abd --- /dev/null +++ b/queue-5.9/ibmvnic-fix-ibmvnic_set_mac.patch @@ -0,0 +1,50 @@ +From foo@baz Sat Oct 31 09:05:46 AM CET 2020 +From: Lijun Pan +Date: Tue, 27 Oct 2020 17:04:56 -0500 +Subject: [PATCH stable 5.9 12/25] ibmvnic: fix ibmvnic_set_mac + +From: Lijun Pan + +[ Upstream commit 8fc3672a8ad3e782bac80e979bc2a2c10960cbe9 ] + +Jakub Kicinski brought up a concern in ibmvnic_set_mac(). +ibmvnic_set_mac() does this: + + ether_addr_copy(adapter->mac_addr, addr->sa_data); + if (adapter->state != VNIC_PROBED) + rc = __ibmvnic_set_mac(netdev, addr->sa_data); + +So if state == VNIC_PROBED, the user can assign an invalid address to +adapter->mac_addr, and ibmvnic_set_mac() will still return 0. + +The fix is to validate ethernet address at the beginning of +ibmvnic_set_mac(), and move the ether_addr_copy to +the case of "adapter->state != VNIC_PROBED". + +Fixes: c26eba03e407 ("ibmvnic: Update reset infrastructure to support tunable parameters") +Signed-off-by: Lijun Pan +Link: https://lore.kernel.org/r/20201027220456.71450-1-ljp@linux.ibm.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/ibm/ibmvnic.c | 8 ++++++-- + 1 file changed, 6 insertions(+), 2 deletions(-) + +--- a/drivers/net/ethernet/ibm/ibmvnic.c ++++ b/drivers/net/ethernet/ibm/ibmvnic.c +@@ -1828,9 +1828,13 @@ static int ibmvnic_set_mac(struct net_de + int rc; + + rc = 0; +- ether_addr_copy(adapter->mac_addr, addr->sa_data); +- if (adapter->state != VNIC_PROBED) ++ if (!is_valid_ether_addr(addr->sa_data)) ++ return -EADDRNOTAVAIL; ++ ++ if (adapter->state != VNIC_PROBED) { ++ ether_addr_copy(adapter->mac_addr, addr->sa_data); + rc = __ibmvnic_set_mac(netdev, addr->sa_data); ++ } + + return rc; + } diff --git a/queue-5.9/mlxsw-core-fix-memory-leak-on-module-removal.patch b/queue-5.9/mlxsw-core-fix-memory-leak-on-module-removal.patch new file mode 100644 index 00000000000..e66c409d77a --- /dev/null +++ b/queue-5.9/mlxsw-core-fix-memory-leak-on-module-removal.patch @@ -0,0 +1,56 @@ +From foo@baz Sat Oct 31 09:05:46 AM CET 2020 +From: Ido Schimmel +Date: Sat, 24 Oct 2020 16:37:32 +0300 +Subject: [PATCH stable 5.9 13/25] mlxsw: core: Fix memory leak on module removal + +From: Ido Schimmel + +[ Upstream commit adc80b6cfedff6dad8b93d46a5ea2775fd5af9ec ] + +Free the devlink instance during the teardown sequence in the non-reload +case to avoid the following memory leak. + +unreferenced object 0xffff888232895000 (size 2048): + comm "modprobe", pid 1073, jiffies 4295568857 (age 164.871s) + hex dump (first 32 bytes): + 00 01 00 00 00 00 ad de 22 01 00 00 00 00 ad de ........"....... + 10 50 89 32 82 88 ff ff 10 50 89 32 82 88 ff ff .P.2.....P.2.... + backtrace: + [<00000000c704e9a6>] __kmalloc+0x13a/0x2a0 + [<00000000ee30129d>] devlink_alloc+0xff/0x760 + [<0000000092ab3e5d>] 0xffffffffa042e5b0 + [<000000004f3f8a31>] 0xffffffffa042f6ad + [<0000000092800b4b>] 0xffffffffa0491df3 + [<00000000c4843903>] local_pci_probe+0xcb/0x170 + [<000000006993ded7>] pci_device_probe+0x2c2/0x4e0 + [<00000000a8e0de75>] really_probe+0x2c5/0xf90 + [<00000000d42ba75d>] driver_probe_device+0x1eb/0x340 + [<00000000bcc95e05>] device_driver_attach+0x294/0x300 + [<000000000e2bc177>] __driver_attach+0x167/0x2f0 + [<000000007d44cd6e>] bus_for_each_dev+0x148/0x1f0 + [<000000003cd5a91e>] driver_attach+0x45/0x60 + [<000000000041ce51>] bus_add_driver+0x3b8/0x720 + [<00000000f5215476>] driver_register+0x230/0x4e0 + [<00000000d79356f5>] __pci_register_driver+0x190/0x200 + +Fixes: a22712a96291 ("mlxsw: core: Fix devlink unregister flow") +Signed-off-by: Ido Schimmel +Reported-by: Vadim Pasternak +Tested-by: Oleksandr Shamray +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/mellanox/mlxsw/core.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/net/ethernet/mellanox/mlxsw/core.c ++++ b/drivers/net/ethernet/mellanox/mlxsw/core.c +@@ -1485,6 +1485,8 @@ void mlxsw_core_bus_device_unregister(st + if (!reload) + devlink_resources_unregister(devlink, NULL); + mlxsw_core->bus->fini(mlxsw_core->bus_priv); ++ if (!reload) ++ devlink_free(devlink); + + return; + diff --git a/queue-5.9/mlxsw-only-advertise-link-modes-supported-by-both-driver-and-device.patch b/queue-5.9/mlxsw-only-advertise-link-modes-supported-by-both-driver-and-device.patch new file mode 100644 index 00000000000..7ec1f839036 --- /dev/null +++ b/queue-5.9/mlxsw-only-advertise-link-modes-supported-by-both-driver-and-device.patch @@ -0,0 +1,141 @@ +From foo@baz Sat Oct 31 09:05:46 AM CET 2020 +From: Amit Cohen +Date: Sat, 24 Oct 2020 16:37:31 +0300 +Subject: [PATCH stable 5.9 14/25] mlxsw: Only advertise link modes supported by both driver and device + +From: Amit Cohen + +[ Upstream commit 1601559be3e4213148b4cb4a1abe672b00bf4f67 ] + +During port creation the driver instructs the device to advertise all +the supported link modes queried from the device. + +Since cited commit not all the link modes supported by the device are +supported by the driver. This can result in the device negotiating a +link mode that is not recognized by the driver causing ethtool to show +an unsupported speed: + +$ ethtool swp1 +... +Speed: Unknown! + +This is especially problematic when the netdev is enslaved to a bond, as +the bond driver uses unknown speed as an indication that the link is +down: + +[13048.900895] net_ratelimit: 86 callbacks suppressed +[13048.900902] t_bond0: (slave swp52): failed to get link speed/duplex +[13048.912160] t_bond0: (slave swp49): failed to get link speed/duplex + +Fix this by making sure that only link modes that are supported by both +the device and the driver are advertised. + +Fixes: b97cd891268d ("mlxsw: Remove 56G speed support") +Signed-off-by: Amit Cohen +Signed-off-by: Ido Schimmel +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 9 +++-- + drivers/net/ethernet/mellanox/mlxsw/spectrum.h | 1 + drivers/net/ethernet/mellanox/mlxsw/spectrum_ethtool.c | 30 +++++++++++++++++ + 3 files changed, 38 insertions(+), 2 deletions(-) + +--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c ++++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c +@@ -1546,11 +1546,14 @@ mlxsw_sp_port_speed_by_width_set(struct + u32 eth_proto_cap, eth_proto_admin, eth_proto_oper; + const struct mlxsw_sp_port_type_speed_ops *ops; + char ptys_pl[MLXSW_REG_PTYS_LEN]; ++ u32 eth_proto_cap_masked; + int err; + + ops = mlxsw_sp->port_type_speed_ops; + +- /* Set advertised speeds to supported speeds. */ ++ /* Set advertised speeds to speeds supported by both the driver ++ * and the device. ++ */ + ops->reg_ptys_eth_pack(mlxsw_sp, ptys_pl, mlxsw_sp_port->local_port, + 0, false); + err = mlxsw_reg_query(mlxsw_sp->core, MLXSW_REG(ptys), ptys_pl); +@@ -1559,8 +1562,10 @@ mlxsw_sp_port_speed_by_width_set(struct + + ops->reg_ptys_eth_unpack(mlxsw_sp, ptys_pl, ð_proto_cap, + ð_proto_admin, ð_proto_oper); ++ eth_proto_cap_masked = ops->ptys_proto_cap_masked_get(eth_proto_cap); + ops->reg_ptys_eth_pack(mlxsw_sp, ptys_pl, mlxsw_sp_port->local_port, +- eth_proto_cap, mlxsw_sp_port->link.autoneg); ++ eth_proto_cap_masked, ++ mlxsw_sp_port->link.autoneg); + return mlxsw_reg_write(mlxsw_sp->core, MLXSW_REG(ptys), ptys_pl); + } + +--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.h ++++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.h +@@ -340,6 +340,7 @@ struct mlxsw_sp_port_type_speed_ops { + u32 *p_eth_proto_cap, + u32 *p_eth_proto_admin, + u32 *p_eth_proto_oper); ++ u32 (*ptys_proto_cap_masked_get)(u32 eth_proto_cap); + }; + + static inline struct net_device * +--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_ethtool.c ++++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_ethtool.c +@@ -1208,6 +1208,20 @@ mlxsw_sp1_reg_ptys_eth_unpack(struct mlx + p_eth_proto_oper); + } + ++static u32 mlxsw_sp1_ptys_proto_cap_masked_get(u32 eth_proto_cap) ++{ ++ u32 ptys_proto_cap_masked = 0; ++ int i; ++ ++ for (i = 0; i < MLXSW_SP1_PORT_LINK_MODE_LEN; i++) { ++ if (mlxsw_sp1_port_link_mode[i].mask & eth_proto_cap) ++ ptys_proto_cap_masked |= ++ mlxsw_sp1_port_link_mode[i].mask; ++ } ++ ++ return ptys_proto_cap_masked; ++} ++ + const struct mlxsw_sp_port_type_speed_ops mlxsw_sp1_port_type_speed_ops = { + .from_ptys_supported_port = mlxsw_sp1_from_ptys_supported_port, + .from_ptys_link = mlxsw_sp1_from_ptys_link, +@@ -1217,6 +1231,7 @@ const struct mlxsw_sp_port_type_speed_op + .to_ptys_speed = mlxsw_sp1_to_ptys_speed, + .reg_ptys_eth_pack = mlxsw_sp1_reg_ptys_eth_pack, + .reg_ptys_eth_unpack = mlxsw_sp1_reg_ptys_eth_unpack, ++ .ptys_proto_cap_masked_get = mlxsw_sp1_ptys_proto_cap_masked_get, + }; + + static const enum ethtool_link_mode_bit_indices +@@ -1632,6 +1647,20 @@ mlxsw_sp2_reg_ptys_eth_unpack(struct mlx + p_eth_proto_admin, p_eth_proto_oper); + } + ++static u32 mlxsw_sp2_ptys_proto_cap_masked_get(u32 eth_proto_cap) ++{ ++ u32 ptys_proto_cap_masked = 0; ++ int i; ++ ++ for (i = 0; i < MLXSW_SP2_PORT_LINK_MODE_LEN; i++) { ++ if (mlxsw_sp2_port_link_mode[i].mask & eth_proto_cap) ++ ptys_proto_cap_masked |= ++ mlxsw_sp2_port_link_mode[i].mask; ++ } ++ ++ return ptys_proto_cap_masked; ++} ++ + const struct mlxsw_sp_port_type_speed_ops mlxsw_sp2_port_type_speed_ops = { + .from_ptys_supported_port = mlxsw_sp2_from_ptys_supported_port, + .from_ptys_link = mlxsw_sp2_from_ptys_link, +@@ -1641,4 +1670,5 @@ const struct mlxsw_sp_port_type_speed_op + .to_ptys_speed = mlxsw_sp2_to_ptys_speed, + .reg_ptys_eth_pack = mlxsw_sp2_reg_ptys_eth_pack, + .reg_ptys_eth_unpack = mlxsw_sp2_reg_ptys_eth_unpack, ++ .ptys_proto_cap_masked_get = mlxsw_sp2_ptys_proto_cap_masked_get, + }; diff --git a/queue-5.9/net-hns3-clear-the-cmdq-registers-before-unmapping-bar-region.patch b/queue-5.9/net-hns3-clear-the-cmdq-registers-before-unmapping-bar-region.patch new file mode 100644 index 00000000000..de53eeb16db --- /dev/null +++ b/queue-5.9/net-hns3-clear-the-cmdq-registers-before-unmapping-bar-region.patch @@ -0,0 +1,94 @@ +From foo@baz Sat Oct 31 09:05:46 AM CET 2020 +From: Zenghui Yu +Date: Fri, 23 Oct 2020 13:15:50 +0800 +Subject: [PATCH stable 5.9 16/25] net: hns3: Clear the CMDQ registers before unmapping BAR region + +From: Zenghui Yu + +[ Upstream commit e3364c5ff3ff975b943a7bf47e21a2a4bf20f3fe ] + +When unbinding the hns3 driver with the HNS3 VF, I got the following +kernel panic: + +[ 265.709989] Unable to handle kernel paging request at virtual address ffff800054627000 +[ 265.717928] Mem abort info: +[ 265.720740] ESR = 0x96000047 +[ 265.723810] EC = 0x25: DABT (current EL), IL = 32 bits +[ 265.729126] SET = 0, FnV = 0 +[ 265.732195] EA = 0, S1PTW = 0 +[ 265.735351] Data abort info: +[ 265.738227] ISV = 0, ISS = 0x00000047 +[ 265.742071] CM = 0, WnR = 1 +[ 265.745055] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000009b54000 +[ 265.751753] [ffff800054627000] pgd=0000202ffffff003, p4d=0000202ffffff003, pud=00002020020eb003, pmd=00000020a0dfc003, pte=0000000000000000 +[ 265.764314] Internal error: Oops: 96000047 [#1] SMP +[ 265.830357] CPU: 61 PID: 20319 Comm: bash Not tainted 5.9.0+ #206 +[ 265.836423] Hardware name: Huawei TaiShan 2280 V2/BC82AMDDA, BIOS 1.05 09/18/2019 +[ 265.843873] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO BTYPE=--) +[ 265.843890] pc : hclgevf_cmd_uninit+0xbc/0x300 +[ 265.861988] lr : hclgevf_cmd_uninit+0xb0/0x300 +[ 265.861992] sp : ffff80004c983b50 +[ 265.881411] pmr_save: 000000e0 +[ 265.884453] x29: ffff80004c983b50 x28: ffff20280bbce500 +[ 265.889744] x27: 0000000000000000 x26: 0000000000000000 +[ 265.895034] x25: ffff800011a1f000 x24: ffff800011a1fe90 +[ 265.900325] x23: ffff0020ce9b00d8 x22: ffff0020ce9b0150 +[ 265.905616] x21: ffff800010d70e90 x20: ffff800010d70e90 +[ 265.910906] x19: ffff0020ce9b0080 x18: 0000000000000004 +[ 265.916198] x17: 0000000000000000 x16: ffff800011ae32e8 +[ 265.916201] x15: 0000000000000028 x14: 0000000000000002 +[ 265.916204] x13: ffff800011ae32e8 x12: 0000000000012ad8 +[ 265.946619] x11: ffff80004c983b50 x10: 0000000000000000 +[ 265.951911] x9 : ffff8000115d0888 x8 : 0000000000000000 +[ 265.951914] x7 : ffff800011890b20 x6 : c0000000ffff7fff +[ 265.951917] x5 : ffff80004c983930 x4 : 0000000000000001 +[ 265.951919] x3 : ffffa027eec1b000 x2 : 2b78ccbbff369100 +[ 265.964487] x1 : 0000000000000000 x0 : ffff800054627000 +[ 265.964491] Call trace: +[ 265.964494] hclgevf_cmd_uninit+0xbc/0x300 +[ 265.964496] hclgevf_uninit_ae_dev+0x9c/0xe8 +[ 265.964501] hnae3_unregister_ae_dev+0xb0/0x130 +[ 265.964516] hns3_remove+0x34/0x88 [hns3] +[ 266.009683] pci_device_remove+0x48/0xf0 +[ 266.009692] device_release_driver_internal+0x114/0x1e8 +[ 266.030058] device_driver_detach+0x28/0x38 +[ 266.034224] unbind_store+0xd4/0x108 +[ 266.037784] drv_attr_store+0x40/0x58 +[ 266.041435] sysfs_kf_write+0x54/0x80 +[ 266.045081] kernfs_fop_write+0x12c/0x250 +[ 266.049076] vfs_write+0xc4/0x248 +[ 266.052378] ksys_write+0x74/0xf8 +[ 266.055677] __arm64_sys_write+0x24/0x30 +[ 266.059584] el0_svc_common.constprop.3+0x84/0x270 +[ 266.064354] do_el0_svc+0x34/0xa0 +[ 266.067658] el0_svc+0x38/0x40 +[ 266.070700] el0_sync_handler+0x8c/0xb0 +[ 266.074519] el0_sync+0x140/0x180 + +It looks like the BAR memory region had already been unmapped before we +start clearing CMDQ registers in it, which is pretty bad and the kernel +happily kills itself because of a Current EL Data Abort (on arm64). + +Moving the CMDQ uninitialization a bit early fixes the issue for me. + +Fixes: 862d969a3a4d ("net: hns3: do VF's pci re-initialization while PF doing FLR") +Signed-off-by: Zenghui Yu +Link: https://lore.kernel.org/r/20201023051550.793-1-yuzenghui@huawei.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c ++++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c +@@ -3146,8 +3146,8 @@ static void hclgevf_uninit_hdev(struct h + hclgevf_uninit_msi(hdev); + } + +- hclgevf_pci_uninit(hdev); + hclgevf_cmd_uninit(hdev); ++ hclgevf_pci_uninit(hdev); + hclgevf_uninit_mac_list(hdev); + } + diff --git a/queue-5.9/net-ipa-command-payloads-already-mapped.patch b/queue-5.9/net-ipa-command-payloads-already-mapped.patch new file mode 100644 index 00000000000..5015d5e057d --- /dev/null +++ b/queue-5.9/net-ipa-command-payloads-already-mapped.patch @@ -0,0 +1,84 @@ +From foo@baz Sat Oct 31 09:05:46 AM CET 2020 +From: Alex Elder +Date: Wed, 21 Oct 2020 20:00:29 -0500 +Subject: [PATCH stable 5.9 17/25] net: ipa: command payloads already mapped + +From: Alex Elder + +[ Upstream commit df833050cced27e1b343cc8bc41f90191b289334 ] + +IPA transactions describe actions to be performed by the IPA +hardware. Three cases use IPA transactions: transmitting a socket +buffer; providing a page to receive packet data; and issuing an IPA +immediate command. An IPA transaction contains a scatter/gather +list (SGL) to hold the set of actions to be performed. + +We map buffers in the SGL for DMA at the time they are added to the +transaction. For skb TX transactions, we fill the SGL with a call +to skb_to_sgvec(). Page RX transactions involve a single page +pointer, and that is recorded in the SGL with sg_set_page(). In +both of these cases we then map the SGL for DMA with a call to +dma_map_sg(). + +Immediate commands are different. The payload for an immediate +command comes from a region of coherent DMA memory, which must +*not* be mapped for DMA. For that reason, gsi_trans_cmd_add() +sort of hand-crafts each SGL entry added to a command transaction. + +This patch fixes a problem with the code that crafts the SGL entry +for an immediate command. Previously a portion of the SGL entry was +updated using sg_set_buf(). However this is not valid because it +includes a call to virt_to_page() on the buffer, but the command +buffer pointer is not a linear address. + +Since we never actually map the SGL for command transactions, there +are very few fields in the SGL we need to fill. Specifically, we +only need to record the DMA address and the length, so they can be +used by __gsi_trans_commit() to fill a TRE. We additionally need to +preserve the SGL flags so for_each_sg() still works. For that we +can simply assign a null page pointer for command SGL entries. + +Fixes: 9dd441e4ed575 ("soc: qcom: ipa: GSI transactions") +Reported-by: Stephen Boyd +Tested-by: Stephen Boyd +Signed-off-by: Alex Elder +Link: https://lore.kernel.org/r/20201022010029.11877-1-elder@linaro.org +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ipa/gsi_trans.c | 21 +++++++++++++++------ + 1 file changed, 15 insertions(+), 6 deletions(-) + +--- a/drivers/net/ipa/gsi_trans.c ++++ b/drivers/net/ipa/gsi_trans.c +@@ -398,15 +398,24 @@ void gsi_trans_cmd_add(struct gsi_trans + + /* assert(which < trans->tre_count); */ + +- /* Set the page information for the buffer. We also need to fill in +- * the DMA address and length for the buffer (something dma_map_sg() +- * normally does). ++ /* Commands are quite different from data transfer requests. ++ * Their payloads come from a pool whose memory is allocated ++ * using dma_alloc_coherent(). We therefore do *not* map them ++ * for DMA (unlike what we do for pages and skbs). ++ * ++ * When a transaction completes, the SGL is normally unmapped. ++ * A command transaction has direction DMA_NONE, which tells ++ * gsi_trans_complete() to skip the unmapping step. ++ * ++ * The only things we use directly in a command scatter/gather ++ * entry are the DMA address and length. We still need the SG ++ * table flags to be maintained though, so assign a NULL page ++ * pointer for that purpose. + */ + sg = &trans->sgl[which]; +- +- sg_set_buf(sg, buf, size); ++ sg_assign_page(sg, NULL); + sg_dma_address(sg) = addr; +- sg_dma_len(sg) = sg->length; ++ sg_dma_len(sg) = size; + + info = &trans->info[which]; + info->opcode = opcode; diff --git a/queue-5.9/net-protect-tcf_block_unbind-with-block-lock.patch b/queue-5.9/net-protect-tcf_block_unbind-with-block-lock.patch new file mode 100644 index 00000000000..c61877ae14d --- /dev/null +++ b/queue-5.9/net-protect-tcf_block_unbind-with-block-lock.patch @@ -0,0 +1,90 @@ +From foo@baz Sat Oct 31 09:05:46 AM CET 2020 +From: Leon Romanovsky +Date: Mon, 26 Oct 2020 14:33:27 +0200 +Subject: [PATCH stable 5.9 25/25] net: protect tcf_block_unbind with block lock + +From: Leon Romanovsky + +[ Upstream commit d6535dca28859d8d9ef80894eb287b2ac35a32e8 ] + +The tcf_block_unbind() expects that the caller will take block->cb_lock +before calling it, however the code took RTNL lock and dropped cb_lock +instead. This causes to the following kernel panic. + + WARNING: CPU: 1 PID: 13524 at net/sched/cls_api.c:1488 tcf_block_unbind+0x2db/0x420 + Modules linked in: mlx5_ib mlx5_core mlxfw ptp pps_core act_mirred act_tunnel_key cls_flower vxlan ip6_udp_tunnel udp_tunnel dummy sch_ingress openvswitch nsh xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad ib_ipoib rdma_cm iw_cm ib_cm ib_uverbs ib_core overlay [last unloaded: mlxfw] + CPU: 1 PID: 13524 Comm: test-ecmp-add-v Tainted: G W 5.9.0+ #1 + Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 + RIP: 0010:tcf_block_unbind+0x2db/0x420 + Code: ff 48 83 c4 40 5b 5d 41 5c 41 5d 41 5e 41 5f c3 49 8d bc 24 30 01 00 00 be ff ff ff ff e8 7d 7f 70 00 85 c0 0f 85 7b fd ff ff <0f> 0b e9 74 fd ff ff 48 c7 c7 dc 6a 24 84 e8 02 ec fe fe e9 55 fd + RSP: 0018:ffff888117d17968 EFLAGS: 00010246 + RAX: 0000000000000000 RBX: ffff88812f713c00 RCX: 1ffffffff0848d5b + RDX: 0000000000000001 RSI: ffff88814fbc8130 RDI: ffff888107f2b878 + RBP: 1ffff11022fa2f3f R08: 0000000000000000 R09: ffffffff84115a87 + R10: fffffbfff0822b50 R11: ffff888107f2b898 R12: ffff88814fbc8000 + R13: ffff88812f713c10 R14: ffff888117d17a38 R15: ffff88814fbc80c0 + FS: 00007f6593d36740(0000) GS:ffff8882a4f00000(0000) knlGS:0000000000000000 + CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 + CR2: 00005607a00758f8 CR3: 0000000131aea006 CR4: 0000000000170ea0 + Call Trace: + tc_block_indr_cleanup+0x3e0/0x5a0 + ? tcf_block_unbind+0x420/0x420 + ? __mutex_unlock_slowpath+0xe7/0x610 + flow_indr_dev_unregister+0x5e2/0x930 + ? mlx5e_restore_tunnel+0xdf0/0xdf0 [mlx5_core] + ? mlx5e_restore_tunnel+0xdf0/0xdf0 [mlx5_core] + ? flow_indr_block_cb_alloc+0x3c0/0x3c0 + ? mlx5_db_free+0x37c/0x4b0 [mlx5_core] + mlx5e_cleanup_rep_tx+0x8b/0xc0 [mlx5_core] + mlx5e_detach_netdev+0xe5/0x120 [mlx5_core] + mlx5e_vport_rep_unload+0x155/0x260 [mlx5_core] + esw_offloads_disable+0x227/0x2b0 [mlx5_core] + mlx5_eswitch_disable_locked.cold+0x38e/0x699 [mlx5_core] + mlx5_eswitch_disable+0x94/0xf0 [mlx5_core] + mlx5_device_disable_sriov+0x183/0x1f0 [mlx5_core] + mlx5_core_sriov_configure+0xfd/0x230 [mlx5_core] + sriov_numvfs_store+0x261/0x2f0 + ? sriov_drivers_autoprobe_store+0x110/0x110 + ? sysfs_file_ops+0x170/0x170 + ? sysfs_file_ops+0x117/0x170 + ? sysfs_file_ops+0x170/0x170 + kernfs_fop_write+0x1ff/0x3f0 + ? rcu_read_lock_any_held+0x6e/0x90 + vfs_write+0x1f3/0x620 + ksys_write+0xf9/0x1d0 + ? __x64_sys_read+0xb0/0xb0 + ? lockdep_hardirqs_on_prepare+0x273/0x3f0 + ? syscall_enter_from_user_mode+0x1d/0x50 + do_syscall_64+0x2d/0x40 + entry_SYSCALL_64_after_hwframe+0x44/0xa9 + +<...> + + ---[ end trace bfdd028ada702879 ]--- + +Fixes: 0fdcf78d5973 ("net: use flow_indr_dev_setup_offload()") +Signed-off-by: Leon Romanovsky +Link: https://lore.kernel.org/r/20201026123327.1141066-1-leon@kernel.org +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/sched/cls_api.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/net/sched/cls_api.c ++++ b/net/sched/cls_api.c +@@ -652,12 +652,12 @@ static void tc_block_indr_cleanup(struct + block_cb->indr.binder_type, + &block->flow_block, tcf_block_shared(block), + &extack); ++ rtnl_lock(); + down_write(&block->cb_lock); + list_del(&block_cb->driver_list); + list_move(&block_cb->list, &bo.cb_list); +- up_write(&block->cb_lock); +- rtnl_lock(); + tcf_block_unbind(block, &bo); ++ up_write(&block->cb_lock); + rtnl_unlock(); + } + diff --git a/queue-5.9/net-sched-act_mpls-add-softdep-on-mpls_gso.ko.patch b/queue-5.9/net-sched-act_mpls-add-softdep-on-mpls_gso.ko.patch new file mode 100644 index 00000000000..49e70a2ed9a --- /dev/null +++ b/queue-5.9/net-sched-act_mpls-add-softdep-on-mpls_gso.ko.patch @@ -0,0 +1,32 @@ +From foo@baz Sat Oct 31 09:05:46 AM CET 2020 +From: Guillaume Nault +Date: Mon, 26 Oct 2020 11:29:45 +0100 +Subject: [PATCH stable 5.9 18/25] net/sched: act_mpls: Add softdep on mpls_gso.ko + +From: Guillaume Nault + +TCA_MPLS_ACT_PUSH and TCA_MPLS_ACT_MAC_PUSH might be used on gso +packets. Such packets will thus require mpls_gso.ko for segmentation. + +v2: Drop dependency on CONFIG_NET_MPLS_GSO in Kconfig (from Jakub and + David). + +Fixes: 2a2ea50870ba ("net: sched: add mpls manipulation actions to TC") +Signed-off-by: Guillaume Nault +Link: https://lore.kernel.org/r/1f6cab15bbd15666795061c55563aaf6a386e90e.1603708007.git.gnault@redhat.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/sched/act_mpls.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/net/sched/act_mpls.c ++++ b/net/sched/act_mpls.c +@@ -408,6 +408,7 @@ static void __exit mpls_cleanup_module(v + module_init(mpls_init_module); + module_exit(mpls_cleanup_module); + ++MODULE_SOFTDEP("post: mpls_gso"); + MODULE_AUTHOR("Netronome Systems "); + MODULE_LICENSE("GPL"); + MODULE_DESCRIPTION("MPLS manipulation actions"); diff --git a/queue-5.9/net-smc-fix-invalid-return-code-in-smcd_new_buf_create.patch b/queue-5.9/net-smc-fix-invalid-return-code-in-smcd_new_buf_create.patch new file mode 100644 index 00000000000..fc88c327a9f --- /dev/null +++ b/queue-5.9/net-smc-fix-invalid-return-code-in-smcd_new_buf_create.patch @@ -0,0 +1,35 @@ +From foo@baz Sat Oct 31 09:05:46 AM CET 2020 +From: Karsten Graul +Date: Wed, 14 Oct 2020 19:43:29 +0200 +Subject: [PATCH stable 5.9 23/25] net/smc: fix invalid return code in smcd_new_buf_create() + +From: Karsten Graul + +[ Upstream commit 6b1bbf94ab369d97ed3bdaa561521a52c27ef619 ] + +smc_ism_register_dmb() returns error codes set by the ISM driver which +are not guaranteed to be negative or in the errno range. Such values +would not be handled by ERR_PTR() and finally the return code will be +used as a memory address. +Fix that by using a valid negative errno value with ERR_PTR(). + +Fixes: 72b7f6c48708 ("net/smc: unique reason code for exceeded max dmb count") +Signed-off-by: Karsten Graul +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/smc/smc_core.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/net/smc/smc_core.c ++++ b/net/smc/smc_core.c +@@ -1616,7 +1616,8 @@ static struct smc_buf_desc *smcd_new_buf + rc = smc_ism_register_dmb(lgr, bufsize, buf_desc); + if (rc) { + kfree(buf_desc); +- return (rc == -ENOMEM) ? ERR_PTR(-EAGAIN) : ERR_PTR(rc); ++ return (rc == -ENOMEM) ? ERR_PTR(-EAGAIN) : ++ ERR_PTR(-EIO); + } + buf_desc->pages = virt_to_page(buf_desc->cpu_addr); + /* CDC header stored in buf. So, pretend it was smaller */ diff --git a/queue-5.9/net-smc-fix-suppressed-return-code.patch b/queue-5.9/net-smc-fix-suppressed-return-code.patch new file mode 100644 index 00000000000..071813ce168 --- /dev/null +++ b/queue-5.9/net-smc-fix-suppressed-return-code.patch @@ -0,0 +1,38 @@ +From foo@baz Sat Oct 31 09:05:46 AM CET 2020 +From: Karsten Graul +Date: Fri, 23 Oct 2020 20:48:29 +0200 +Subject: [PATCH stable 5.9 24/25] net/smc: fix suppressed return code + +From: Karsten Graul + +[ Upstream commit 96d6fded958d971a3695009e0ed43aca6c598283 ] + +The patch that repaired the invalid return code in smcd_new_buf_create() +missed to take care of errno ENOSPC which has a special meaning that no +more DMBEs can be registered on the device. Fix that by keeping this +errno value during the translation of the return code. + +Fixes: 6b1bbf94ab36 ("net/smc: fix invalid return code in smcd_new_buf_create()") +Signed-off-by: Karsten Graul +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/smc/smc_core.c | 7 +++++-- + 1 file changed, 5 insertions(+), 2 deletions(-) + +--- a/net/smc/smc_core.c ++++ b/net/smc/smc_core.c +@@ -1616,8 +1616,11 @@ static struct smc_buf_desc *smcd_new_buf + rc = smc_ism_register_dmb(lgr, bufsize, buf_desc); + if (rc) { + kfree(buf_desc); +- return (rc == -ENOMEM) ? ERR_PTR(-EAGAIN) : +- ERR_PTR(-EIO); ++ if (rc == -ENOMEM) ++ return ERR_PTR(-EAGAIN); ++ if (rc == -ENOSPC) ++ return ERR_PTR(-ENOSPC); ++ return ERR_PTR(-EIO); + } + buf_desc->pages = virt_to_page(buf_desc->cpu_addr); + /* CDC header stored in buf. So, pretend it was smaller */ diff --git a/queue-5.9/netem-fix-zero-division-in-tabledist.patch b/queue-5.9/netem-fix-zero-division-in-tabledist.patch new file mode 100644 index 00000000000..8df31ea4883 --- /dev/null +++ b/queue-5.9/netem-fix-zero-division-in-tabledist.patch @@ -0,0 +1,70 @@ +From foo@baz Sat Oct 31 09:05:46 AM CET 2020 +From: Aleksandr Nogikh +Date: Wed, 28 Oct 2020 17:07:31 +0000 +Subject: [PATCH stable 5.9 15/25] netem: fix zero division in tabledist + +From: Aleksandr Nogikh + +[ Upstream commit eadd1befdd778a1eca57fad058782bd22b4db804 ] + +Currently it is possible to craft a special netlink RTM_NEWQDISC +command that can result in jitter being equal to 0x80000000. It is +enough to set the 32 bit jitter to 0x02000000 (it will later be +multiplied by 2^6) or just set the 64 bit jitter via +TCA_NETEM_JITTER64. This causes an overflow during the generation of +uniformly distributed numbers in tabledist(), which in turn leads to +division by zero (sigma != 0, but sigma * 2 is 0). + +The related fragment of code needs 32-bit division - see commit +9b0ed89 ("netem: remove unnecessary 64 bit modulus"), so switching to +64 bit is not an option. + +Fix the issue by keeping the value of jitter within the range that can +be adequately handled by tabledist() - [0;INT_MAX]. As negative std +deviation makes no sense, take the absolute value of the passed value +and cap it at INT_MAX. Inside tabledist(), switch to unsigned 32 bit +arithmetic in order to prevent overflows. + +Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") +Signed-off-by: Aleksandr Nogikh +Reported-by: syzbot+ec762a6342ad0d3c0d8f@syzkaller.appspotmail.com +Acked-by: Stephen Hemminger +Link: https://lore.kernel.org/r/20201028170731.1383332-1-aleksandrnogikh@gmail.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/sched/sch_netem.c | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +--- a/net/sched/sch_netem.c ++++ b/net/sched/sch_netem.c +@@ -330,7 +330,7 @@ static s64 tabledist(s64 mu, s32 sigma, + + /* default uniform distribution */ + if (dist == NULL) +- return ((rnd % (2 * sigma)) + mu) - sigma; ++ return ((rnd % (2 * (u32)sigma)) + mu) - sigma; + + t = dist->table[rnd % dist->size]; + x = (sigma % NETEM_DIST_SCALE) * t; +@@ -812,6 +812,10 @@ static void get_slot(struct netem_sched_ + q->slot_config.max_packets = INT_MAX; + if (q->slot_config.max_bytes == 0) + q->slot_config.max_bytes = INT_MAX; ++ ++ /* capping dist_jitter to the range acceptable by tabledist() */ ++ q->slot_config.dist_jitter = min_t(__s64, INT_MAX, abs(q->slot_config.dist_jitter)); ++ + q->slot.packets_left = q->slot_config.max_packets; + q->slot.bytes_left = q->slot_config.max_bytes; + if (q->slot_config.min_delay | q->slot_config.max_delay | +@@ -1037,6 +1041,9 @@ static int netem_change(struct Qdisc *sc + if (tb[TCA_NETEM_SLOT]) + get_slot(q, tb[TCA_NETEM_SLOT]); + ++ /* capping jitter to the range acceptable by tabledist() */ ++ q->jitter = min_t(s64, abs(q->jitter), INT_MAX); ++ + return ret; + + get_table_failure: diff --git a/queue-5.9/r8169-fix-issue-with-forced-threading-in-combination-with-shared-interrupts.patch b/queue-5.9/r8169-fix-issue-with-forced-threading-in-combination-with-shared-interrupts.patch new file mode 100644 index 00000000000..c76739838d4 --- /dev/null +++ b/queue-5.9/r8169-fix-issue-with-forced-threading-in-combination-with-shared-interrupts.patch @@ -0,0 +1,49 @@ +From foo@baz Sat Oct 31 09:05:46 AM CET 2020 +From: Heiner Kallweit +Date: Thu, 29 Oct 2020 10:18:53 +0100 +Subject: [PATCH stable 5.9 19/25] r8169: fix issue with forced threading in combination with shared interrupts + +From: Heiner Kallweit + +[ Upstream commit 2734a24e6e5d18522fbf599135c59b82ec9b2c9e ] + +As reported by Serge flag IRQF_NO_THREAD causes an error if the +interrupt is actually shared and the other driver(s) don't have this +flag set. This situation can occur if a PCI(e) legacy interrupt is +used in combination with forced threading. +There's no good way to deal with this properly, therefore we have to +remove flag IRQF_NO_THREAD. For fixing the original forced threading +issue switch to napi_schedule(). + +Fixes: 424a646e072a ("r8169: fix operation under forced interrupt threading") +Link: https://www.spinics.net/lists/netdev/msg694960.html +Reported-by: Serge Belyshev +Signed-off-by: Heiner Kallweit +Tested-by: Serge Belyshev +Link: https://lore.kernel.org/r/b5b53bfe-35ac-3768-85bf-74d1290cf394@gmail.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/realtek/r8169_main.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/net/ethernet/realtek/r8169_main.c ++++ b/drivers/net/ethernet/realtek/r8169_main.c +@@ -4563,7 +4563,7 @@ static irqreturn_t rtl8169_interrupt(int + } + + rtl_irq_disable(tp); +- napi_schedule_irqoff(&tp->napi); ++ napi_schedule(&tp->napi); + out: + rtl_ack_events(tp, status); + +@@ -4738,7 +4738,7 @@ static int rtl_open(struct net_device *d + rtl_request_firmware(tp); + + retval = request_irq(pci_irq_vector(pdev, 0), rtl8169_interrupt, +- IRQF_NO_THREAD | IRQF_SHARED, dev->name, tp); ++ IRQF_SHARED, dev->name, tp); + if (retval < 0) + goto err_release_fw_2; + diff --git a/queue-5.9/ravb-fix-bit-fields-checking-in-ravb_hwtstamp_get.patch b/queue-5.9/ravb-fix-bit-fields-checking-in-ravb_hwtstamp_get.patch new file mode 100644 index 00000000000..408fc5f20d0 --- /dev/null +++ b/queue-5.9/ravb-fix-bit-fields-checking-in-ravb_hwtstamp_get.patch @@ -0,0 +1,69 @@ +From foo@baz Sat Oct 31 09:05:46 AM CET 2020 +From: Andrew Gabbasov +Date: Mon, 26 Oct 2020 05:21:30 -0500 +Subject: [PATCH stable 5.9 20/25] ravb: Fix bit fields checking in ravb_hwtstamp_get() + +From: Andrew Gabbasov + +[ Upstream commit 68b9f0865b1ef545da180c57d54b82c94cb464a4 ] + +In the function ravb_hwtstamp_get() in ravb_main.c with the existing +values for RAVB_RXTSTAMP_TYPE_V2_L2_EVENT (0x2) and RAVB_RXTSTAMP_TYPE_ALL +(0x6) + +if (priv->tstamp_rx_ctrl & RAVB_RXTSTAMP_TYPE_V2_L2_EVENT) + config.rx_filter = HWTSTAMP_FILTER_PTP_V2_L2_EVENT; +else if (priv->tstamp_rx_ctrl & RAVB_RXTSTAMP_TYPE_ALL) + config.rx_filter = HWTSTAMP_FILTER_ALL; + +if the test on RAVB_RXTSTAMP_TYPE_ALL should be true, +it will never be reached. + +This issue can be verified with 'hwtstamp_config' testing program +(tools/testing/selftests/net/hwtstamp_config.c). Setting filter type +to ALL and subsequent retrieving it gives incorrect value: + +$ hwtstamp_config eth0 OFF ALL +flags = 0 +tx_type = OFF +rx_filter = ALL +$ hwtstamp_config eth0 +flags = 0 +tx_type = OFF +rx_filter = PTP_V2_L2_EVENT + +Correct this by converting if-else's to switch. + +Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper") +Reported-by: Julia Lawall +Signed-off-by: Andrew Gabbasov +Reviewed-by: Sergei Shtylyov +Link: https://lore.kernel.org/r/20201026102130.29368-1-andrew_gabbasov@mentor.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/renesas/ravb_main.c | 10 +++++++--- + 1 file changed, 7 insertions(+), 3 deletions(-) + +--- a/drivers/net/ethernet/renesas/ravb_main.c ++++ b/drivers/net/ethernet/renesas/ravb_main.c +@@ -1747,12 +1747,16 @@ static int ravb_hwtstamp_get(struct net_ + config.flags = 0; + config.tx_type = priv->tstamp_tx_ctrl ? HWTSTAMP_TX_ON : + HWTSTAMP_TX_OFF; +- if (priv->tstamp_rx_ctrl & RAVB_RXTSTAMP_TYPE_V2_L2_EVENT) ++ switch (priv->tstamp_rx_ctrl & RAVB_RXTSTAMP_TYPE) { ++ case RAVB_RXTSTAMP_TYPE_V2_L2_EVENT: + config.rx_filter = HWTSTAMP_FILTER_PTP_V2_L2_EVENT; +- else if (priv->tstamp_rx_ctrl & RAVB_RXTSTAMP_TYPE_ALL) ++ break; ++ case RAVB_RXTSTAMP_TYPE_ALL: + config.rx_filter = HWTSTAMP_FILTER_ALL; +- else ++ break; ++ default: + config.rx_filter = HWTSTAMP_FILTER_NONE; ++ } + + return copy_to_user(req->ifr_data, &config, sizeof(config)) ? + -EFAULT : 0; diff --git a/queue-5.9/series b/queue-5.9/series index 0366845bf4d..8a67c5b4db9 100644 --- a/queue-5.9/series +++ b/queue-5.9/series @@ -24,3 +24,28 @@ x86-pci-fix-intel_mid_pci.c-build-error-when-acpi-is-not-enabled.patch x86-powerpc-rename-memcpy_mcsafe-to-copy_mc_to_-user-kernel.patch x86-copy_mc-introduce-copy_mc_enhanced_fast_string.patch efivarfs-replace-invalid-slashes-with-exclamation-marks-in-dentries.patch +bnxt_en-check-abort-error-state-in-bnxt_open_nic.patch +bnxt_en-fix-regression-in-workqueue-cleanup-logic-in-bnxt_remove_one.patch +bnxt_en-invoke-cancel_delayed_work_sync-for-pfs-also.patch +bnxt_en-re-write-pci-bars-after-pci-fatal-error.patch +bnxt_en-send-hwrm_func_reset-fw-command-unconditionally.patch +chelsio-chtls-fix-deadlock-issue.patch +chelsio-chtls-fix-memory-leaks-in-cpl-handlers.patch +chelsio-chtls-fix-tls-record-info-to-user.patch +cxgb4-set-up-filter-action-after-rewrites.patch +gtp-fix-an-use-before-init-in-gtp_newlink.patch +ibmveth-fix-use-of-ibmveth-in-a-bridge.patch +ibmvnic-fix-ibmvnic_set_mac.patch +mlxsw-core-fix-memory-leak-on-module-removal.patch +mlxsw-only-advertise-link-modes-supported-by-both-driver-and-device.patch +netem-fix-zero-division-in-tabledist.patch +net-hns3-clear-the-cmdq-registers-before-unmapping-bar-region.patch +net-ipa-command-payloads-already-mapped.patch +net-sched-act_mpls-add-softdep-on-mpls_gso.ko.patch +r8169-fix-issue-with-forced-threading-in-combination-with-shared-interrupts.patch +ravb-fix-bit-fields-checking-in-ravb_hwtstamp_get.patch +tcp-prevent-low-rmem-stalls-with-so_rcvlowat.patch +tipc-fix-memory-leak-caused-by-tipc_buf_append.patch +net-smc-fix-invalid-return-code-in-smcd_new_buf_create.patch +net-smc-fix-suppressed-return-code.patch +net-protect-tcf_block_unbind-with-block-lock.patch diff --git a/queue-5.9/tcp-prevent-low-rmem-stalls-with-so_rcvlowat.patch b/queue-5.9/tcp-prevent-low-rmem-stalls-with-so_rcvlowat.patch new file mode 100644 index 00000000000..d5477c1d3ce --- /dev/null +++ b/queue-5.9/tcp-prevent-low-rmem-stalls-with-so_rcvlowat.patch @@ -0,0 +1,63 @@ +From foo@baz Sat Oct 31 09:05:46 AM CET 2020 +From: Arjun Roy +Date: Fri, 23 Oct 2020 11:47:09 -0700 +Subject: [PATCH stable 5.9 21/25] tcp: Prevent low rmem stalls with SO_RCVLOWAT. + +From: Arjun Roy + +[ Upstream commit 435ccfa894e35e3d4a1799e6ac030e48a7b69ef5 ] + +With SO_RCVLOWAT, under memory pressure, +it is possible to enter a state where: + +1. We have not received enough bytes to satisfy SO_RCVLOWAT. +2. We have not entered buffer pressure (see tcp_rmem_pressure()). +3. But, we do not have enough buffer space to accept more packets. + +In this case, we advertise 0 rwnd (due to #3) but the application does +not drain the receive queue (no wakeup because of #1 and #2) so the +flow stalls. + +Modify the heuristic for SO_RCVLOWAT so that, if we are advertising +rwnd<=rcv_mss, force a wakeup to prevent a stall. + +Without this patch, setting tcp_rmem to 6143 and disabling TCP +autotune causes a stalled flow. With this patch, no stall occurs. This +is with RPC-style traffic with large messages. + +Fixes: 03f45c883c6f ("tcp: avoid extra wakeups for SO_RCVLOWAT users") +Signed-off-by: Arjun Roy +Acked-by: Soheil Hassas Yeganeh +Acked-by: Neal Cardwell +Signed-off-by: Eric Dumazet +Link: https://lore.kernel.org/r/20201023184709.217614-1-arjunroy.kdev@gmail.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/ipv4/tcp.c | 2 ++ + net/ipv4/tcp_input.c | 3 ++- + 2 files changed, 4 insertions(+), 1 deletion(-) + +--- a/net/ipv4/tcp.c ++++ b/net/ipv4/tcp.c +@@ -483,6 +483,8 @@ static inline bool tcp_stream_is_readabl + return true; + if (tcp_rmem_pressure(sk)) + return true; ++ if (tcp_receive_window(tp) <= inet_csk(sk)->icsk_ack.rcv_mss) ++ return true; + } + if (sk->sk_prot->stream_memory_read) + return sk->sk_prot->stream_memory_read(sk); +--- a/net/ipv4/tcp_input.c ++++ b/net/ipv4/tcp_input.c +@@ -4840,7 +4840,8 @@ void tcp_data_ready(struct sock *sk) + int avail = tp->rcv_nxt - tp->copied_seq; + + if (avail < sk->sk_rcvlowat && !tcp_rmem_pressure(sk) && +- !sock_flag(sk, SOCK_DONE)) ++ !sock_flag(sk, SOCK_DONE) && ++ tcp_receive_window(tp) > inet_csk(sk)->icsk_ack.rcv_mss) + return; + + sk->sk_data_ready(sk); diff --git a/queue-5.9/tipc-fix-memory-leak-caused-by-tipc_buf_append.patch b/queue-5.9/tipc-fix-memory-leak-caused-by-tipc_buf_append.patch new file mode 100644 index 00000000000..d811f226f0e --- /dev/null +++ b/queue-5.9/tipc-fix-memory-leak-caused-by-tipc_buf_append.patch @@ -0,0 +1,72 @@ +From foo@baz Sat Oct 31 09:05:46 AM CET 2020 +From: Tung Nguyen +Date: Tue, 27 Oct 2020 10:24:03 +0700 +Subject: [PATCH stable 5.9 22/25] tipc: fix memory leak caused by tipc_buf_append() + +From: Tung Nguyen + +[ Upstream commit ceb1eb2fb609c88363e06618b8d4bbf7815a4e03 ] + +Commit ed42989eab57 ("tipc: fix the skb_unshare() in tipc_buf_append()") +replaced skb_unshare() with skb_copy() to not reduce the data reference +counter of the original skb intentionally. This is not the correct +way to handle the cloned skb because it causes memory leak in 2 +following cases: + 1/ Sending multicast messages via broadcast link + The original skb list is cloned to the local skb list for local + destination. After that, the data reference counter of each skb + in the original list has the value of 2. This causes each skb not + to be freed after receiving ACK: + tipc_link_advance_transmq() + { + ... + /* release skb */ + __skb_unlink(skb, &l->transmq); + kfree_skb(skb); <-- memory exists after being freed + } + + 2/ Sending multicast messages via replicast link + Similar to the above case, each skb cannot be freed after purging + the skb list: + tipc_mcast_xmit() + { + ... + __skb_queue_purge(pkts); <-- memory exists after being freed + } + +This commit fixes this issue by using skb_unshare() instead. Besides, +to avoid use-after-free error reported by KASAN, the pointer to the +fragment is set to NULL before calling skb_unshare() to make sure that +the original skb is not freed after freeing the fragment 2 times in +case skb_unshare() returns NULL. + +Fixes: ed42989eab57 ("tipc: fix the skb_unshare() in tipc_buf_append()") +Acked-by: Jon Maloy +Reported-by: Thang Hoang Ngo +Signed-off-by: Tung Nguyen +Reviewed-by: Xin Long +Acked-by: Cong Wang +Link: https://lore.kernel.org/r/20201027032403.1823-1-tung.q.nguyen@dektech.com.au +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/tipc/msg.c | 5 ++--- + 1 file changed, 2 insertions(+), 3 deletions(-) + +--- a/net/tipc/msg.c ++++ b/net/tipc/msg.c +@@ -150,12 +150,11 @@ int tipc_buf_append(struct sk_buff **hea + if (fragid == FIRST_FRAGMENT) { + if (unlikely(head)) + goto err; +- if (skb_cloned(frag)) +- frag = skb_copy(frag, GFP_ATOMIC); ++ *buf = NULL; ++ frag = skb_unshare(frag, GFP_ATOMIC); + if (unlikely(!frag)) + goto err; + head = *headbuf = frag; +- *buf = NULL; + TIPC_SKB_CB(head)->tail = NULL; + if (skb_is_nonlinear(head)) { + skb_walk_frags(head, tail) { -- 2.47.3