From: Greg Kroah-Hartman Date: Sat, 7 Oct 2023 12:44:03 +0000 (+0200) Subject: 6.5-stable patches X-Git-Tag: v4.14.327~54 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=85f3d6e78d4c940fd9c3bbe28ed8d66fe39d9752;p=thirdparty%2Fkernel%2Fstable-queue.git 6.5-stable patches added patches: arm64-add-cortex-a520-cpu-part-definition.patch arm64-errata-add-cortex-a520-speculative-unprivileged-load-workaround.patch bluetooth-hci_codec-fix-leaking-content-of-local_codecs.patch bluetooth-hci_sync-fix-handling-of-hci_quirk_strict_duplicate_filter.patch btrfs-always-print-transaction-aborted-messages-with-an-error-level.patch btrfs-reject-unknown-mount-options-early.patch drm-amd-fix-detection-of-_pr3-on-the-pcie-root-port.patch drm-amd-fix-logic-error-in-sienna_cichlid_update_pcie_parameters.patch drm-i915-don-t-set-pipe_control_flush_l3-for-aux-inval.patch io_uring-don-t-allow-ioring_setup_no_mmap-rings-on-highmem-pages.patch io_uring-ensure-io_lockdep_assert_cq_locked-handles-disabled-rings.patch io_uring-kbuf-don-t-allow-registered-buffer-rings-on-highmem-pages.patch iommu-apple-dart-handle-dma_fq-domains-in-attach_dev.patch iommu-vt-d-avoid-memory-allocation-in-iommu_suspend.patch md-raid5-release-batch_last-before-waiting-for-another-stripe_head.patch mptcp-fix-delegated-action-races.patch mptcp-userspace-pm-allow-creating-id-0-subflow.patch net-ethernet-mediatek-disable-irq-before-schedule-napi.patch net-mana-fix-the-tso_bytes-calculation.patch net-mana-fix-tx-cqe-error-handling.patch net-prevent-rewrite-of-msg_name-in-sock_sendmsg.patch net-replace-calls-to-sock-ops-connect-with-kernel_connect.patch pci-pm-mark-devices-disconnected-if-upstream-pcie-link-is-down-on-resume.patch pci-qcom-fix-ipq8074-enumeration.patch platform-x86-intel-ifs-release-cpus_read_lock.patch qed-red_ll2-fix-undefined-behavior-bug-in-struct-qed_ll2_info.patch scsi-zfcp-fix-a-double-put-in-zfcp_port_enqueue.patch vringh-don-t-use-vringh_kiov_advance-in-vringh_iov_xfer.patch wifi-brcmfmac-replace-1-element-arrays-with-flexible-arrays.patch wifi-mwifiex-fix-tlv_buf_left-calculation.patch wifi-rtw88-rtw8723d-fix-mac-address-offset-in-eeprom.patch --- diff --git a/queue-6.5/arm64-add-cortex-a520-cpu-part-definition.patch b/queue-6.5/arm64-add-cortex-a520-cpu-part-definition.patch new file mode 100644 index 00000000000..a9effac9100 --- /dev/null +++ b/queue-6.5/arm64-add-cortex-a520-cpu-part-definition.patch @@ -0,0 +1,38 @@ +From a654a69b9f9c06b2e56387d0b99f0e3e6b0ff4ef Mon Sep 17 00:00:00 2001 +From: Rob Herring +Date: Thu, 21 Sep 2023 14:41:51 -0500 +Subject: arm64: Add Cortex-A520 CPU part definition + +From: Rob Herring + +commit a654a69b9f9c06b2e56387d0b99f0e3e6b0ff4ef upstream. + +Add the CPU Part number for the new Arm design. + +Cc: stable@vger.kernel.org +Signed-off-by: Rob Herring +Link: https://lore.kernel.org/r/20230921194156.1050055-1-robh@kernel.org +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/include/asm/cputype.h | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/arch/arm64/include/asm/cputype.h ++++ b/arch/arm64/include/asm/cputype.h +@@ -79,6 +79,7 @@ + #define ARM_CPU_PART_CORTEX_A78AE 0xD42 + #define ARM_CPU_PART_CORTEX_X1 0xD44 + #define ARM_CPU_PART_CORTEX_A510 0xD46 ++#define ARM_CPU_PART_CORTEX_A520 0xD80 + #define ARM_CPU_PART_CORTEX_A710 0xD47 + #define ARM_CPU_PART_CORTEX_A715 0xD4D + #define ARM_CPU_PART_CORTEX_X2 0xD48 +@@ -148,6 +149,7 @@ + #define MIDR_CORTEX_A78AE MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A78AE) + #define MIDR_CORTEX_X1 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_X1) + #define MIDR_CORTEX_A510 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A510) ++#define MIDR_CORTEX_A520 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A520) + #define MIDR_CORTEX_A710 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A710) + #define MIDR_CORTEX_A715 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A715) + #define MIDR_CORTEX_X2 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_X2) diff --git a/queue-6.5/arm64-errata-add-cortex-a520-speculative-unprivileged-load-workaround.patch b/queue-6.5/arm64-errata-add-cortex-a520-speculative-unprivileged-load-workaround.patch new file mode 100644 index 00000000000..4e3f7de3331 --- /dev/null +++ b/queue-6.5/arm64-errata-add-cortex-a520-speculative-unprivileged-load-workaround.patch @@ -0,0 +1,111 @@ +From 471470bc7052d28ce125901877dd10e4c048e513 Mon Sep 17 00:00:00 2001 +From: Rob Herring +Date: Thu, 21 Sep 2023 14:41:52 -0500 +Subject: arm64: errata: Add Cortex-A520 speculative unprivileged load workaround + +From: Rob Herring + +commit 471470bc7052d28ce125901877dd10e4c048e513 upstream. + +Implement the workaround for ARM Cortex-A520 erratum 2966298. On an +affected Cortex-A520 core, a speculatively executed unprivileged load +might leak data from a privileged load via a cache side channel. The +issue only exists for loads within a translation regime with the same +translation (e.g. same ASID and VMID). Therefore, the issue only affects +the return to EL0. + +The workaround is to execute a TLBI before returning to EL0 after all +loads of privileged data. A non-shareable TLBI to any address is +sufficient. + +The workaround isn't necessary if page table isolation (KPTI) is +enabled, but for simplicity it will be. Page table isolation should +normally be disabled for Cortex-A520 as it supports the CSV3 feature +and the E0PD feature (used when KASLR is enabled). + +Cc: stable@vger.kernel.org +Signed-off-by: Rob Herring +Link: https://lore.kernel.org/r/20230921194156.1050055-2-robh@kernel.org +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman +--- + Documentation/arch/arm64/silicon-errata.rst | 2 ++ + arch/arm64/Kconfig | 13 +++++++++++++ + arch/arm64/kernel/cpu_errata.c | 8 ++++++++ + arch/arm64/kernel/entry.S | 4 ++++ + arch/arm64/tools/cpucaps | 1 + + 5 files changed, 28 insertions(+) + +--- a/Documentation/arch/arm64/silicon-errata.rst ++++ b/Documentation/arch/arm64/silicon-errata.rst +@@ -63,6 +63,8 @@ stable kernels. + +----------------+-----------------+-----------------+-----------------------------+ + | ARM | Cortex-A510 | #1902691 | ARM64_ERRATUM_1902691 | + +----------------+-----------------+-----------------+-----------------------------+ ++| ARM | Cortex-A520 | #2966298 | ARM64_ERRATUM_2966298 | +++----------------+-----------------+-----------------+-----------------------------+ + | ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 | + +----------------+-----------------+-----------------+-----------------------------+ + | ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 | +--- a/arch/arm64/Kconfig ++++ b/arch/arm64/Kconfig +@@ -1038,6 +1038,19 @@ config ARM64_ERRATUM_2645198 + + If unsure, say Y. + ++config ARM64_ERRATUM_2966298 ++ bool "Cortex-A520: 2966298: workaround for speculatively executed unprivileged load" ++ default y ++ help ++ This option adds the workaround for ARM Cortex-A520 erratum 2966298. ++ ++ On an affected Cortex-A520 core, a speculatively executed unprivileged ++ load might leak data from a privileged level via a cache side channel. ++ ++ Work around this problem by executing a TLBI before returning to EL0. ++ ++ If unsure, say Y. ++ + config CAVIUM_ERRATUM_22375 + bool "Cavium erratum 22375, 24313" + default y +--- a/arch/arm64/kernel/cpu_errata.c ++++ b/arch/arm64/kernel/cpu_errata.c +@@ -730,6 +730,14 @@ const struct arm64_cpu_capabilities arm6 + .cpu_enable = cpu_clear_bf16_from_user_emulation, + }, + #endif ++#ifdef CONFIG_ARM64_ERRATUM_2966298 ++ { ++ .desc = "ARM erratum 2966298", ++ .capability = ARM64_WORKAROUND_2966298, ++ /* Cortex-A520 r0p0 - r0p1 */ ++ ERRATA_MIDR_REV_RANGE(MIDR_CORTEX_A520, 0, 0, 1), ++ }, ++#endif + #ifdef CONFIG_AMPERE_ERRATUM_AC03_CPU_38 + { + .desc = "AmpereOne erratum AC03_CPU_38", +--- a/arch/arm64/kernel/entry.S ++++ b/arch/arm64/kernel/entry.S +@@ -428,6 +428,10 @@ alternative_else_nop_endif + ldp x28, x29, [sp, #16 * 14] + + .if \el == 0 ++alternative_if ARM64_WORKAROUND_2966298 ++ tlbi vale1, xzr ++ dsb nsh ++alternative_else_nop_endif + alternative_if_not ARM64_UNMAP_KERNEL_AT_EL0 + ldr lr, [sp, #S_LR] + add sp, sp, #PT_REGS_SIZE // restore sp +--- a/arch/arm64/tools/cpucaps ++++ b/arch/arm64/tools/cpucaps +@@ -83,6 +83,7 @@ WORKAROUND_2077057 + WORKAROUND_2457168 + WORKAROUND_2645198 + WORKAROUND_2658417 ++WORKAROUND_2966298 + WORKAROUND_AMPERE_AC03_CPU_38 + WORKAROUND_TRBE_OVERWRITE_FILL_MODE + WORKAROUND_TSB_FLUSH_FAILURE diff --git a/queue-6.5/bluetooth-hci_codec-fix-leaking-content-of-local_codecs.patch b/queue-6.5/bluetooth-hci_codec-fix-leaking-content-of-local_codecs.patch new file mode 100644 index 00000000000..63a91c8cf9a --- /dev/null +++ b/queue-6.5/bluetooth-hci_codec-fix-leaking-content-of-local_codecs.patch @@ -0,0 +1,72 @@ +From b938790e70540bf4f2e653dcd74b232494d06c8f Mon Sep 17 00:00:00 2001 +From: Luiz Augusto von Dentz +Date: Fri, 15 Sep 2023 13:24:47 -0700 +Subject: Bluetooth: hci_codec: Fix leaking content of local_codecs + +From: Luiz Augusto von Dentz + +commit b938790e70540bf4f2e653dcd74b232494d06c8f upstream. + +The following memory leak can be observed when the controller supports +codecs which are stored in local_codecs list but the elements are never +freed: + +unreferenced object 0xffff88800221d840 (size 32): + comm "kworker/u3:0", pid 36, jiffies 4294898739 (age 127.060s) + hex dump (first 32 bytes): + f8 d3 02 03 80 88 ff ff 80 d8 21 02 80 88 ff ff ..........!..... + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ + backtrace: + [] __kmalloc+0x47/0x120 + [] hci_codec_list_add.isra.0+0x2d/0x160 + [] hci_read_codec_capabilities+0x183/0x270 + [] hci_read_supported_codecs+0x1bb/0x2d0 + [] hci_read_local_codecs_sync+0x3e/0x60 + [] hci_dev_open_sync+0x943/0x11e0 + [] hci_power_on+0x10d/0x3f0 + [] process_one_work+0x404/0x800 + [] worker_thread+0x374/0x670 + [] kthread+0x188/0x1c0 + [] ret_from_fork+0x2b/0x50 + [] ret_from_fork_asm+0x1a/0x30 + +Cc: stable@vger.kernel.org +Fixes: 8961987f3f5f ("Bluetooth: Enumerate local supported codec and cache details") +Signed-off-by: Luiz Augusto von Dentz +Signed-off-by: Greg Kroah-Hartman +--- + net/bluetooth/hci_core.c | 1 + + net/bluetooth/hci_event.c | 1 + + net/bluetooth/hci_sync.c | 1 + + 3 files changed, 3 insertions(+) + +--- a/net/bluetooth/hci_core.c ++++ b/net/bluetooth/hci_core.c +@@ -2784,6 +2784,7 @@ void hci_release_dev(struct hci_dev *hde + hci_conn_params_clear_all(hdev); + hci_discovery_filter_clear(hdev); + hci_blocked_keys_clear(hdev); ++ hci_codec_list_clear(&hdev->local_codecs); + hci_dev_unlock(hdev); + + ida_simple_remove(&hci_index_ida, hdev->id); +--- a/net/bluetooth/hci_event.c ++++ b/net/bluetooth/hci_event.c +@@ -33,6 +33,7 @@ + + #include "hci_request.h" + #include "hci_debugfs.h" ++#include "hci_codec.h" + #include "a2mp.h" + #include "amp.h" + #include "smp.h" +--- a/net/bluetooth/hci_sync.c ++++ b/net/bluetooth/hci_sync.c +@@ -5095,6 +5095,7 @@ int hci_dev_close_sync(struct hci_dev *h + memset(hdev->eir, 0, sizeof(hdev->eir)); + memset(hdev->dev_class, 0, sizeof(hdev->dev_class)); + bacpy(&hdev->random_addr, BDADDR_ANY); ++ hci_codec_list_clear(&hdev->local_codecs); + + hci_dev_put(hdev); + return err; diff --git a/queue-6.5/bluetooth-hci_sync-fix-handling-of-hci_quirk_strict_duplicate_filter.patch b/queue-6.5/bluetooth-hci_sync-fix-handling-of-hci_quirk_strict_duplicate_filter.patch new file mode 100644 index 00000000000..ab52581a074 --- /dev/null +++ b/queue-6.5/bluetooth-hci_sync-fix-handling-of-hci_quirk_strict_duplicate_filter.patch @@ -0,0 +1,59 @@ +From 941c998b42f5c90384f49da89a6e11233de567cf Mon Sep 17 00:00:00 2001 +From: Luiz Augusto von Dentz +Date: Tue, 29 Aug 2023 13:50:06 -0700 +Subject: Bluetooth: hci_sync: Fix handling of HCI_QUIRK_STRICT_DUPLICATE_FILTER + +From: Luiz Augusto von Dentz + +commit 941c998b42f5c90384f49da89a6e11233de567cf upstream. + +When HCI_QUIRK_STRICT_DUPLICATE_FILTER is set LE scanning requires +periodic restarts of the scanning procedure as the controller would +consider device previously found as duplicated despite of RSSI changes, +but in order to set the scan timeout properly set le_scan_restart needs +to be synchronous so it shall not use hci_cmd_sync_queue which defers +the command processing to cmd_sync_work. + +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/linux-bluetooth/578e6d7afd676129decafba846a933f5@agner.ch/#t +Fixes: 27d54b778ad1 ("Bluetooth: Rework le_scan_restart for hci_sync") +Signed-off-by: Luiz Augusto von Dentz +Signed-off-by: Greg Kroah-Hartman +--- + net/bluetooth/hci_sync.c | 13 ++++--------- + 1 file changed, 4 insertions(+), 9 deletions(-) + +--- a/net/bluetooth/hci_sync.c ++++ b/net/bluetooth/hci_sync.c +@@ -412,11 +412,6 @@ static int hci_le_scan_restart_sync(stru + LE_SCAN_FILTER_DUP_ENABLE); + } + +-static int le_scan_restart_sync(struct hci_dev *hdev, void *data) +-{ +- return hci_le_scan_restart_sync(hdev); +-} +- + static void le_scan_restart(struct work_struct *work) + { + struct hci_dev *hdev = container_of(work, struct hci_dev, +@@ -426,15 +421,15 @@ static void le_scan_restart(struct work_ + + bt_dev_dbg(hdev, ""); + +- hci_dev_lock(hdev); +- +- status = hci_cmd_sync_queue(hdev, le_scan_restart_sync, NULL, NULL); ++ status = hci_le_scan_restart_sync(hdev); + if (status) { + bt_dev_err(hdev, "failed to restart LE scan: status %d", + status); +- goto unlock; ++ return; + } + ++ hci_dev_lock(hdev); ++ + if (!test_bit(HCI_QUIRK_STRICT_DUPLICATE_FILTER, &hdev->quirks) || + !hdev->discovery.scan_start) + goto unlock; diff --git a/queue-6.5/btrfs-always-print-transaction-aborted-messages-with-an-error-level.patch b/queue-6.5/btrfs-always-print-transaction-aborted-messages-with-an-error-level.patch new file mode 100644 index 00000000000..9660a5f8b9f --- /dev/null +++ b/queue-6.5/btrfs-always-print-transaction-aborted-messages-with-an-error-level.patch @@ -0,0 +1,48 @@ +From f8d1b011ca8c9d64ce32da431a8420635a96958a Mon Sep 17 00:00:00 2001 +From: Filipe Manana +Date: Tue, 26 Sep 2023 19:31:19 +0100 +Subject: btrfs: always print transaction aborted messages with an error level + +From: Filipe Manana + +commit f8d1b011ca8c9d64ce32da431a8420635a96958a upstream. + +Commit b7af0635c87f ("btrfs: print transaction aborted messages with an +error level") changed the log level of transaction aborted messages from +a debug level to an error level, so that such messages are always visible +even on production systems where the log level is normally above the debug +level (and also on some syzbot reports). + +Later, commit fccf0c842ed4 ("btrfs: move btrfs_abort_transaction to +transaction.c") changed the log level back to debug level when the error +number for a transaction abort should not have a stack trace printed. +This happened for absolutely no reason. It's always useful to print +transaction abort messages with an error level, regardless of whether +the error number should cause a stack trace or not. + +So change back the log level to error level. + +Fixes: fccf0c842ed4 ("btrfs: move btrfs_abort_transaction to transaction.c") +CC: stable@vger.kernel.org # 6.5+ +Reviewed-by: Qu Wenruo +Signed-off-by: Filipe Manana +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/transaction.h | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/fs/btrfs/transaction.h ++++ b/fs/btrfs/transaction.h +@@ -218,8 +218,8 @@ do { \ + (errno))) { \ + /* Stack trace printed. */ \ + } else { \ +- btrfs_debug((trans)->fs_info, \ +- "Transaction aborted (error %d)", \ ++ btrfs_err((trans)->fs_info, \ ++ "Transaction aborted (error %d)", \ + (errno)); \ + } \ + } \ diff --git a/queue-6.5/btrfs-reject-unknown-mount-options-early.patch b/queue-6.5/btrfs-reject-unknown-mount-options-early.patch new file mode 100644 index 00000000000..4062ae9a46d --- /dev/null +++ b/queue-6.5/btrfs-reject-unknown-mount-options-early.patch @@ -0,0 +1,55 @@ +From 5f521494cc73520ffac18ede0758883b9aedd018 Mon Sep 17 00:00:00 2001 +From: Qu Wenruo +Date: Wed, 27 Sep 2023 10:43:15 +0930 +Subject: btrfs: reject unknown mount options early + +From: Qu Wenruo + +commit 5f521494cc73520ffac18ede0758883b9aedd018 upstream. + +[BUG] +The following script would allow invalid mount options to be specified +(although such invalid options would just be ignored): + + # mkfs.btrfs -f $dev + # mount $dev $mnt1 <<< Successful mount expected + # mount $dev $mnt2 -o junk <<< Failed mount expected + # echo $? + 0 + +[CAUSE] +For the 2nd mount, since the fs is already mounted, we won't go through +open_ctree() thus no btrfs_parse_options(), but only through +btrfs_parse_subvol_options(). + +However we do not treat unrecognized options from valid but irrelevant +options, thus those invalid options would just be ignored by +btrfs_parse_subvol_options(). + +[FIX] +Add the handling for Opt_err to handle invalid options and error out, +while still ignore other valid options inside btrfs_parse_subvol_options(). + +Reported-by: Anand Jain +CC: stable@vger.kernel.org # 4.14+ +Signed-off-by: Qu Wenruo +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/super.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/fs/btrfs/super.c ++++ b/fs/btrfs/super.c +@@ -948,6 +948,10 @@ static int btrfs_parse_subvol_options(co + + *subvol_objectid = subvolid; + break; ++ case Opt_err: ++ btrfs_err(NULL, "unrecognized mount option '%s'", p); ++ error = -EINVAL; ++ goto out; + default: + break; + } diff --git a/queue-6.5/drm-amd-fix-detection-of-_pr3-on-the-pcie-root-port.patch b/queue-6.5/drm-amd-fix-detection-of-_pr3-on-the-pcie-root-port.patch new file mode 100644 index 00000000000..a4f5c1d325d --- /dev/null +++ b/queue-6.5/drm-amd-fix-detection-of-_pr3-on-the-pcie-root-port.patch @@ -0,0 +1,41 @@ +From 134b8c5d8674e7cde380f82e9aedfd46dcdd16f7 Mon Sep 17 00:00:00 2001 +From: Mario Limonciello +Date: Tue, 26 Sep 2023 17:59:53 -0500 +Subject: drm/amd: Fix detection of _PR3 on the PCIe root port + +From: Mario Limonciello + +commit 134b8c5d8674e7cde380f82e9aedfd46dcdd16f7 upstream. + +On some systems with Navi3x dGPU will attempt to use BACO for runtime +PM but fails to resume properly. This is because on these systems +the root port goes into D3cold which is incompatible with BACO. + +This happens because in this case dGPU is connected to a bridge between +root port which causes BOCO detection logic to fail. Fix the intent of +the logic by looking at root port, not the immediate upstream bridge for +_PR3. + +Cc: stable@vger.kernel.org +Suggested-by: Jun Ma +Tested-by: David Perry +Fixes: b10c1c5b3a4e ("drm/amdgpu: add check for ACPI power resources") +Signed-off-by: Mario Limonciello +Reviewed-by: Alex Deucher +Signed-off-by: Alex Deucher +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +@@ -2308,7 +2308,7 @@ static int amdgpu_device_ip_early_init(s + adev->flags |= AMD_IS_PX; + + if (!(adev->flags & AMD_IS_APU)) { +- parent = pci_upstream_bridge(adev->pdev); ++ parent = pcie_find_root_port(adev->pdev); + adev->has_pr3 = parent ? pci_pr3_present(parent) : false; + } + diff --git a/queue-6.5/drm-amd-fix-logic-error-in-sienna_cichlid_update_pcie_parameters.patch b/queue-6.5/drm-amd-fix-logic-error-in-sienna_cichlid_update_pcie_parameters.patch new file mode 100644 index 00000000000..bb1907ec1d0 --- /dev/null +++ b/queue-6.5/drm-amd-fix-logic-error-in-sienna_cichlid_update_pcie_parameters.patch @@ -0,0 +1,91 @@ +From 2a1fe39a5be785e962e387146aed34fa9a829f3f Mon Sep 17 00:00:00 2001 +From: Mario Limonciello +Date: Tue, 26 Sep 2023 21:07:43 -0500 +Subject: drm/amd: Fix logic error in sienna_cichlid_update_pcie_parameters() + +From: Mario Limonciello + +commit 2a1fe39a5be785e962e387146aed34fa9a829f3f upstream. + +While aligning SMU11 with SMU13 implementation an assumption was made that +`dpm_context->dpm_tables.pcie_table` was populated in dpm table initialization +like in SMU13 but it isn't. + +So restore some of the original logic and instead just check for +amdgpu_device_pcie_dynamic_switching_supported() to decide whether to hardcode +values; erring on the side of performance. + +Cc: stable@vger.kernel.org # 6.1+ +Reported-and-tested-by: Umio Yasuno +Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/1447#note_2101382 +Fixes: e701156ccc6c ("drm/amd: Align SMU11 SMU_MSG_OverridePcieParameters implementation with SMU13") +Signed-off-by: Mario Limonciello +Reviewed-by: Alex Deucher +Signed-off-by: Alex Deucher +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 41 ++++++++-------- + 1 file changed, 23 insertions(+), 18 deletions(-) + +--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c ++++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c +@@ -2081,36 +2081,41 @@ static int sienna_cichlid_display_disabl + return ret; + } + ++#define MAX(a, b) ((a) > (b) ? (a) : (b)) ++ + static int sienna_cichlid_update_pcie_parameters(struct smu_context *smu, + uint32_t pcie_gen_cap, + uint32_t pcie_width_cap) + { + struct smu_11_0_dpm_context *dpm_context = smu->smu_dpm.dpm_context; + struct smu_11_0_pcie_table *pcie_table = &dpm_context->dpm_tables.pcie_table; +- u32 smu_pcie_arg; ++ uint8_t *table_member1, *table_member2; ++ uint32_t min_gen_speed, max_gen_speed; ++ uint32_t min_lane_width, max_lane_width; ++ uint32_t smu_pcie_arg; + int ret, i; + +- /* PCIE gen speed and lane width override */ +- if (!amdgpu_device_pcie_dynamic_switching_supported()) { +- if (pcie_table->pcie_gen[NUM_LINK_LEVELS - 1] < pcie_gen_cap) +- pcie_gen_cap = pcie_table->pcie_gen[NUM_LINK_LEVELS - 1]; ++ GET_PPTABLE_MEMBER(PcieGenSpeed, &table_member1); ++ GET_PPTABLE_MEMBER(PcieLaneCount, &table_member2); + +- if (pcie_table->pcie_lane[NUM_LINK_LEVELS - 1] < pcie_width_cap) +- pcie_width_cap = pcie_table->pcie_lane[NUM_LINK_LEVELS - 1]; ++ min_gen_speed = MAX(0, table_member1[0]); ++ max_gen_speed = MIN(pcie_gen_cap, table_member1[1]); ++ min_gen_speed = min_gen_speed > max_gen_speed ? ++ max_gen_speed : min_gen_speed; ++ min_lane_width = MAX(1, table_member2[0]); ++ max_lane_width = MIN(pcie_width_cap, table_member2[1]); ++ min_lane_width = min_lane_width > max_lane_width ? ++ max_lane_width : min_lane_width; + +- /* Force all levels to use the same settings */ +- for (i = 0; i < NUM_LINK_LEVELS; i++) { +- pcie_table->pcie_gen[i] = pcie_gen_cap; +- pcie_table->pcie_lane[i] = pcie_width_cap; +- } ++ if (!amdgpu_device_pcie_dynamic_switching_supported()) { ++ pcie_table->pcie_gen[0] = max_gen_speed; ++ pcie_table->pcie_lane[0] = max_lane_width; + } else { +- for (i = 0; i < NUM_LINK_LEVELS; i++) { +- if (pcie_table->pcie_gen[i] > pcie_gen_cap) +- pcie_table->pcie_gen[i] = pcie_gen_cap; +- if (pcie_table->pcie_lane[i] > pcie_width_cap) +- pcie_table->pcie_lane[i] = pcie_width_cap; +- } ++ pcie_table->pcie_gen[0] = min_gen_speed; ++ pcie_table->pcie_lane[0] = min_lane_width; + } ++ pcie_table->pcie_gen[1] = max_gen_speed; ++ pcie_table->pcie_lane[1] = max_lane_width; + + for (i = 0; i < NUM_LINK_LEVELS; i++) { + smu_pcie_arg = (i << 16 | diff --git a/queue-6.5/drm-i915-don-t-set-pipe_control_flush_l3-for-aux-inval.patch b/queue-6.5/drm-i915-don-t-set-pipe_control_flush_l3-for-aux-inval.patch new file mode 100644 index 00000000000..194ef135b69 --- /dev/null +++ b/queue-6.5/drm-i915-don-t-set-pipe_control_flush_l3-for-aux-inval.patch @@ -0,0 +1,62 @@ +From 128c20eda73bd3e78505c574fb17adb46195c98b Mon Sep 17 00:00:00 2001 +From: Nirmoy Das +Date: Tue, 26 Sep 2023 16:24:01 +0200 +Subject: drm/i915: Don't set PIPE_CONTROL_FLUSH_L3 for aux inval +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Nirmoy Das + +commit 128c20eda73bd3e78505c574fb17adb46195c98b upstream. + +PIPE_CONTROL_FLUSH_L3 is not needed for aux invalidation +so don't set that. + +Fixes: 78a6ccd65fa3 ("drm/i915/gt: Ensure memory quiesced before invalidation") +Cc: Jonathan Cavitt +Cc: Andi Shyti +Cc: # v5.8+ +Cc: Andrzej Hajda +Cc: Tvrtko Ursulin +Cc: Matt Roper +Cc: Tejas Upadhyay +Cc: Lucas De Marchi +Cc: Prathap Kumar Valsan +Cc: Tapani Pälli +Cc: Mark Janes +Cc: Rodrigo Vivi +Signed-off-by: Nirmoy Das +Acked-by: Matt Roper +Reviewed-by: Andi Shyti +Tested-by: Tapani Pälli +Reviewed-by: Andrzej Hajda +Link: https://patchwork.freedesktop.org/patch/msgid/20230926142401.25687-1-nirmoy.das@intel.com +(cherry picked from commit 03d681412b38558aefe4fb0f46e36efa94bb21ef) +Signed-off-by: Rodrigo Vivi +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 11 ++++++++++- + 1 file changed, 10 insertions(+), 1 deletion(-) + +--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c ++++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c +@@ -271,8 +271,17 @@ int gen12_emit_flush_rcs(struct i915_req + if (GRAPHICS_VER_FULL(rq->i915) >= IP_VER(12, 70)) + bit_group_0 |= PIPE_CONTROL_CCS_FLUSH; + ++ /* ++ * L3 fabric flush is needed for AUX CCS invalidation ++ * which happens as part of pipe-control so we can ++ * ignore PIPE_CONTROL_FLUSH_L3. Also PIPE_CONTROL_FLUSH_L3 ++ * deals with Protected Memory which is not needed for ++ * AUX CCS invalidation and lead to unwanted side effects. ++ */ ++ if (mode & EMIT_FLUSH) ++ bit_group_1 |= PIPE_CONTROL_FLUSH_L3; ++ + bit_group_1 |= PIPE_CONTROL_TILE_CACHE_FLUSH; +- bit_group_1 |= PIPE_CONTROL_FLUSH_L3; + bit_group_1 |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH; + bit_group_1 |= PIPE_CONTROL_DEPTH_CACHE_FLUSH; + /* Wa_1409600907:tgl,adl-p */ diff --git a/queue-6.5/io_uring-don-t-allow-ioring_setup_no_mmap-rings-on-highmem-pages.patch b/queue-6.5/io_uring-don-t-allow-ioring_setup_no_mmap-rings-on-highmem-pages.patch new file mode 100644 index 00000000000..60609ca0caa --- /dev/null +++ b/queue-6.5/io_uring-don-t-allow-ioring_setup_no_mmap-rings-on-highmem-pages.patch @@ -0,0 +1,54 @@ +From 223ef474316466e9f61f6e0064f3a6fe4923a2c5 Mon Sep 17 00:00:00 2001 +From: Jens Axboe +Date: Tue, 3 Oct 2023 09:59:58 -0600 +Subject: io_uring: don't allow IORING_SETUP_NO_MMAP rings on highmem pages + +From: Jens Axboe + +commit 223ef474316466e9f61f6e0064f3a6fe4923a2c5 upstream. + +On at least arm32, but presumably any arch with highmem, if the +application passes in memory that resides in highmem for the rings, +then we should fail that ring creation. We fail it with -EINVAL, which +is what kernels that don't support IORING_SETUP_NO_MMAP will do as well. + +Cc: stable@vger.kernel.org +Fixes: 03d89a2de25b ("io_uring: support for user allocated memory for rings/sqes") +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + io_uring/io_uring.c | 16 +++++++++++++++- + 1 file changed, 15 insertions(+), 1 deletion(-) + +--- a/io_uring/io_uring.c ++++ b/io_uring/io_uring.c +@@ -2678,7 +2678,7 @@ static void *__io_uaddr_map(struct page + { + struct page **page_array; + unsigned int nr_pages; +- int ret; ++ int ret, i; + + *npages = 0; + +@@ -2708,6 +2708,20 @@ err: + */ + if (page_array[0] != page_array[ret - 1]) + goto err; ++ ++ /* ++ * Can't support mapping user allocated ring memory on 32-bit archs ++ * where it could potentially reside in highmem. Just fail those with ++ * -EINVAL, just like we did on kernels that didn't support this ++ * feature. ++ */ ++ for (i = 0; i < nr_pages; i++) { ++ if (PageHighMem(page_array[i])) { ++ ret = -EINVAL; ++ goto err; ++ } ++ } ++ + *pages = page_array; + *npages = nr_pages; + return page_to_virt(page_array[0]); diff --git a/queue-6.5/io_uring-ensure-io_lockdep_assert_cq_locked-handles-disabled-rings.patch b/queue-6.5/io_uring-ensure-io_lockdep_assert_cq_locked-handles-disabled-rings.patch new file mode 100644 index 00000000000..f6762e06547 --- /dev/null +++ b/queue-6.5/io_uring-ensure-io_lockdep_assert_cq_locked-handles-disabled-rings.patch @@ -0,0 +1,82 @@ +From 1658633c04653578429ff5dfc62fdc159203a8f2 Mon Sep 17 00:00:00 2001 +From: Jens Axboe +Date: Mon, 2 Oct 2023 19:51:38 -0600 +Subject: io_uring: ensure io_lockdep_assert_cq_locked() handles disabled rings + +From: Jens Axboe + +commit 1658633c04653578429ff5dfc62fdc159203a8f2 upstream. + +io_lockdep_assert_cq_locked() checks that locking is correctly done when +a CQE is posted. If the ring is setup in a disabled state with +IORING_SETUP_R_DISABLED, then ctx->submitter_task isn't assigned until +the ring is later enabled. We generally don't post CQEs in this state, +as no SQEs can be submitted. However it is possible to generate a CQE +if tagged resources are being updated. If this happens and PROVE_LOCKING +is enabled, then the locking check helper will dereference +ctx->submitter_task, which hasn't been set yet. + +Fixup io_lockdep_assert_cq_locked() to handle this case correctly. While +at it, convert it to a static inline as well, so that generated line +offsets will actually reflect which condition failed, rather than just +the line offset for io_lockdep_assert_cq_locked() itself. + +Reported-and-tested-by: syzbot+efc45d4e7ba6ab4ef1eb@syzkaller.appspotmail.com +Fixes: f26cc9593581 ("io_uring: lockdep annotate CQ locking") +Cc: stable@vger.kernel.org +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + io_uring/io_uring.h | 41 +++++++++++++++++++++++++++-------------- + 1 file changed, 27 insertions(+), 14 deletions(-) + +--- a/io_uring/io_uring.h ++++ b/io_uring/io_uring.h +@@ -87,20 +87,33 @@ bool __io_alloc_req_refill(struct io_rin + bool io_match_task_safe(struct io_kiocb *head, struct task_struct *task, + bool cancel_all); + +-#define io_lockdep_assert_cq_locked(ctx) \ +- do { \ +- lockdep_assert(in_task()); \ +- \ +- if (ctx->flags & IORING_SETUP_IOPOLL) { \ +- lockdep_assert_held(&ctx->uring_lock); \ +- } else if (!ctx->task_complete) { \ +- lockdep_assert_held(&ctx->completion_lock); \ +- } else if (ctx->submitter_task->flags & PF_EXITING) { \ +- lockdep_assert(current_work()); \ +- } else { \ +- lockdep_assert(current == ctx->submitter_task); \ +- } \ +- } while (0) ++#if defined(CONFIG_PROVE_LOCKING) ++static inline void io_lockdep_assert_cq_locked(struct io_ring_ctx *ctx) ++{ ++ lockdep_assert(in_task()); ++ ++ if (ctx->flags & IORING_SETUP_IOPOLL) { ++ lockdep_assert_held(&ctx->uring_lock); ++ } else if (!ctx->task_complete) { ++ lockdep_assert_held(&ctx->completion_lock); ++ } else if (ctx->submitter_task) { ++ /* ++ * ->submitter_task may be NULL and we can still post a CQE, ++ * if the ring has been setup with IORING_SETUP_R_DISABLED. ++ * Not from an SQE, as those cannot be submitted, but via ++ * updating tagged resources. ++ */ ++ if (ctx->submitter_task->flags & PF_EXITING) ++ lockdep_assert(current_work()); ++ else ++ lockdep_assert(current == ctx->submitter_task); ++ } ++} ++#else ++static inline void io_lockdep_assert_cq_locked(struct io_ring_ctx *ctx) ++{ ++} ++#endif + + static inline void io_req_task_work_add(struct io_kiocb *req) + { diff --git a/queue-6.5/io_uring-kbuf-don-t-allow-registered-buffer-rings-on-highmem-pages.patch b/queue-6.5/io_uring-kbuf-don-t-allow-registered-buffer-rings-on-highmem-pages.patch new file mode 100644 index 00000000000..28544f4bf7d --- /dev/null +++ b/queue-6.5/io_uring-kbuf-don-t-allow-registered-buffer-rings-on-highmem-pages.patch @@ -0,0 +1,88 @@ +From f8024f1f36a30a082b0457d5779c8847cea57f57 Mon Sep 17 00:00:00 2001 +From: Jens Axboe +Date: Mon, 2 Oct 2023 18:14:08 -0600 +Subject: io_uring/kbuf: don't allow registered buffer rings on highmem pages + +From: Jens Axboe + +commit f8024f1f36a30a082b0457d5779c8847cea57f57 upstream. + +syzbot reports that registering a mapped buffer ring on arm32 can +trigger an OOPS. Registered buffer rings have two modes, one of them +is the application passing in the memory that the buffer ring should +reside in. Once those pages are mapped, we use page_address() to get +a virtual address. This will obviously fail on highmem pages, which +aren't mapped. + +Add a check if we have any highmem pages after mapping, and fail the +attempt to register a provided buffer ring if we do. This will return +the same error as kernels that don't support provided buffer rings to +begin with. + +Link: https://lore.kernel.org/io-uring/000000000000af635c0606bcb889@google.com/ +Fixes: c56e022c0a27 ("io_uring: add support for user mapped provided buffer ring") +Cc: stable@vger.kernel.org +Reported-by: syzbot+2113e61b8848fa7951d8@syzkaller.appspotmail.com +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + io_uring/kbuf.c | 27 +++++++++++++++++++-------- + 1 file changed, 19 insertions(+), 8 deletions(-) + +--- a/io_uring/kbuf.c ++++ b/io_uring/kbuf.c +@@ -481,7 +481,7 @@ static int io_pin_pbuf_ring(struct io_ur + { + struct io_uring_buf_ring *br; + struct page **pages; +- int nr_pages; ++ int i, nr_pages; + + pages = io_pin_pages(reg->ring_addr, + flex_array_size(br, bufs, reg->ring_entries), +@@ -489,6 +489,17 @@ static int io_pin_pbuf_ring(struct io_ur + if (IS_ERR(pages)) + return PTR_ERR(pages); + ++ /* ++ * Apparently some 32-bit boxes (ARM) will return highmem pages, ++ * which then need to be mapped. We could support that, but it'd ++ * complicate the code and slowdown the common cases quite a bit. ++ * So just error out, returning -EINVAL just like we did on kernels ++ * that didn't support mapped buffer rings. ++ */ ++ for (i = 0; i < nr_pages; i++) ++ if (PageHighMem(pages[i])) ++ goto error_unpin; ++ + br = page_address(pages[0]); + #ifdef SHM_COLOUR + /* +@@ -500,13 +511,8 @@ static int io_pin_pbuf_ring(struct io_ur + * should use IOU_PBUF_RING_MMAP instead, and liburing will handle + * this transparently. + */ +- if ((reg->ring_addr | (unsigned long) br) & (SHM_COLOUR - 1)) { +- int i; +- +- for (i = 0; i < nr_pages; i++) +- unpin_user_page(pages[i]); +- return -EINVAL; +- } ++ if ((reg->ring_addr | (unsigned long) br) & (SHM_COLOUR - 1)) ++ goto error_unpin; + #endif + bl->buf_pages = pages; + bl->buf_nr_pages = nr_pages; +@@ -514,6 +520,11 @@ static int io_pin_pbuf_ring(struct io_ur + bl->is_mapped = 1; + bl->is_mmap = 0; + return 0; ++error_unpin: ++ for (i = 0; i < nr_pages; i++) ++ unpin_user_page(pages[i]); ++ kvfree(pages); ++ return -EINVAL; + } + + static int io_alloc_pbuf_ring(struct io_uring_buf_reg *reg, diff --git a/queue-6.5/iommu-apple-dart-handle-dma_fq-domains-in-attach_dev.patch b/queue-6.5/iommu-apple-dart-handle-dma_fq-domains-in-attach_dev.patch new file mode 100644 index 00000000000..b23bb1a1a37 --- /dev/null +++ b/queue-6.5/iommu-apple-dart-handle-dma_fq-domains-in-attach_dev.patch @@ -0,0 +1,52 @@ +From c7bd8a1f45bada7725d11266df7fd5cb549b3098 Mon Sep 17 00:00:00 2001 +From: Hector Martin +Date: Fri, 22 Sep 2023 23:55:23 +0900 +Subject: iommu/apple-dart: Handle DMA_FQ domains in attach_dev() + +From: Hector Martin + +commit c7bd8a1f45bada7725d11266df7fd5cb549b3098 upstream. + +Commit a4fdd9762272 ("iommu: Use flush queue capability") hid the +IOMMU_DOMAIN_DMA_FQ domain type from domain allocation. A check was +introduced in iommu_dma_init_domain() to fall back if not supported, but +this check runs too late: by that point, devices have been attached to +the IOMMU, and apple-dart's attach_dev() callback does not expect +IOMMU_DOMAIN_DMA_FQ domains. + +Change the logic so the IOMMU_DOMAIN_DMA codepath is the default, +instead of explicitly enumerating all types. + +Fixes an apple-dart regression in v6.5. + +Cc: regressions@lists.linux.dev +Cc: stable@vger.kernel.org +Suggested-by: Robin Murphy +Fixes: a4fdd9762272 ("iommu: Use flush queue capability") +Signed-off-by: Hector Martin +Reviewed-by: Neal Gompa +Reviewed-by: Jason Gunthorpe +Link: https://lore.kernel.org/r/20230922-iommu-type-regression-v2-1-689b2ba9b673@marcan.st +Signed-off-by: Joerg Roedel +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iommu/apple-dart.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +diff --git a/drivers/iommu/apple-dart.c b/drivers/iommu/apple-dart.c +index 2082081402d3..0b8927508427 100644 +--- a/drivers/iommu/apple-dart.c ++++ b/drivers/iommu/apple-dart.c +@@ -671,8 +671,7 @@ static int apple_dart_attach_dev(struct iommu_domain *domain, + return ret; + + switch (domain->type) { +- case IOMMU_DOMAIN_DMA: +- case IOMMU_DOMAIN_UNMANAGED: ++ default: + ret = apple_dart_domain_add_streams(dart_domain, cfg); + if (ret) + return ret; +-- +2.42.0 + diff --git a/queue-6.5/iommu-vt-d-avoid-memory-allocation-in-iommu_suspend.patch b/queue-6.5/iommu-vt-d-avoid-memory-allocation-in-iommu_suspend.patch new file mode 100644 index 00000000000..0ab41f02c07 --- /dev/null +++ b/queue-6.5/iommu-vt-d-avoid-memory-allocation-in-iommu_suspend.patch @@ -0,0 +1,120 @@ +From 59df44bfb0ca4c3ee1f1c3c5d0ee8e314844799e Mon Sep 17 00:00:00 2001 +From: Zhang Rui +Date: Mon, 25 Sep 2023 20:04:17 +0800 +Subject: iommu/vt-d: Avoid memory allocation in iommu_suspend() + +From: Zhang Rui + +commit 59df44bfb0ca4c3ee1f1c3c5d0ee8e314844799e upstream. + +The iommu_suspend() syscore suspend callback is invoked with IRQ disabled. +Allocating memory with the GFP_KERNEL flag may re-enable IRQs during +the suspend callback, which can cause intermittent suspend/hibernation +problems with the following kernel traces: + +Calling iommu_suspend+0x0/0x1d0 +------------[ cut here ]------------ +WARNING: CPU: 0 PID: 15 at kernel/time/timekeeping.c:868 ktime_get+0x9b/0xb0 +... +CPU: 0 PID: 15 Comm: rcu_preempt Tainted: G U E 6.3-intel #r1 +RIP: 0010:ktime_get+0x9b/0xb0 +... +Call Trace: + + tick_sched_timer+0x22/0x90 + ? __pfx_tick_sched_timer+0x10/0x10 + __hrtimer_run_queues+0x111/0x2b0 + hrtimer_interrupt+0xfa/0x230 + __sysvec_apic_timer_interrupt+0x63/0x140 + sysvec_apic_timer_interrupt+0x7b/0xa0 + + + asm_sysvec_apic_timer_interrupt+0x1f/0x30 +... +------------[ cut here ]------------ +Interrupts enabled after iommu_suspend+0x0/0x1d0 +WARNING: CPU: 0 PID: 27420 at drivers/base/syscore.c:68 syscore_suspend+0x147/0x270 +CPU: 0 PID: 27420 Comm: rtcwake Tainted: G U W E 6.3-intel #r1 +RIP: 0010:syscore_suspend+0x147/0x270 +... +Call Trace: + + hibernation_snapshot+0x25b/0x670 + hibernate+0xcd/0x390 + state_store+0xcf/0xe0 + kobj_attr_store+0x13/0x30 + sysfs_kf_write+0x3f/0x50 + kernfs_fop_write_iter+0x128/0x200 + vfs_write+0x1fd/0x3c0 + ksys_write+0x6f/0xf0 + __x64_sys_write+0x1d/0x30 + do_syscall_64+0x3b/0x90 + entry_SYSCALL_64_after_hwframe+0x72/0xdc + +Given that only 4 words memory is needed, avoid the memory allocation in +iommu_suspend(). + +CC: stable@kernel.org +Fixes: 33e07157105e ("iommu/vt-d: Avoid GFP_ATOMIC where it is not needed") +Signed-off-by: Zhang Rui +Tested-by: Ooi, Chin Hao +Link: https://lore.kernel.org/r/20230921093956.234692-1-rui.zhang@intel.com +Signed-off-by: Lu Baolu +Link: https://lore.kernel.org/r/20230925120417.55977-2-baolu.lu@linux.intel.com +Signed-off-by: Joerg Roedel +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iommu/intel/iommu.c | 16 ---------------- + drivers/iommu/intel/iommu.h | 2 +- + 2 files changed, 1 insertion(+), 17 deletions(-) + +--- a/drivers/iommu/intel/iommu.c ++++ b/drivers/iommu/intel/iommu.c +@@ -3004,13 +3004,6 @@ static int iommu_suspend(void) + struct intel_iommu *iommu = NULL; + unsigned long flag; + +- for_each_active_iommu(iommu, drhd) { +- iommu->iommu_state = kcalloc(MAX_SR_DMAR_REGS, sizeof(u32), +- GFP_KERNEL); +- if (!iommu->iommu_state) +- goto nomem; +- } +- + iommu_flush_all(); + + for_each_active_iommu(iommu, drhd) { +@@ -3030,12 +3023,6 @@ static int iommu_suspend(void) + raw_spin_unlock_irqrestore(&iommu->register_lock, flag); + } + return 0; +- +-nomem: +- for_each_active_iommu(iommu, drhd) +- kfree(iommu->iommu_state); +- +- return -ENOMEM; + } + + static void iommu_resume(void) +@@ -3067,9 +3054,6 @@ static void iommu_resume(void) + + raw_spin_unlock_irqrestore(&iommu->register_lock, flag); + } +- +- for_each_active_iommu(iommu, drhd) +- kfree(iommu->iommu_state); + } + + static struct syscore_ops iommu_syscore_ops = { +--- a/drivers/iommu/intel/iommu.h ++++ b/drivers/iommu/intel/iommu.h +@@ -680,7 +680,7 @@ struct intel_iommu { + struct iopf_queue *iopf_queue; + unsigned char iopfq_name[16]; + struct q_inval *qi; /* Queued invalidation info */ +- u32 *iommu_state; /* Store iommu states between suspend and resume.*/ ++ u32 iommu_state[MAX_SR_DMAR_REGS]; /* Store iommu states between suspend and resume.*/ + + #ifdef CONFIG_IRQ_REMAP + struct ir_table *ir_table; /* Interrupt remapping info */ diff --git a/queue-6.5/md-raid5-release-batch_last-before-waiting-for-another-stripe_head.patch b/queue-6.5/md-raid5-release-batch_last-before-waiting-for-another-stripe_head.patch new file mode 100644 index 00000000000..8116ca9332d --- /dev/null +++ b/queue-6.5/md-raid5-release-batch_last-before-waiting-for-another-stripe_head.patch @@ -0,0 +1,46 @@ +From 2fd7b0f6d5ad655b1d947d3acdd82f687c31465e Mon Sep 17 00:00:00 2001 +From: David Jeffery +Date: Mon, 2 Oct 2023 14:32:29 -0400 +Subject: md/raid5: release batch_last before waiting for another stripe_head + +From: David Jeffery + +commit 2fd7b0f6d5ad655b1d947d3acdd82f687c31465e upstream. + +When raid5_get_active_stripe is called with a ctx containing a stripe_head in +its batch_last pointer, it can cause a deadlock if the task sleeps waiting on +another stripe_head to become available. The stripe_head held by batch_last +can be blocking the advancement of other stripe_heads, leading to no +stripe_heads being released so raid5_get_active_stripe waits forever. + +Like with the quiesce state handling earlier in the function, batch_last +needs to be released by raid5_get_active_stripe before it waits for another +stripe_head. + +Fixes: 3312e6c887fe ("md/raid5: Keep a reference to last stripe_head for batch") +Cc: stable@vger.kernel.org # v6.0+ +Signed-off-by: David Jeffery +Reviewed-by: Logan Gunthorpe +Signed-off-by: Song Liu +Link: https://lore.kernel.org/r/20231002183422.13047-1-djeffery@redhat.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/md/raid5.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/drivers/md/raid5.c ++++ b/drivers/md/raid5.c +@@ -854,6 +854,13 @@ struct stripe_head *raid5_get_active_str + + set_bit(R5_INACTIVE_BLOCKED, &conf->cache_state); + r5l_wake_reclaim(conf->log, 0); ++ ++ /* release batch_last before wait to avoid risk of deadlock */ ++ if (ctx && ctx->batch_last) { ++ raid5_release_stripe(ctx->batch_last); ++ ctx->batch_last = NULL; ++ } ++ + wait_event_lock_irq(conf->wait_for_stripe, + is_inactive_blocked(conf, hash), + *(conf->hash_locks + hash)); diff --git a/queue-6.5/mptcp-fix-delegated-action-races.patch b/queue-6.5/mptcp-fix-delegated-action-races.patch new file mode 100644 index 00000000000..bc684ae6d2b --- /dev/null +++ b/queue-6.5/mptcp-fix-delegated-action-races.patch @@ -0,0 +1,192 @@ +From a5efdbcece83af94180e8d7c0a6e22947318499d Mon Sep 17 00:00:00 2001 +From: Paolo Abeni +Date: Wed, 4 Oct 2023 13:38:11 -0700 +Subject: mptcp: fix delegated action races + +From: Paolo Abeni + +commit a5efdbcece83af94180e8d7c0a6e22947318499d upstream. + +The delegated action infrastructure is prone to the following +race: different CPUs can try to schedule different delegated +actions on the same subflow at the same time. + +Each of them will check different bits via mptcp_subflow_delegate(), +and will try to schedule the action on the related per-cpu napi +instance. + +Depending on the timing, both can observe an empty delegated list +node, causing the same entry to be added simultaneously on two different +lists. + +The root cause is that the delegated actions infra does not provide +a single synchronization point. Address the issue reserving an additional +bit to mark the subflow as scheduled for delegation. Acquiring such bit +guarantee the caller to own the delegated list node, and being able to +safely schedule the subflow. + +Clear such bit only when the subflow scheduling is completed, ensuring +proper barrier in place. + +Additionally swap the meaning of the delegated_action bitmask, to allow +the usage of the existing helper to set multiple bit at once. + +Fixes: bcd97734318d ("mptcp: use delegate action to schedule 3rd ack retrans") +Cc: stable@vger.kernel.org +Reviewed-by: Mat Martineau +Signed-off-by: Paolo Abeni +Signed-off-by: Mat Martineau +Link: https://lore.kernel.org/r/20231004-send-net-20231004-v1-1-28de4ac663ae@kernel.org +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/mptcp/protocol.c | 28 ++++++++++++++-------------- + net/mptcp/protocol.h | 35 ++++++++++++----------------------- + net/mptcp/subflow.c | 10 ++++++++-- + 3 files changed, 34 insertions(+), 39 deletions(-) + +--- a/net/mptcp/protocol.c ++++ b/net/mptcp/protocol.c +@@ -3409,24 +3409,21 @@ static void schedule_3rdack_retransmissi + sk_reset_timer(ssk, &icsk->icsk_delack_timer, timeout); + } + +-void mptcp_subflow_process_delegated(struct sock *ssk) ++void mptcp_subflow_process_delegated(struct sock *ssk, long status) + { + struct mptcp_subflow_context *subflow = mptcp_subflow_ctx(ssk); + struct sock *sk = subflow->conn; + +- if (test_bit(MPTCP_DELEGATE_SEND, &subflow->delegated_status)) { ++ if (status & BIT(MPTCP_DELEGATE_SEND)) { + mptcp_data_lock(sk); + if (!sock_owned_by_user(sk)) + __mptcp_subflow_push_pending(sk, ssk, true); + else + __set_bit(MPTCP_PUSH_PENDING, &mptcp_sk(sk)->cb_flags); + mptcp_data_unlock(sk); +- mptcp_subflow_delegated_done(subflow, MPTCP_DELEGATE_SEND); + } +- if (test_bit(MPTCP_DELEGATE_ACK, &subflow->delegated_status)) { ++ if (status & BIT(MPTCP_DELEGATE_ACK)) + schedule_3rdack_retransmission(ssk); +- mptcp_subflow_delegated_done(subflow, MPTCP_DELEGATE_ACK); +- } + } + + static int mptcp_hash(struct sock *sk) +@@ -3932,14 +3929,17 @@ static int mptcp_napi_poll(struct napi_s + struct sock *ssk = mptcp_subflow_tcp_sock(subflow); + + bh_lock_sock_nested(ssk); +- if (!sock_owned_by_user(ssk) && +- mptcp_subflow_has_delegated_action(subflow)) +- mptcp_subflow_process_delegated(ssk); +- /* ... elsewhere tcp_release_cb_override already processed +- * the action or will do at next release_sock(). +- * In both case must dequeue the subflow here - on the same +- * CPU that scheduled it. +- */ ++ if (!sock_owned_by_user(ssk)) { ++ mptcp_subflow_process_delegated(ssk, xchg(&subflow->delegated_status, 0)); ++ } else { ++ /* tcp_release_cb_override already processed ++ * the action or will do at next release_sock(). ++ * In both case must dequeue the subflow here - on the same ++ * CPU that scheduled it. ++ */ ++ smp_wmb(); ++ clear_bit(MPTCP_DELEGATE_SCHEDULED, &subflow->delegated_status); ++ } + bh_unlock_sock(ssk); + sock_put(ssk); + +--- a/net/mptcp/protocol.h ++++ b/net/mptcp/protocol.h +@@ -440,9 +440,11 @@ struct mptcp_delegated_action { + + DECLARE_PER_CPU(struct mptcp_delegated_action, mptcp_delegated_actions); + +-#define MPTCP_DELEGATE_SEND 0 +-#define MPTCP_DELEGATE_ACK 1 ++#define MPTCP_DELEGATE_SCHEDULED 0 ++#define MPTCP_DELEGATE_SEND 1 ++#define MPTCP_DELEGATE_ACK 2 + ++#define MPTCP_DELEGATE_ACTIONS_MASK (~BIT(MPTCP_DELEGATE_SCHEDULED)) + /* MPTCP subflow context */ + struct mptcp_subflow_context { + struct list_head node;/* conn_list of subflows */ +@@ -559,23 +561,24 @@ mptcp_subflow_get_mapped_dsn(const struc + return subflow->map_seq + mptcp_subflow_get_map_offset(subflow); + } + +-void mptcp_subflow_process_delegated(struct sock *ssk); ++void mptcp_subflow_process_delegated(struct sock *ssk, long actions); + + static inline void mptcp_subflow_delegate(struct mptcp_subflow_context *subflow, int action) + { ++ long old, set_bits = BIT(MPTCP_DELEGATE_SCHEDULED) | BIT(action); + struct mptcp_delegated_action *delegated; + bool schedule; + + /* the caller held the subflow bh socket lock */ + lockdep_assert_in_softirq(); + +- /* The implied barrier pairs with mptcp_subflow_delegated_done(), and +- * ensures the below list check sees list updates done prior to status +- * bit changes ++ /* The implied barrier pairs with tcp_release_cb_override() ++ * mptcp_napi_poll(), and ensures the below list check sees list ++ * updates done prior to delegated status bits changes + */ +- if (!test_and_set_bit(action, &subflow->delegated_status)) { +- /* still on delegated list from previous scheduling */ +- if (!list_empty(&subflow->delegated_node)) ++ old = set_mask_bits(&subflow->delegated_status, 0, set_bits); ++ if (!(old & BIT(MPTCP_DELEGATE_SCHEDULED))) { ++ if (WARN_ON_ONCE(!list_empty(&subflow->delegated_node))) + return; + + delegated = this_cpu_ptr(&mptcp_delegated_actions); +@@ -600,20 +603,6 @@ mptcp_subflow_delegated_next(struct mptc + return ret; + } + +-static inline bool mptcp_subflow_has_delegated_action(const struct mptcp_subflow_context *subflow) +-{ +- return !!READ_ONCE(subflow->delegated_status); +-} +- +-static inline void mptcp_subflow_delegated_done(struct mptcp_subflow_context *subflow, int action) +-{ +- /* pairs with mptcp_subflow_delegate, ensures delegate_node is updated before +- * touching the status bit +- */ +- smp_wmb(); +- clear_bit(action, &subflow->delegated_status); +-} +- + int mptcp_is_enabled(const struct net *net); + unsigned int mptcp_get_add_addr_timeout(const struct net *net); + int mptcp_is_checksum_enabled(const struct net *net); +--- a/net/mptcp/subflow.c ++++ b/net/mptcp/subflow.c +@@ -1956,9 +1956,15 @@ static void subflow_ulp_clone(const stru + static void tcp_release_cb_override(struct sock *ssk) + { + struct mptcp_subflow_context *subflow = mptcp_subflow_ctx(ssk); ++ long status; + +- if (mptcp_subflow_has_delegated_action(subflow)) +- mptcp_subflow_process_delegated(ssk); ++ /* process and clear all the pending actions, but leave the subflow into ++ * the napi queue. To respect locking, only the same CPU that originated ++ * the action can touch the list. mptcp_napi_poll will take care of it. ++ */ ++ status = set_mask_bits(&subflow->delegated_status, MPTCP_DELEGATE_ACTIONS_MASK, 0); ++ if (status) ++ mptcp_subflow_process_delegated(ssk, status); + + tcp_release_cb(ssk); + } diff --git a/queue-6.5/mptcp-userspace-pm-allow-creating-id-0-subflow.patch b/queue-6.5/mptcp-userspace-pm-allow-creating-id-0-subflow.patch new file mode 100644 index 00000000000..c7148bbc17d --- /dev/null +++ b/queue-6.5/mptcp-userspace-pm-allow-creating-id-0-subflow.patch @@ -0,0 +1,45 @@ +From e5ed101a602873d65d2d64edaba93e8c73ec1b0f Mon Sep 17 00:00:00 2001 +From: Geliang Tang +Date: Wed, 4 Oct 2023 13:38:12 -0700 +Subject: mptcp: userspace pm allow creating id 0 subflow + +From: Geliang Tang + +commit e5ed101a602873d65d2d64edaba93e8c73ec1b0f upstream. + +This patch drops id 0 limitation in mptcp_nl_cmd_sf_create() to allow +creating additional subflows with the local addr ID 0. + +There is no reason not to allow additional subflows from this local +address: we should be able to create new subflows from the initial +endpoint. This limitation was breaking fullmesh support from userspace. + +Fixes: 702c2f646d42 ("mptcp: netlink: allow userspace-driven subflow establishment") +Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/391 +Cc: stable@vger.kernel.org +Suggested-by: Matthieu Baerts +Reviewed-by: Matthieu Baerts +Signed-off-by: Geliang Tang +Signed-off-by: Mat Martineau +Link: https://lore.kernel.org/r/20231004-send-net-20231004-v1-2-28de4ac663ae@kernel.org +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/mptcp/pm_userspace.c | 6 ------ + 1 file changed, 6 deletions(-) + +--- a/net/mptcp/pm_userspace.c ++++ b/net/mptcp/pm_userspace.c +@@ -307,12 +307,6 @@ int mptcp_nl_cmd_sf_create(struct sk_buf + goto create_err; + } + +- if (addr_l.id == 0) { +- NL_SET_ERR_MSG_ATTR(info->extack, laddr, "missing local addr id"); +- err = -EINVAL; +- goto create_err; +- } +- + err = mptcp_pm_parse_addr(raddr, info, &addr_r); + if (err < 0) { + NL_SET_ERR_MSG_ATTR(info->extack, raddr, "error parsing remote addr"); diff --git a/queue-6.5/net-ethernet-mediatek-disable-irq-before-schedule-napi.patch b/queue-6.5/net-ethernet-mediatek-disable-irq-before-schedule-napi.patch new file mode 100644 index 00000000000..111319ae6c8 --- /dev/null +++ b/queue-6.5/net-ethernet-mediatek-disable-irq-before-schedule-napi.patch @@ -0,0 +1,59 @@ +From fcdfc462881d8acf9db77f483b2c821e286ca97b Mon Sep 17 00:00:00 2001 +From: Christian Marangi +Date: Mon, 2 Oct 2023 16:08:05 +0200 +Subject: net: ethernet: mediatek: disable irq before schedule napi + +From: Christian Marangi + +commit fcdfc462881d8acf9db77f483b2c821e286ca97b upstream. + +While searching for possible refactor of napi_schedule_prep and +__napi_schedule it was notice that the mtk eth driver disable the +interrupt for rx and tx AFTER napi is scheduled. + +While this is a very hard to repro case it might happen to have +situation where the interrupt is disabled and never enabled again as the +napi completes and the interrupt is enabled before. + +This is caused by the fact that a napi driven by interrupt expect a +logic with: +1. interrupt received. napi prepared -> interrupt disabled -> napi + scheduled +2. napi triggered. ring cleared -> interrupt enabled -> wait for new + interrupt + +To prevent this case, disable the interrupt BEFORE the napi is +scheduled. + +Fixes: 656e705243fd ("net-next: mediatek: add support for MT7623 ethernet") +Cc: stable@vger.kernel.org +Signed-off-by: Christian Marangi +Link: https://lore.kernel.org/r/20231002140805.568-1-ansuelsmth@gmail.com +Signed-off-by: Paolo Abeni +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/mediatek/mtk_eth_soc.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c ++++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c +@@ -3036,8 +3036,8 @@ static irqreturn_t mtk_handle_irq_rx(int + + eth->rx_events++; + if (likely(napi_schedule_prep(ð->rx_napi))) { +- __napi_schedule(ð->rx_napi); + mtk_rx_irq_disable(eth, eth->soc->txrx.rx_irq_done_mask); ++ __napi_schedule(ð->rx_napi); + } + + return IRQ_HANDLED; +@@ -3049,8 +3049,8 @@ static irqreturn_t mtk_handle_irq_tx(int + + eth->tx_events++; + if (likely(napi_schedule_prep(ð->tx_napi))) { +- __napi_schedule(ð->tx_napi); + mtk_tx_irq_disable(eth, MTK_TX_DONE_INT); ++ __napi_schedule(ð->tx_napi); + } + + return IRQ_HANDLED; diff --git a/queue-6.5/net-mana-fix-the-tso_bytes-calculation.patch b/queue-6.5/net-mana-fix-the-tso_bytes-calculation.patch new file mode 100644 index 00000000000..5a3165a0872 --- /dev/null +++ b/queue-6.5/net-mana-fix-the-tso_bytes-calculation.patch @@ -0,0 +1,34 @@ +From 7a54de92657455210d0ca71d4176b553952c871a Mon Sep 17 00:00:00 2001 +From: Haiyang Zhang +Date: Fri, 29 Sep 2023 13:42:26 -0700 +Subject: net: mana: Fix the tso_bytes calculation + +From: Haiyang Zhang + +commit 7a54de92657455210d0ca71d4176b553952c871a upstream. + +sizeof(struct hop_jumbo_hdr) is not part of tso_bytes, so remove +the subtraction from header size. + +Cc: stable@vger.kernel.org +Fixes: bd7fc6e1957c ("net: mana: Add new MANA VF performance counters for easier troubleshooting") +Signed-off-by: Haiyang Zhang +Reviewed-by: Simon Horman +Reviewed-by: Shradha Gupta +Signed-off-by: Paolo Abeni +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/microsoft/mana/mana_en.c | 2 -- + 1 file changed, 2 deletions(-) + +--- a/drivers/net/ethernet/microsoft/mana/mana_en.c ++++ b/drivers/net/ethernet/microsoft/mana/mana_en.c +@@ -262,8 +262,6 @@ netdev_tx_t mana_start_xmit(struct sk_bu + ihs = skb_transport_offset(skb) + sizeof(struct udphdr); + } else { + ihs = skb_tcp_all_headers(skb); +- if (ipv6_has_hopopt_jumbo(skb)) +- ihs -= sizeof(struct hop_jumbo_hdr); + } + + u64_stats_update_begin(&tx_stats->syncp); diff --git a/queue-6.5/net-mana-fix-tx-cqe-error-handling.patch b/queue-6.5/net-mana-fix-tx-cqe-error-handling.patch new file mode 100644 index 00000000000..49a7cc73374 --- /dev/null +++ b/queue-6.5/net-mana-fix-tx-cqe-error-handling.patch @@ -0,0 +1,60 @@ +From b2b000069a4c307b09548dc2243f31f3ca0eac9c Mon Sep 17 00:00:00 2001 +From: Haiyang Zhang +Date: Fri, 29 Sep 2023 13:42:25 -0700 +Subject: net: mana: Fix TX CQE error handling + +From: Haiyang Zhang + +commit b2b000069a4c307b09548dc2243f31f3ca0eac9c upstream. + +For an unknown TX CQE error type (probably from a newer hardware), +still free the SKB, update the queue tail, etc., otherwise the +accounting will be wrong. + +Also, TX errors can be triggered by injecting corrupted packets, so +replace the WARN_ONCE to ratelimited error logging. + +Cc: stable@vger.kernel.org +Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)") +Signed-off-by: Haiyang Zhang +Reviewed-by: Simon Horman +Reviewed-by: Shradha Gupta +Signed-off-by: Paolo Abeni +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/microsoft/mana/mana_en.c | 18 +++++++++++------- + 1 file changed, 11 insertions(+), 7 deletions(-) + +--- a/drivers/net/ethernet/microsoft/mana/mana_en.c ++++ b/drivers/net/ethernet/microsoft/mana/mana_en.c +@@ -1315,19 +1315,23 @@ static void mana_poll_tx_cq(struct mana_ + case CQE_TX_VPORT_IDX_OUT_OF_RANGE: + case CQE_TX_VPORT_DISABLED: + case CQE_TX_VLAN_TAGGING_VIOLATION: +- WARN_ONCE(1, "TX: CQE error %d: ignored.\n", +- cqe_oob->cqe_hdr.cqe_type); ++ if (net_ratelimit()) ++ netdev_err(ndev, "TX: CQE error %d\n", ++ cqe_oob->cqe_hdr.cqe_type); ++ + apc->eth_stats.tx_cqe_err++; + break; + + default: +- /* If the CQE type is unexpected, log an error, assert, +- * and go through the error path. ++ /* If the CQE type is unknown, log an error, ++ * and still free the SKB, update tail, etc. + */ +- WARN_ONCE(1, "TX: Unexpected CQE type %d: HW BUG?\n", +- cqe_oob->cqe_hdr.cqe_type); ++ if (net_ratelimit()) ++ netdev_err(ndev, "TX: unknown CQE type %d\n", ++ cqe_oob->cqe_hdr.cqe_type); ++ + apc->eth_stats.tx_cqe_unknown_type++; +- return; ++ break; + } + + if (WARN_ON_ONCE(txq->gdma_txq_id != completions[i].wq_num)) diff --git a/queue-6.5/net-prevent-rewrite-of-msg_name-in-sock_sendmsg.patch b/queue-6.5/net-prevent-rewrite-of-msg_name-in-sock_sendmsg.patch new file mode 100644 index 00000000000..1c5b4c074ad --- /dev/null +++ b/queue-6.5/net-prevent-rewrite-of-msg_name-in-sock_sendmsg.patch @@ -0,0 +1,105 @@ +From 86a7e0b69bd5b812e48a20c66c2161744f3caa16 Mon Sep 17 00:00:00 2001 +From: Jordan Rife +Date: Thu, 21 Sep 2023 18:46:41 -0500 +Subject: net: prevent rewrite of msg_name in sock_sendmsg() + +From: Jordan Rife + +commit 86a7e0b69bd5b812e48a20c66c2161744f3caa16 upstream. + +Callers of sock_sendmsg(), and similarly kernel_sendmsg(), in kernel +space may observe their value of msg_name change in cases where BPF +sendmsg hooks rewrite the send address. This has been confirmed to break +NFS mounts running in UDP mode and has the potential to break other +systems. + +This patch: + +1) Creates a new function called __sock_sendmsg() with same logic as the + old sock_sendmsg() function. +2) Replaces calls to sock_sendmsg() made by __sys_sendto() and + __sys_sendmsg() with __sock_sendmsg() to avoid an unnecessary copy, + as these system calls are already protected. +3) Modifies sock_sendmsg() so that it makes a copy of msg_name if + present before passing it down the stack to insulate callers from + changes to the send address. + +Link: https://lore.kernel.org/netdev/20230912013332.2048422-1-jrife@google.com/ +Fixes: 1cedee13d25a ("bpf: Hooks for sys_sendmsg") +Cc: stable@vger.kernel.org +Reviewed-by: Willem de Bruijn +Signed-off-by: Jordan Rife +Reviewed-by: Simon Horman +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + net/socket.c | 29 +++++++++++++++++++++++------ + 1 file changed, 23 insertions(+), 6 deletions(-) + +--- a/net/socket.c ++++ b/net/socket.c +@@ -732,6 +732,14 @@ static inline int sock_sendmsg_nosec(str + return ret; + } + ++static int __sock_sendmsg(struct socket *sock, struct msghdr *msg) ++{ ++ int err = security_socket_sendmsg(sock, msg, ++ msg_data_left(msg)); ++ ++ return err ?: sock_sendmsg_nosec(sock, msg); ++} ++ + /** + * sock_sendmsg - send a message through @sock + * @sock: socket +@@ -742,10 +750,19 @@ static inline int sock_sendmsg_nosec(str + */ + int sock_sendmsg(struct socket *sock, struct msghdr *msg) + { +- int err = security_socket_sendmsg(sock, msg, +- msg_data_left(msg)); ++ struct sockaddr_storage *save_addr = (struct sockaddr_storage *)msg->msg_name; ++ struct sockaddr_storage address; ++ int ret; + +- return err ?: sock_sendmsg_nosec(sock, msg); ++ if (msg->msg_name) { ++ memcpy(&address, msg->msg_name, msg->msg_namelen); ++ msg->msg_name = &address; ++ } ++ ++ ret = __sock_sendmsg(sock, msg); ++ msg->msg_name = save_addr; ++ ++ return ret; + } + EXPORT_SYMBOL(sock_sendmsg); + +@@ -1127,7 +1144,7 @@ static ssize_t sock_write_iter(struct ki + if (sock->type == SOCK_SEQPACKET) + msg.msg_flags |= MSG_EOR; + +- res = sock_sendmsg(sock, &msg); ++ res = __sock_sendmsg(sock, &msg); + *from = msg.msg_iter; + return res; + } +@@ -2132,7 +2149,7 @@ int __sys_sendto(int fd, void __user *bu + if (sock->file->f_flags & O_NONBLOCK) + flags |= MSG_DONTWAIT; + msg.msg_flags = flags; +- err = sock_sendmsg(sock, &msg); ++ err = __sock_sendmsg(sock, &msg); + + out_put: + fput_light(sock->file, fput_needed); +@@ -2492,7 +2509,7 @@ static int ____sys_sendmsg(struct socket + err = sock_sendmsg_nosec(sock, msg_sys); + goto out_freectl; + } +- err = sock_sendmsg(sock, msg_sys); ++ err = __sock_sendmsg(sock, msg_sys); + /* + * If this is sendmmsg() and sending to current destination address was + * successful, remember it. diff --git a/queue-6.5/net-replace-calls-to-sock-ops-connect-with-kernel_connect.patch b/queue-6.5/net-replace-calls-to-sock-ops-connect-with-kernel_connect.patch new file mode 100644 index 00000000000..b10162e7008 --- /dev/null +++ b/queue-6.5/net-replace-calls-to-sock-ops-connect-with-kernel_connect.patch @@ -0,0 +1,52 @@ +From 26297b4ce1ce4ea40bc9a48ec99f45da3f64d2e2 Mon Sep 17 00:00:00 2001 +From: Jordan Rife +Date: Thu, 21 Sep 2023 18:46:40 -0500 +Subject: net: replace calls to sock->ops->connect() with kernel_connect() + +From: Jordan Rife + +commit 26297b4ce1ce4ea40bc9a48ec99f45da3f64d2e2 upstream. + +commit 0bdf399342c5 ("net: Avoid address overwrite in kernel_connect") +ensured that kernel_connect() will not overwrite the address parameter +in cases where BPF connect hooks perform an address rewrite. This change +replaces direct calls to sock->ops->connect() in net with kernel_connect() +to make these call safe. + +Link: https://lore.kernel.org/netdev/20230912013332.2048422-1-jrife@google.com/ +Fixes: d74bad4e74ee ("bpf: Hooks for sys_connect") +Cc: stable@vger.kernel.org +Reviewed-by: Willem de Bruijn +Signed-off-by: Jordan Rife +Reviewed-by: Simon Horman +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + net/netfilter/ipvs/ip_vs_sync.c | 4 ++-- + net/rds/tcp_connect.c | 2 +- + 2 files changed, 3 insertions(+), 3 deletions(-) + +--- a/net/netfilter/ipvs/ip_vs_sync.c ++++ b/net/netfilter/ipvs/ip_vs_sync.c +@@ -1507,8 +1507,8 @@ static int make_send_sock(struct netns_i + } + + get_mcast_sockaddr(&mcast_addr, &salen, &ipvs->mcfg, id); +- result = sock->ops->connect(sock, (struct sockaddr *) &mcast_addr, +- salen, 0); ++ result = kernel_connect(sock, (struct sockaddr *)&mcast_addr, ++ salen, 0); + if (result < 0) { + pr_err("Error connecting to the multicast addr\n"); + goto error; +--- a/net/rds/tcp_connect.c ++++ b/net/rds/tcp_connect.c +@@ -173,7 +173,7 @@ int rds_tcp_conn_path_connect(struct rds + * own the socket + */ + rds_tcp_set_callbacks(sock, cp); +- ret = sock->ops->connect(sock, addr, addrlen, O_NONBLOCK); ++ ret = kernel_connect(sock, addr, addrlen, O_NONBLOCK); + + rdsdebug("connect to address %pI6c returned %d\n", &conn->c_faddr, ret); + if (ret == -EINPROGRESS) diff --git a/queue-6.5/pci-pm-mark-devices-disconnected-if-upstream-pcie-link-is-down-on-resume.patch b/queue-6.5/pci-pm-mark-devices-disconnected-if-upstream-pcie-link-is-down-on-resume.patch new file mode 100644 index 00000000000..385edebac5d --- /dev/null +++ b/queue-6.5/pci-pm-mark-devices-disconnected-if-upstream-pcie-link-is-down-on-resume.patch @@ -0,0 +1,82 @@ +From c82458101d5490230d735caecce14c9c27b1010c Mon Sep 17 00:00:00 2001 +From: Mika Westerberg +Date: Mon, 18 Sep 2023 08:30:41 +0300 +Subject: PCI/PM: Mark devices disconnected if upstream PCIe link is down on resume + +From: Mika Westerberg + +commit c82458101d5490230d735caecce14c9c27b1010c upstream. + +Mark Blakeney reported that when suspending system with a Thunderbolt +dock connected and then unplugging the dock before resume (which is +pretty normal flow with laptops), resuming takes long time. + +What happens is that the PCIe link from the root port to the PCIe switch +inside the Thunderbolt device does not train (as expected, the link is +unplugged): + + pcieport 0000:00:07.2: restoring config space at offset 0x24 (was 0x3bf12001, writing 0x3bf12001) + pcieport 0000:00:07.0: waiting 100 ms for downstream link + pcieport 0000:01:00.0: not ready 1023ms after resume; giving up + +However, at this point we still try to resume the devices below that +unplugged link: + + pcieport 0000:01:00.0: Unable to change power state from D3cold to D0, device inaccessible + ... + pcieport 0000:01:00.0: restoring config space at offset 0x38 (was 0xffffffff, writing 0x0) + ... + pcieport 0000:02:02.0: waiting 100 ms for downstream link, after activation + +And this is the link from PCIe switch downstream port to the xHCI on the +dock: + + xhci_hcd 0000:03:00.0: not ready 65535ms after resume; giving up + xhci_hcd 0000:03:00.0: Unable to change power state from D3cold to D0, device inaccessible + xhci_hcd 0000:03:00.0: restoring config space at offset 0x3c (was 0xffffffff, writing 0x1ff) + +This ends up slowing down the resume time considerably. For this reason +mark these devices as disconnected if the link above them did not train +properly. + +Fixes: e8b908146d44 ("PCI/PM: Increase wait time after resume") +Link: https://lore.kernel.org/r/20230918053041.1018876-1-mika.westerberg@linux.intel.com +Reported-by: Mark Blakeney +Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217915 +Signed-off-by: Mika Westerberg +Signed-off-by: Bjorn Helgaas +Reviewed-by: Lukas Wunner +Cc: stable@vger.kernel.org # v6.4+ +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/pci-driver.c | 14 +++++++++++++- + 1 file changed, 13 insertions(+), 1 deletion(-) + +diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c +index a79c110c7e51..51ec9e7e784f 100644 +--- a/drivers/pci/pci-driver.c ++++ b/drivers/pci/pci-driver.c +@@ -572,7 +572,19 @@ static void pci_pm_default_resume_early(struct pci_dev *pci_dev) + + static void pci_pm_bridge_power_up_actions(struct pci_dev *pci_dev) + { +- pci_bridge_wait_for_secondary_bus(pci_dev, "resume"); ++ int ret; ++ ++ ret = pci_bridge_wait_for_secondary_bus(pci_dev, "resume"); ++ if (ret) { ++ /* ++ * The downstream link failed to come up, so mark the ++ * devices below as disconnected to make sure we don't ++ * attempt to resume them. ++ */ ++ pci_walk_bus(pci_dev->subordinate, pci_dev_set_disconnected, ++ NULL); ++ return; ++ } + + /* + * When powering on a bridge from D3cold, the whole hierarchy may be +-- +2.42.0 + diff --git a/queue-6.5/pci-qcom-fix-ipq8074-enumeration.patch b/queue-6.5/pci-qcom-fix-ipq8074-enumeration.patch new file mode 100644 index 00000000000..6e68d1cc414 --- /dev/null +++ b/queue-6.5/pci-qcom-fix-ipq8074-enumeration.patch @@ -0,0 +1,54 @@ +From 6a878a54d0053ef21f3b829dc267487c2302b012 Mon Sep 17 00:00:00 2001 +From: Sricharan Ramabadhran +Date: Tue, 19 Sep 2023 15:59:48 +0530 +Subject: PCI: qcom: Fix IPQ8074 enumeration + +From: Sricharan Ramabadhran + +commit 6a878a54d0053ef21f3b829dc267487c2302b012 upstream. + +PARF_SLV_ADDR_SPACE_SIZE_2_3_3 is used by qcom_pcie_post_init_2_3_3(). +This PCIe slave address space size register offset is 0x358 but was +incorrectly changed to 0x16c by 39171b33f652 ("PCI: qcom: Remove PCIE20_ +prefix from register definitions"). + +This prevented access to slave address space registers like iATU, etc., +so the IPQ8074 PCIe controller was not enumerated. + +Revert back to the correct 0x358 offset and remove the unused +PARF_SLV_ADDR_SPACE_SIZE_2_3_3. + +Fixes: 39171b33f652 ("PCI: qcom: Remove PCIE20_ prefix from register definitions") +Link: https://lore.kernel.org/r/20230919102948.1844909-1-quic_srichara@quicinc.com +Tested-by: Robert Marko +Signed-off-by: Sricharan Ramabadhran +[bhelgaas: commit log] +Signed-off-by: Bjorn Helgaas +Reviewed-by: Manivannan Sadhasivam +Reviewed-by: Konrad Dybcio +Cc: stable@vger.kernel.org # v6.4+ +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/controller/dwc/pcie-qcom.c | 4 +--- + 1 file changed, 1 insertion(+), 3 deletions(-) + +--- a/drivers/pci/controller/dwc/pcie-qcom.c ++++ b/drivers/pci/controller/dwc/pcie-qcom.c +@@ -43,7 +43,6 @@ + #define PARF_PHY_REFCLK 0x4c + #define PARF_CONFIG_BITS 0x50 + #define PARF_DBI_BASE_ADDR 0x168 +-#define PARF_SLV_ADDR_SPACE_SIZE_2_3_3 0x16c /* Register offset specific to IP ver 2.3.3 */ + #define PARF_MHI_CLOCK_RESET_CTRL 0x174 + #define PARF_AXI_MSTR_WR_ADDR_HALT 0x178 + #define PARF_AXI_MSTR_WR_ADDR_HALT_V2 0x1a8 +@@ -797,8 +796,7 @@ static int qcom_pcie_post_init_2_3_3(str + u16 offset = dw_pcie_find_capability(pci, PCI_CAP_ID_EXP); + u32 val; + +- writel(SLV_ADDR_SPACE_SZ, +- pcie->parf + PARF_SLV_ADDR_SPACE_SIZE_2_3_3); ++ writel(SLV_ADDR_SPACE_SZ, pcie->parf + PARF_SLV_ADDR_SPACE_SIZE); + + val = readl(pcie->parf + PARF_PHY_CTRL); + val &= ~PHY_TEST_PWR_DOWN; diff --git a/queue-6.5/platform-x86-intel-ifs-release-cpus_read_lock.patch b/queue-6.5/platform-x86-intel-ifs-release-cpus_read_lock.patch new file mode 100644 index 00000000000..0595bdbc0e4 --- /dev/null +++ b/queue-6.5/platform-x86-intel-ifs-release-cpus_read_lock.patch @@ -0,0 +1,64 @@ +From 2545deba314eec91dc5ca1a954fe97f91ef1cf07 Mon Sep 17 00:00:00 2001 +From: Jithu Joseph +Date: Wed, 27 Sep 2023 11:48:24 -0700 +Subject: platform/x86/intel/ifs: release cpus_read_lock() + +From: Jithu Joseph + +commit 2545deba314eec91dc5ca1a954fe97f91ef1cf07 upstream. + +Couple of error paths in do_core_test() was returning directly without +doing a necessary cpus_read_unlock(). + +Following lockdep warning was observed when exercising these scenarios +with PROVE_RAW_LOCK_NESTING enabled: + +[ 139.304775] ================================================ +[ 139.311185] WARNING: lock held when returning to user space! +[ 139.317593] 6.6.0-rc2ifs01+ #11 Tainted: G S W I +[ 139.324499] ------------------------------------------------ +[ 139.330908] bash/11476 is leaving the kernel with locks still held! +[ 139.338000] 1 lock held by bash/11476: +[ 139.342262] #0: ffffffffaa26c930 (cpu_hotplug_lock){++++}-{0:0}, at: +do_core_test+0x35/0x1c0 [intel_ifs] + +Fix the flow so that all scenarios release the lock prior to returning +from the function. + +Fixes: 5210fb4e1880 ("platform/x86/intel/ifs: Sysfs interface for Array BIST") +Cc: stable@vger.kernel.org +Signed-off-by: Jithu Joseph +Link: https://lore.kernel.org/r/20230927184824.2566086-1-jithu.joseph@intel.com +Reviewed-by: Hans de Goede +Signed-off-by: Hans de Goede +Signed-off-by: Greg Kroah-Hartman +--- + drivers/platform/x86/intel/ifs/runtest.c | 7 ++++--- + 1 file changed, 4 insertions(+), 3 deletions(-) + +diff --git a/drivers/platform/x86/intel/ifs/runtest.c b/drivers/platform/x86/intel/ifs/runtest.c +index 1061eb7ec399..43c864add778 100644 +--- a/drivers/platform/x86/intel/ifs/runtest.c ++++ b/drivers/platform/x86/intel/ifs/runtest.c +@@ -331,14 +331,15 @@ int do_core_test(int cpu, struct device *dev) + switch (test->test_num) { + case IFS_TYPE_SAF: + if (!ifsd->loaded) +- return -EPERM; +- ifs_test_core(cpu, dev); ++ ret = -EPERM; ++ else ++ ifs_test_core(cpu, dev); + break; + case IFS_TYPE_ARRAY_BIST: + ifs_array_test_core(cpu, dev); + break; + default: +- return -EINVAL; ++ ret = -EINVAL; + } + out: + cpus_read_unlock(); +-- +2.42.0 + diff --git a/queue-6.5/qed-red_ll2-fix-undefined-behavior-bug-in-struct-qed_ll2_info.patch b/queue-6.5/qed-red_ll2-fix-undefined-behavior-bug-in-struct-qed_ll2_info.patch new file mode 100644 index 00000000000..fe43a9f7ae6 --- /dev/null +++ b/queue-6.5/qed-red_ll2-fix-undefined-behavior-bug-in-struct-qed_ll2_info.patch @@ -0,0 +1,116 @@ +From eea03d18af9c44235865a4bc9bec4d780ef6cf21 Mon Sep 17 00:00:00 2001 +From: "Gustavo A. R. Silva" +Date: Sat, 23 Sep 2023 19:15:59 -0600 +Subject: qed/red_ll2: Fix undefined behavior bug in struct qed_ll2_info + +From: Gustavo A. R. Silva + +commit eea03d18af9c44235865a4bc9bec4d780ef6cf21 upstream. + +The flexible structure (a structure that contains a flexible-array member +at the end) `qed_ll2_tx_packet` is nested within the second layer of +`struct qed_ll2_info`: + +struct qed_ll2_tx_packet { + ... + /* Flexible Array of bds_set determined by max_bds_per_packet */ + struct { + struct core_tx_bd *txq_bd; + dma_addr_t tx_frag; + u16 frag_len; + } bds_set[]; +}; + +struct qed_ll2_tx_queue { + ... + struct qed_ll2_tx_packet cur_completing_packet; +}; + +struct qed_ll2_info { + ... + struct qed_ll2_tx_queue tx_queue; + struct qed_ll2_cbs cbs; +}; + +The problem is that member `cbs` in `struct qed_ll2_info` is placed just +after an object of type `struct qed_ll2_tx_queue`, which is in itself +an implicit flexible structure, which by definition ends in a flexible +array member, in this case `bds_set`. This causes an undefined behavior +bug at run-time when dynamic memory is allocated for `bds_set`, which +could lead to a serious issue if `cbs` in `struct qed_ll2_info` is +overwritten by the contents of `bds_set`. Notice that the type of `cbs` +is a structure full of function pointers (and a cookie :) ): + +include/linux/qed/qed_ll2_if.h: +107 typedef +108 void (*qed_ll2_complete_rx_packet_cb)(void *cxt, +109 struct qed_ll2_comp_rx_data *data); +110 +111 typedef +112 void (*qed_ll2_release_rx_packet_cb)(void *cxt, +113 u8 connection_handle, +114 void *cookie, +115 dma_addr_t rx_buf_addr, +116 bool b_last_packet); +117 +118 typedef +119 void (*qed_ll2_complete_tx_packet_cb)(void *cxt, +120 u8 connection_handle, +121 void *cookie, +122 dma_addr_t first_frag_addr, +123 bool b_last_fragment, +124 bool b_last_packet); +125 +126 typedef +127 void (*qed_ll2_release_tx_packet_cb)(void *cxt, +128 u8 connection_handle, +129 void *cookie, +130 dma_addr_t first_frag_addr, +131 bool b_last_fragment, bool b_last_packet); +132 +133 typedef +134 void (*qed_ll2_slowpath_cb)(void *cxt, u8 connection_handle, +135 u32 opaque_data_0, u32 opaque_data_1); +136 +137 struct qed_ll2_cbs { +138 qed_ll2_complete_rx_packet_cb rx_comp_cb; +139 qed_ll2_release_rx_packet_cb rx_release_cb; +140 qed_ll2_complete_tx_packet_cb tx_comp_cb; +141 qed_ll2_release_tx_packet_cb tx_release_cb; +142 qed_ll2_slowpath_cb slowpath_cb; +143 void *cookie; +144 }; + +Fix this by moving the declaration of `cbs` to the middle of its +containing structure `qed_ll2_info`, preventing it from being +overwritten by the contents of `bds_set` at run-time. + +This bug was introduced in 2017, when `bds_set` was converted to a +one-element array, and started to be used as a Variable Length Object +(VLO) at run-time. + +Fixes: f5823fe6897c ("qed: Add ll2 option to limit the number of bds per packet") +Cc: stable@vger.kernel.org +Signed-off-by: Gustavo A. R. Silva +Reviewed-by: Kees Cook +Reviewed-by: Simon Horman +Link: https://lore.kernel.org/r/ZQ+Nz8DfPg56pIzr@work +Signed-off-by: Paolo Abeni +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/qlogic/qed/qed_ll2.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/ethernet/qlogic/qed/qed_ll2.h ++++ b/drivers/net/ethernet/qlogic/qed/qed_ll2.h +@@ -110,9 +110,9 @@ struct qed_ll2_info { + enum core_tx_dest tx_dest; + u8 tx_stats_en; + bool main_func_queue; ++ struct qed_ll2_cbs cbs; + struct qed_ll2_rx_queue rx_queue; + struct qed_ll2_tx_queue tx_queue; +- struct qed_ll2_cbs cbs; + }; + + extern const struct qed_ll2_ops qed_ll2_ops_pass; diff --git a/queue-6.5/scsi-zfcp-fix-a-double-put-in-zfcp_port_enqueue.patch b/queue-6.5/scsi-zfcp-fix-a-double-put-in-zfcp_port_enqueue.patch new file mode 100644 index 00000000000..603f6d91b94 --- /dev/null +++ b/queue-6.5/scsi-zfcp-fix-a-double-put-in-zfcp_port_enqueue.patch @@ -0,0 +1,63 @@ +From b481f644d9174670b385c3a699617052cd2a79d3 Mon Sep 17 00:00:00 2001 +From: Dinghao Liu +Date: Sat, 23 Sep 2023 18:37:23 +0800 +Subject: scsi: zfcp: Fix a double put in zfcp_port_enqueue() + +From: Dinghao Liu + +commit b481f644d9174670b385c3a699617052cd2a79d3 upstream. + +When device_register() fails, zfcp_port_release() will be called after +put_device(). As a result, zfcp_ccw_adapter_put() will be called twice: one +in zfcp_port_release() and one in the error path after device_register(). +So the reference on the adapter object is doubly put, which may lead to a +premature free. Fix this by adjusting the error tag after +device_register(). + +Fixes: f3450c7b9172 ("[SCSI] zfcp: Replace local reference counting with common kref") +Signed-off-by: Dinghao Liu +Link: https://lore.kernel.org/r/20230923103723.10320-1-dinghao.liu@zju.edu.cn +Acked-by: Benjamin Block +Cc: stable@vger.kernel.org # v2.6.33+ +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/s390/scsi/zfcp_aux.c | 9 +++++---- + 1 file changed, 5 insertions(+), 4 deletions(-) + +--- a/drivers/s390/scsi/zfcp_aux.c ++++ b/drivers/s390/scsi/zfcp_aux.c +@@ -518,12 +518,12 @@ struct zfcp_port *zfcp_port_enqueue(stru + if (port) { + put_device(&port->dev); + retval = -EEXIST; +- goto err_out; ++ goto err_put; + } + + port = kzalloc(sizeof(struct zfcp_port), GFP_KERNEL); + if (!port) +- goto err_out; ++ goto err_put; + + rwlock_init(&port->unit_list_lock); + INIT_LIST_HEAD(&port->unit_list); +@@ -546,7 +546,7 @@ struct zfcp_port *zfcp_port_enqueue(stru + + if (dev_set_name(&port->dev, "0x%016llx", (unsigned long long)wwpn)) { + kfree(port); +- goto err_out; ++ goto err_put; + } + retval = -EINVAL; + +@@ -563,7 +563,8 @@ struct zfcp_port *zfcp_port_enqueue(stru + + return port; + +-err_out: ++err_put: + zfcp_ccw_adapter_put(adapter); ++err_out: + return ERR_PTR(retval); + } diff --git a/queue-6.5/series b/queue-6.5/series index 5ac9950abdf..ef55352b566 100644 --- a/queue-6.5/series +++ b/queue-6.5/series @@ -23,3 +23,34 @@ net-release-reference-to-inet6_dev-pointer.patch iommu-arm-smmu-v3-avoid-constructing-invalid-range-c.patch maple_tree-reduce-resets-during-store-setup.patch maple_tree-add-mas_underflow-and-mas_overflow-states.patch +iommu-apple-dart-handle-dma_fq-domains-in-attach_dev.patch +scsi-zfcp-fix-a-double-put-in-zfcp_port_enqueue.patch +iommu-vt-d-avoid-memory-allocation-in-iommu_suspend.patch +net-mana-fix-tx-cqe-error-handling.patch +vringh-don-t-use-vringh_kiov_advance-in-vringh_iov_xfer.patch +net-ethernet-mediatek-disable-irq-before-schedule-napi.patch +mptcp-fix-delegated-action-races.patch +mptcp-userspace-pm-allow-creating-id-0-subflow.patch +qed-red_ll2-fix-undefined-behavior-bug-in-struct-qed_ll2_info.patch +net-mana-fix-the-tso_bytes-calculation.patch +bluetooth-hci_codec-fix-leaking-content-of-local_codecs.patch +wifi-brcmfmac-replace-1-element-arrays-with-flexible-arrays.patch +bluetooth-hci_sync-fix-handling-of-hci_quirk_strict_duplicate_filter.patch +wifi-rtw88-rtw8723d-fix-mac-address-offset-in-eeprom.patch +wifi-mwifiex-fix-tlv_buf_left-calculation.patch +io_uring-don-t-allow-ioring_setup_no_mmap-rings-on-highmem-pages.patch +md-raid5-release-batch_last-before-waiting-for-another-stripe_head.patch +pci-pm-mark-devices-disconnected-if-upstream-pcie-link-is-down-on-resume.patch +pci-qcom-fix-ipq8074-enumeration.patch +platform-x86-intel-ifs-release-cpus_read_lock.patch +net-replace-calls-to-sock-ops-connect-with-kernel_connect.patch +io_uring-kbuf-don-t-allow-registered-buffer-rings-on-highmem-pages.patch +io_uring-ensure-io_lockdep_assert_cq_locked-handles-disabled-rings.patch +btrfs-always-print-transaction-aborted-messages-with-an-error-level.patch +btrfs-reject-unknown-mount-options-early.patch +net-prevent-rewrite-of-msg_name-in-sock_sendmsg.patch +drm-i915-don-t-set-pipe_control_flush_l3-for-aux-inval.patch +drm-amd-fix-detection-of-_pr3-on-the-pcie-root-port.patch +drm-amd-fix-logic-error-in-sienna_cichlid_update_pcie_parameters.patch +arm64-add-cortex-a520-cpu-part-definition.patch +arm64-errata-add-cortex-a520-speculative-unprivileged-load-workaround.patch diff --git a/queue-6.5/vringh-don-t-use-vringh_kiov_advance-in-vringh_iov_xfer.patch b/queue-6.5/vringh-don-t-use-vringh_kiov_advance-in-vringh_iov_xfer.patch new file mode 100644 index 00000000000..396c64283af --- /dev/null +++ b/queue-6.5/vringh-don-t-use-vringh_kiov_advance-in-vringh_iov_xfer.patch @@ -0,0 +1,52 @@ +From 7aed44babc7f97e82b38e9a68515e699692cc100 Mon Sep 17 00:00:00 2001 +From: Stefano Garzarella +Date: Mon, 25 Sep 2023 12:30:57 +0200 +Subject: vringh: don't use vringh_kiov_advance() in vringh_iov_xfer() + +From: Stefano Garzarella + +commit 7aed44babc7f97e82b38e9a68515e699692cc100 upstream. + +In the while loop of vringh_iov_xfer(), `partlen` could be 0 if one of +the `iov` has 0 lenght. +In this case, we should skip the iov and go to the next one. +But calling vringh_kiov_advance() with 0 lenght does not cause the +advancement, since it returns immediately if asked to advance by 0 bytes. + +Let's restore the code that was there before commit b8c06ad4d67d +("vringh: implement vringh_kiov_advance()"), avoiding using +vringh_kiov_advance(). + +Fixes: b8c06ad4d67d ("vringh: implement vringh_kiov_advance()") +Cc: stable@vger.kernel.org +Reported-by: Jason Wang +Signed-off-by: Stefano Garzarella +Acked-by: Jason Wang +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/vhost/vringh.c | 12 +++++++++++- + 1 file changed, 11 insertions(+), 1 deletion(-) + +--- a/drivers/vhost/vringh.c ++++ b/drivers/vhost/vringh.c +@@ -123,8 +123,18 @@ static inline ssize_t vringh_iov_xfer(st + done += partlen; + len -= partlen; + ptr += partlen; ++ iov->consumed += partlen; ++ iov->iov[iov->i].iov_len -= partlen; ++ iov->iov[iov->i].iov_base += partlen; + +- vringh_kiov_advance(iov, partlen); ++ if (!iov->iov[iov->i].iov_len) { ++ /* Fix up old iov element then increment. */ ++ iov->iov[iov->i].iov_len = iov->consumed; ++ iov->iov[iov->i].iov_base -= iov->consumed; ++ ++ iov->consumed = 0; ++ iov->i++; ++ } + } + return done; + } diff --git a/queue-6.5/wifi-brcmfmac-replace-1-element-arrays-with-flexible-arrays.patch b/queue-6.5/wifi-brcmfmac-replace-1-element-arrays-with-flexible-arrays.patch new file mode 100644 index 00000000000..5b78fe0b29d --- /dev/null +++ b/queue-6.5/wifi-brcmfmac-replace-1-element-arrays-with-flexible-arrays.patch @@ -0,0 +1,69 @@ +From 4fed494abcd4fde5c24de19160e93814f912fdb3 Mon Sep 17 00:00:00 2001 +From: Juerg Haefliger +Date: Thu, 14 Sep 2023 09:02:27 +0200 +Subject: wifi: brcmfmac: Replace 1-element arrays with flexible arrays + +From: Juerg Haefliger + +commit 4fed494abcd4fde5c24de19160e93814f912fdb3 upstream. + +Since commit 2d47c6956ab3 ("ubsan: Tighten UBSAN_BOUNDS on GCC"), +UBSAN_BOUNDS no longer pretends 1-element arrays are unbounded. Walking +'element' and 'channel_list' will trigger warnings, so make them proper +flexible arrays. + +False positive warnings were: + + UBSAN: array-index-out-of-bounds in drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:6984:20 + index 1 is out of range for type '__le32 [1]' + + UBSAN: array-index-out-of-bounds in drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:1126:27 + index 1 is out of range for type '__le16 [1]' + +for these lines of code: + + 6884 ch.chspec = (u16)le32_to_cpu(list->element[i]); + + 1126 params_le->channel_list[i] = cpu_to_le16(chanspec); + +Cc: stable@vger.kernel.org # 6.5+ +Signed-off-by: Juerg Haefliger +Reviewed-by: Kees Cook +Reviewed-by: Gustavo A. R. Silva +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/20230914070227.12028-1-juerg.haefliger@canonical.com +Signed-off-by: Greg Kroah-Hartman +--- + .../wireless/broadcom/brcm80211/brcmfmac/fwil_types.h | 9 +++++++-- + 1 file changed, 7 insertions(+), 2 deletions(-) + +diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h +index bece26741d3a..611d1a6aabb9 100644 +--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h ++++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwil_types.h +@@ -442,7 +442,12 @@ struct brcmf_scan_params_v2_le { + * fixed parameter portion is assumed, otherwise + * ssid in the fixed portion is ignored + */ +- __le16 channel_list[1]; /* list of chanspecs */ ++ union { ++ __le16 padding; /* Reserve space for at least 1 entry for abort ++ * which uses an on stack brcmf_scan_params_v2_le ++ */ ++ DECLARE_FLEX_ARRAY(__le16, channel_list); /* chanspecs */ ++ }; + }; + + struct brcmf_scan_results { +@@ -702,7 +707,7 @@ struct brcmf_sta_info_le { + + struct brcmf_chanspec_list { + __le32 count; /* # of entries */ +- __le32 element[1]; /* variable length uint32 list */ ++ __le32 element[]; /* variable length uint32 list */ + }; + + /* +-- +2.42.0 + diff --git a/queue-6.5/wifi-mwifiex-fix-tlv_buf_left-calculation.patch b/queue-6.5/wifi-mwifiex-fix-tlv_buf_left-calculation.patch new file mode 100644 index 00000000000..8c16d3c8a87 --- /dev/null +++ b/queue-6.5/wifi-mwifiex-fix-tlv_buf_left-calculation.patch @@ -0,0 +1,103 @@ +From eec679e4ac5f47507774956fb3479c206e761af7 Mon Sep 17 00:00:00 2001 +From: "Gustavo A. R. Silva" +Date: Thu, 24 Aug 2023 21:06:51 -0600 +Subject: wifi: mwifiex: Fix tlv_buf_left calculation + +From: Gustavo A. R. Silva + +commit eec679e4ac5f47507774956fb3479c206e761af7 upstream. + +In a TLV encoding scheme, the Length part represents the length after +the header containing the values for type and length. In this case, +`tlv_len` should be: + +tlv_len == (sizeof(*tlv_rxba) - 1) - sizeof(tlv_rxba->header) + tlv_bitmap_len + +Notice that the `- 1` accounts for the one-element array `bitmap`, which +1-byte size is already included in `sizeof(*tlv_rxba)`. + +So, if the above is correct, there is a double-counting of some members +in `struct mwifiex_ie_types_rxba_sync`, when `tlv_buf_left` and `tmp` +are calculated: + +968 tlv_buf_left -= (sizeof(*tlv_rxba) + tlv_len); +969 tmp = (u8 *)tlv_rxba + tlv_len + sizeof(*tlv_rxba); + +in specific, members: + +drivers/net/wireless/marvell/mwifiex/fw.h:777 + 777 u8 mac[ETH_ALEN]; + 778 u8 tid; + 779 u8 reserved; + 780 __le16 seq_num; + 781 __le16 bitmap_len; + +This is clearly wrong, and affects the subsequent decoding of data in +`event_buf` through `tlv_rxba`: + +970 tlv_rxba = (struct mwifiex_ie_types_rxba_sync *)tmp; + +Fix this by using `sizeof(tlv_rxba->header)` instead of `sizeof(*tlv_rxba)` +in the calculation of `tlv_buf_left` and `tmp`. + +This results in the following binary differences before/after changes: + +| drivers/net/wireless/marvell/mwifiex/11n_rxreorder.o +| @@ -4698,11 +4698,11 @@ +| drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c:968 +| tlv_buf_left -= (sizeof(tlv_rxba->header) + tlv_len); +| - 1da7: lea -0x11(%rbx),%edx +| + 1da7: lea -0x4(%rbx),%edx +| 1daa: movzwl %bp,%eax +| drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c:969 +| tmp = (u8 *)tlv_rxba + sizeof(tlv_rxba->header) + tlv_len; +| - 1dad: lea 0x11(%r15,%rbp,1),%r15 +| + 1dad: lea 0x4(%r15,%rbp,1),%r15 + +The above reflects the desired change: avoid counting 13 too many bytes; +which is the total size of the double-counted members in +`struct mwifiex_ie_types_rxba_sync`: + +$ pahole -C mwifiex_ie_types_rxba_sync drivers/net/wireless/marvell/mwifiex/11n_rxreorder.o +struct mwifiex_ie_types_rxba_sync { + struct mwifiex_ie_types_header header; /* 0 4 */ + + |----------------------------------------------------------------------- + | u8 mac[6]; /* 4 6 */ | + | u8 tid; /* 10 1 */ | + | u8 reserved; /* 11 1 */ | + | __le16 seq_num; /* 12 2 */ | + | __le16 bitmap_len; /* 14 2 */ | + | u8 bitmap[1]; /* 16 1 */ | + |----------------------------------------------------------------------| + | 13 bytes| + ----------- + + /* size: 17, cachelines: 1, members: 7 */ + /* last cacheline: 17 bytes */ +} __attribute__((__packed__)); + +Fixes: 99ffe72cdae4 ("mwifiex: process rxba_sync event") +Cc: stable@vger.kernel.org +Signed-off-by: Gustavo A. R. Silva +Reviewed-by: Kees Cook +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/06668edd68e7a26bbfeebd1201ae077a2a7a8bce.1692931954.git.gustavoars@kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c ++++ b/drivers/net/wireless/marvell/mwifiex/11n_rxreorder.c +@@ -965,8 +965,8 @@ void mwifiex_11n_rxba_sync_event(struct + } + } + +- tlv_buf_left -= (sizeof(*tlv_rxba) + tlv_len); +- tmp = (u8 *)tlv_rxba + tlv_len + sizeof(*tlv_rxba); ++ tlv_buf_left -= (sizeof(tlv_rxba->header) + tlv_len); ++ tmp = (u8 *)tlv_rxba + sizeof(tlv_rxba->header) + tlv_len; + tlv_rxba = (struct mwifiex_ie_types_rxba_sync *)tmp; + } + } diff --git a/queue-6.5/wifi-rtw88-rtw8723d-fix-mac-address-offset-in-eeprom.patch b/queue-6.5/wifi-rtw88-rtw8723d-fix-mac-address-offset-in-eeprom.patch new file mode 100644 index 00000000000..4cc61b18b9a --- /dev/null +++ b/queue-6.5/wifi-rtw88-rtw8723d-fix-mac-address-offset-in-eeprom.patch @@ -0,0 +1,39 @@ +From 2e1b3ae3e1f2cf5a3c9c05d5f961d7d4257b489f Mon Sep 17 00:00:00 2001 +From: Sascha Hauer +Date: Thu, 7 Sep 2023 09:16:14 +0200 +Subject: wifi: rtw88: rtw8723d: Fix MAC address offset in EEPROM + +From: Sascha Hauer + +commit 2e1b3ae3e1f2cf5a3c9c05d5f961d7d4257b489f upstream. + +The MAC address is stored at offset 0x107 in the EEPROM, like correctly +stated in the comment. Add a two bytes reserved field right before the +MAC address to shift it from offset 0x105 to 0x107. + +With this the MAC address returned from my RTL8723du wifi stick can be +correctly decoded as "Shenzhen Four Seas Global Link Network Technology +Co., Ltd." + +Fixes: 87caeef032fc ("wifi: rtw88: Add rtw8723du chipset support") +Signed-off-by: Sascha Hauer +Reported-by: Yanik Fuchs +Cc: stable@vger.kernel.org +Acked-by: Ping-Ke Shih +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/20230907071614.2032404-1-s.hauer@pengutronix.de +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/wireless/realtek/rtw88/rtw8723d.h | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/net/wireless/realtek/rtw88/rtw8723d.h ++++ b/drivers/net/wireless/realtek/rtw88/rtw8723d.h +@@ -46,6 +46,7 @@ struct rtw8723du_efuse { + u8 vender_id[2]; /* 0x100 */ + u8 product_id[2]; /* 0x102 */ + u8 usb_option; /* 0x104 */ ++ u8 res5[2]; /* 0x105 */ + u8 mac_addr[ETH_ALEN]; /* 0x107 */ + }; +