--- /dev/null
+From a654a69b9f9c06b2e56387d0b99f0e3e6b0ff4ef Mon Sep 17 00:00:00 2001
+From: Rob Herring <robh@kernel.org>
+Date: Thu, 21 Sep 2023 14:41:51 -0500
+Subject: arm64: Add Cortex-A520 CPU part definition
+
+From: Rob Herring <robh@kernel.org>
+
+commit a654a69b9f9c06b2e56387d0b99f0e3e6b0ff4ef upstream.
+
+Add the CPU Part number for the new Arm design.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Rob Herring <robh@kernel.org>
+Link: https://lore.kernel.org/r/20230921194156.1050055-1-robh@kernel.org
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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)
--- /dev/null
+From 471470bc7052d28ce125901877dd10e4c048e513 Mon Sep 17 00:00:00 2001
+From: Rob Herring <robh@kernel.org>
+Date: Thu, 21 Sep 2023 14:41:52 -0500
+Subject: arm64: errata: Add Cortex-A520 speculative unprivileged load workaround
+
+From: Rob Herring <robh@kernel.org>
+
+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 <robh@kernel.org>
+Link: https://lore.kernel.org/r/20230921194156.1050055-2-robh@kernel.org
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
--- /dev/null
+From b938790e70540bf4f2e653dcd74b232494d06c8f Mon Sep 17 00:00:00 2001
+From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Date: Fri, 15 Sep 2023 13:24:47 -0700
+Subject: Bluetooth: hci_codec: Fix leaking content of local_codecs
+
+From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+
+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:
+ [<ffffffffb324f557>] __kmalloc+0x47/0x120
+ [<ffffffffb39ef37d>] hci_codec_list_add.isra.0+0x2d/0x160
+ [<ffffffffb39ef643>] hci_read_codec_capabilities+0x183/0x270
+ [<ffffffffb39ef9ab>] hci_read_supported_codecs+0x1bb/0x2d0
+ [<ffffffffb39f162e>] hci_read_local_codecs_sync+0x3e/0x60
+ [<ffffffffb39ff1b3>] hci_dev_open_sync+0x943/0x11e0
+ [<ffffffffb396d55d>] hci_power_on+0x10d/0x3f0
+ [<ffffffffb30c99b4>] process_one_work+0x404/0x800
+ [<ffffffffb30ca134>] worker_thread+0x374/0x670
+ [<ffffffffb30d9108>] kthread+0x188/0x1c0
+ [<ffffffffb304db6b>] ret_from_fork+0x2b/0x50
+ [<ffffffffb300206a>] 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 <luiz.von.dentz@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From 941c998b42f5c90384f49da89a6e11233de567cf Mon Sep 17 00:00:00 2001
+From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+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 <luiz.von.dentz@intel.com>
+
+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 <luiz.von.dentz@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From f8d1b011ca8c9d64ce32da431a8420635a96958a Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Tue, 26 Sep 2023 19:31:19 +0100
+Subject: btrfs: always print transaction aborted messages with an error level
+
+From: Filipe Manana <fdmanana@suse.com>
+
+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 <wqu@suse.com>
+Signed-off-by: Filipe Manana <fdmanana@suse.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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)); \
+ } \
+ } \
--- /dev/null
+From 5f521494cc73520ffac18ede0758883b9aedd018 Mon Sep 17 00:00:00 2001
+From: Qu Wenruo <wqu@suse.com>
+Date: Wed, 27 Sep 2023 10:43:15 +0930
+Subject: btrfs: reject unknown mount options early
+
+From: Qu Wenruo <wqu@suse.com>
+
+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 <anand.jain@oracle.com>
+CC: stable@vger.kernel.org # 4.14+
+Signed-off-by: Qu Wenruo <wqu@suse.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
--- /dev/null
+From 134b8c5d8674e7cde380f82e9aedfd46dcdd16f7 Mon Sep 17 00:00:00 2001
+From: Mario Limonciello <mario.limonciello@amd.com>
+Date: Tue, 26 Sep 2023 17:59:53 -0500
+Subject: drm/amd: Fix detection of _PR3 on the PCIe root port
+
+From: Mario Limonciello <mario.limonciello@amd.com>
+
+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 <Jun.Ma2@amd.com>
+Tested-by: David Perry <David.Perry@amd.com>
+Fixes: b10c1c5b3a4e ("drm/amdgpu: add check for ACPI power resources")
+Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
+Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
+
--- /dev/null
+From 2a1fe39a5be785e962e387146aed34fa9a829f3f Mon Sep 17 00:00:00 2001
+From: Mario Limonciello <mario.limonciello@amd.com>
+Date: Tue, 26 Sep 2023 21:07:43 -0500
+Subject: drm/amd: Fix logic error in sienna_cichlid_update_pcie_parameters()
+
+From: Mario Limonciello <mario.limonciello@amd.com>
+
+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 <coelacanth_dream@protonmail.com>
+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 <mario.limonciello@amd.com>
+Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 |
--- /dev/null
+From 128c20eda73bd3e78505c574fb17adb46195c98b Mon Sep 17 00:00:00 2001
+From: Nirmoy Das <nirmoy.das@intel.com>
+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 <nirmoy.das@intel.com>
+
+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 <jonathan.cavitt@intel.com>
+Cc: Andi Shyti <andi.shyti@linux.intel.com>
+Cc: <stable@vger.kernel.org> # v5.8+
+Cc: Andrzej Hajda <andrzej.hajda@intel.com>
+Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
+Cc: Matt Roper <matthew.d.roper@intel.com>
+Cc: Tejas Upadhyay <tejas.upadhyay@intel.com>
+Cc: Lucas De Marchi <lucas.demarchi@intel.com>
+Cc: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com>
+Cc: Tapani Pälli <tapani.palli@intel.com>
+Cc: Mark Janes <mark.janes@intel.com>
+Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
+Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
+Acked-by: Matt Roper <matthew.d.roper@intel.com>
+Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
+Tested-by: Tapani Pälli <tapani.palli@intel.com>
+Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20230926142401.25687-1-nirmoy.das@intel.com
+(cherry picked from commit 03d681412b38558aefe4fb0f46e36efa94bb21ef)
+Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 */
--- /dev/null
+From 223ef474316466e9f61f6e0064f3a6fe4923a2c5 Mon Sep 17 00:00:00 2001
+From: Jens Axboe <axboe@kernel.dk>
+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 <axboe@kernel.dk>
+
+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 <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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]);
--- /dev/null
+From 1658633c04653578429ff5dfc62fdc159203a8f2 Mon Sep 17 00:00:00 2001
+From: Jens Axboe <axboe@kernel.dk>
+Date: Mon, 2 Oct 2023 19:51:38 -0600
+Subject: io_uring: ensure io_lockdep_assert_cq_locked() handles disabled rings
+
+From: Jens Axboe <axboe@kernel.dk>
+
+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 <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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)
+ {
--- /dev/null
+From f8024f1f36a30a082b0457d5779c8847cea57f57 Mon Sep 17 00:00:00 2001
+From: Jens Axboe <axboe@kernel.dk>
+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 <axboe@kernel.dk>
+
+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 <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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,
--- /dev/null
+From c7bd8a1f45bada7725d11266df7fd5cb549b3098 Mon Sep 17 00:00:00 2001
+From: Hector Martin <marcan@marcan.st>
+Date: Fri, 22 Sep 2023 23:55:23 +0900
+Subject: iommu/apple-dart: Handle DMA_FQ domains in attach_dev()
+
+From: Hector Martin <marcan@marcan.st>
+
+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 <robin.murphy@arm.com>
+Fixes: a4fdd9762272 ("iommu: Use flush queue capability")
+Signed-off-by: Hector Martin <marcan@marcan.st>
+Reviewed-by: Neal Gompa <neal@gompa.dev>
+Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
+Link: https://lore.kernel.org/r/20230922-iommu-type-regression-v2-1-689b2ba9b673@marcan.st
+Signed-off-by: Joerg Roedel <jroedel@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+
--- /dev/null
+From 59df44bfb0ca4c3ee1f1c3c5d0ee8e314844799e Mon Sep 17 00:00:00 2001
+From: Zhang Rui <rui.zhang@intel.com>
+Date: Mon, 25 Sep 2023 20:04:17 +0800
+Subject: iommu/vt-d: Avoid memory allocation in iommu_suspend()
+
+From: Zhang Rui <rui.zhang@intel.com>
+
+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:
+ <IRQ>
+ 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
+ </IRQ>
+ <TASK>
+ 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:
+ <TASK>
+ 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 <rui.zhang@intel.com>
+Tested-by: Ooi, Chin Hao <chin.hao.ooi@intel.com>
+Link: https://lore.kernel.org/r/20230921093956.234692-1-rui.zhang@intel.com
+Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
+Link: https://lore.kernel.org/r/20230925120417.55977-2-baolu.lu@linux.intel.com
+Signed-off-by: Joerg Roedel <jroedel@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 */
--- /dev/null
+From 2fd7b0f6d5ad655b1d947d3acdd82f687c31465e Mon Sep 17 00:00:00 2001
+From: David Jeffery <djeffery@redhat.com>
+Date: Mon, 2 Oct 2023 14:32:29 -0400
+Subject: md/raid5: release batch_last before waiting for another stripe_head
+
+From: David Jeffery <djeffery@redhat.com>
+
+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 <djeffery@redhat.com>
+Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
+Signed-off-by: Song Liu <song@kernel.org>
+Link: https://lore.kernel.org/r/20231002183422.13047-1-djeffery@redhat.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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));
--- /dev/null
+From a5efdbcece83af94180e8d7c0a6e22947318499d Mon Sep 17 00:00:00 2001
+From: Paolo Abeni <pabeni@redhat.com>
+Date: Wed, 4 Oct 2023 13:38:11 -0700
+Subject: mptcp: fix delegated action races
+
+From: Paolo Abeni <pabeni@redhat.com>
+
+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 <martineau@kernel.org>
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Mat Martineau <martineau@kernel.org>
+Link: https://lore.kernel.org/r/20231004-send-net-20231004-v1-1-28de4ac663ae@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+ }
--- /dev/null
+From e5ed101a602873d65d2d64edaba93e8c73ec1b0f Mon Sep 17 00:00:00 2001
+From: Geliang Tang <geliang.tang@suse.com>
+Date: Wed, 4 Oct 2023 13:38:12 -0700
+Subject: mptcp: userspace pm allow creating id 0 subflow
+
+From: Geliang Tang <geliang.tang@suse.com>
+
+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 <matthieu.baerts@tessares.net>
+Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net>
+Signed-off-by: Geliang Tang <geliang.tang@suse.com>
+Signed-off-by: Mat Martineau <martineau@kernel.org>
+Link: https://lore.kernel.org/r/20231004-send-net-20231004-v1-2-28de4ac663ae@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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");
--- /dev/null
+From fcdfc462881d8acf9db77f483b2c821e286ca97b Mon Sep 17 00:00:00 2001
+From: Christian Marangi <ansuelsmth@gmail.com>
+Date: Mon, 2 Oct 2023 16:08:05 +0200
+Subject: net: ethernet: mediatek: disable irq before schedule napi
+
+From: Christian Marangi <ansuelsmth@gmail.com>
+
+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 <ansuelsmth@gmail.com>
+Link: https://lore.kernel.org/r/20231002140805.568-1-ansuelsmth@gmail.com
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From 7a54de92657455210d0ca71d4176b553952c871a Mon Sep 17 00:00:00 2001
+From: Haiyang Zhang <haiyangz@microsoft.com>
+Date: Fri, 29 Sep 2023 13:42:26 -0700
+Subject: net: mana: Fix the tso_bytes calculation
+
+From: Haiyang Zhang <haiyangz@microsoft.com>
+
+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 <haiyangz@microsoft.com>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Reviewed-by: Shradha Gupta <shradhagupta@linux.microsoft.com>
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From b2b000069a4c307b09548dc2243f31f3ca0eac9c Mon Sep 17 00:00:00 2001
+From: Haiyang Zhang <haiyangz@microsoft.com>
+Date: Fri, 29 Sep 2023 13:42:25 -0700
+Subject: net: mana: Fix TX CQE error handling
+
+From: Haiyang Zhang <haiyangz@microsoft.com>
+
+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 <haiyangz@microsoft.com>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Reviewed-by: Shradha Gupta <shradhagupta@linux.microsoft.com>
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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))
--- /dev/null
+From 86a7e0b69bd5b812e48a20c66c2161744f3caa16 Mon Sep 17 00:00:00 2001
+From: Jordan Rife <jrife@google.com>
+Date: Thu, 21 Sep 2023 18:46:41 -0500
+Subject: net: prevent rewrite of msg_name in sock_sendmsg()
+
+From: Jordan Rife <jrife@google.com>
+
+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 <willemb@google.com>
+Signed-off-by: Jordan Rife <jrife@google.com>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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.
--- /dev/null
+From 26297b4ce1ce4ea40bc9a48ec99f45da3f64d2e2 Mon Sep 17 00:00:00 2001
+From: Jordan Rife <jrife@google.com>
+Date: Thu, 21 Sep 2023 18:46:40 -0500
+Subject: net: replace calls to sock->ops->connect() with kernel_connect()
+
+From: Jordan Rife <jrife@google.com>
+
+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 <willemb@google.com>
+Signed-off-by: Jordan Rife <jrife@google.com>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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)
--- /dev/null
+From c82458101d5490230d735caecce14c9c27b1010c Mon Sep 17 00:00:00 2001
+From: Mika Westerberg <mika.westerberg@linux.intel.com>
+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 <mika.westerberg@linux.intel.com>
+
+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 <mark.blakeney@bullet-systems.net>
+Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217915
+Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Reviewed-by: Lukas Wunner <lukas@wunner.de>
+Cc: stable@vger.kernel.org # v6.4+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+
--- /dev/null
+From 6a878a54d0053ef21f3b829dc267487c2302b012 Mon Sep 17 00:00:00 2001
+From: Sricharan Ramabadhran <quic_srichara@quicinc.com>
+Date: Tue, 19 Sep 2023 15:59:48 +0530
+Subject: PCI: qcom: Fix IPQ8074 enumeration
+
+From: Sricharan Ramabadhran <quic_srichara@quicinc.com>
+
+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 <robimarko@gmail.com>
+Signed-off-by: Sricharan Ramabadhran <quic_srichara@quicinc.com>
+[bhelgaas: commit log]
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
+Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
+Cc: stable@vger.kernel.org # v6.4+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From 2545deba314eec91dc5ca1a954fe97f91ef1cf07 Mon Sep 17 00:00:00 2001
+From: Jithu Joseph <jithu.joseph@intel.com>
+Date: Wed, 27 Sep 2023 11:48:24 -0700
+Subject: platform/x86/intel/ifs: release cpus_read_lock()
+
+From: Jithu Joseph <jithu.joseph@intel.com>
+
+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 <jithu.joseph@intel.com>
+Link: https://lore.kernel.org/r/20230927184824.2566086-1-jithu.joseph@intel.com
+Reviewed-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+
--- /dev/null
+From eea03d18af9c44235865a4bc9bec4d780ef6cf21 Mon Sep 17 00:00:00 2001
+From: "Gustavo A. R. Silva" <gustavoars@kernel.org>
+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 <gustavoars@kernel.org>
+
+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 <gustavoars@kernel.org>
+Reviewed-by: Kees Cook <keescook@chromium.org>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Link: https://lore.kernel.org/r/ZQ+Nz8DfPg56pIzr@work
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From b481f644d9174670b385c3a699617052cd2a79d3 Mon Sep 17 00:00:00 2001
+From: Dinghao Liu <dinghao.liu@zju.edu.cn>
+Date: Sat, 23 Sep 2023 18:37:23 +0800
+Subject: scsi: zfcp: Fix a double put in zfcp_port_enqueue()
+
+From: Dinghao Liu <dinghao.liu@zju.edu.cn>
+
+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 <dinghao.liu@zju.edu.cn>
+Link: https://lore.kernel.org/r/20230923103723.10320-1-dinghao.liu@zju.edu.cn
+Acked-by: Benjamin Block <bblock@linux.ibm.com>
+Cc: stable@vger.kernel.org # v2.6.33+
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+ }
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
--- /dev/null
+From 7aed44babc7f97e82b38e9a68515e699692cc100 Mon Sep 17 00:00:00 2001
+From: Stefano Garzarella <sgarzare@redhat.com>
+Date: Mon, 25 Sep 2023 12:30:57 +0200
+Subject: vringh: don't use vringh_kiov_advance() in vringh_iov_xfer()
+
+From: Stefano Garzarella <sgarzare@redhat.com>
+
+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 <jasowang@redhat.com>
+Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
+Acked-by: Jason Wang <jasowang@redhat.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
--- /dev/null
+From 4fed494abcd4fde5c24de19160e93814f912fdb3 Mon Sep 17 00:00:00 2001
+From: Juerg Haefliger <juerg.haefliger@canonical.com>
+Date: Thu, 14 Sep 2023 09:02:27 +0200
+Subject: wifi: brcmfmac: Replace 1-element arrays with flexible arrays
+
+From: Juerg Haefliger <juerg.haefliger@canonical.com>
+
+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 <juerg.haefliger@canonical.com>
+Reviewed-by: Kees Cook <keescook@chromium.org>
+Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
+Signed-off-by: Kalle Valo <kvalo@kernel.org>
+Link: https://lore.kernel.org/r/20230914070227.12028-1-juerg.haefliger@canonical.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ .../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
+
--- /dev/null
+From eec679e4ac5f47507774956fb3479c206e761af7 Mon Sep 17 00:00:00 2001
+From: "Gustavo A. R. Silva" <gustavoars@kernel.org>
+Date: Thu, 24 Aug 2023 21:06:51 -0600
+Subject: wifi: mwifiex: Fix tlv_buf_left calculation
+
+From: Gustavo A. R. Silva <gustavoars@kernel.org>
+
+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 <gustavoars@kernel.org>
+Reviewed-by: Kees Cook <keescook@chromium.org>
+Signed-off-by: Kalle Valo <kvalo@kernel.org>
+Link: https://lore.kernel.org/r/06668edd68e7a26bbfeebd1201ae077a2a7a8bce.1692931954.git.gustavoars@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
+ }
--- /dev/null
+From 2e1b3ae3e1f2cf5a3c9c05d5f961d7d4257b489f Mon Sep 17 00:00:00 2001
+From: Sascha Hauer <s.hauer@pengutronix.de>
+Date: Thu, 7 Sep 2023 09:16:14 +0200
+Subject: wifi: rtw88: rtw8723d: Fix MAC address offset in EEPROM
+
+From: Sascha Hauer <s.hauer@pengutronix.de>
+
+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 <s.hauer@pengutronix.de>
+Reported-by: Yanik Fuchs <Yanik.fuchs@mbv.ch>
+Cc: stable@vger.kernel.org
+Acked-by: Ping-Ke Shih <pkshih@realtek.com>
+Signed-off-by: Kalle Valo <kvalo@kernel.org>
+Link: https://lore.kernel.org/r/20230907071614.2032404-1-s.hauer@pengutronix.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 */
+ };
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
