From: Greg Kroah-Hartman Date: Mon, 14 Oct 2024 12:33:10 +0000 (+0200) Subject: 6.11-stable patches X-Git-Tag: v5.10.227~31 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=67268995094a7ddfb14170699c3282bc8b2739ed;p=thirdparty%2Fkernel%2Fstable-queue.git 6.11-stable patches added patches: acpi-resource-make-asus-expertbook-b2402-matches-cover-more-models.patch acpi-resource-make-asus-expertbook-b2502-matches-cover-more-models.patch ata-libata-avoid-superfluous-disk-spin-down-spin-up-during-hibernation.patch bluetooth-hci_conn-fix-uaf-in-hci_enhanced_setup_sync.patch btrfs-add-cancellation-points-to-trim-loops.patch btrfs-split-remaining-space-to-discard-in-chunks.patch device-dax-correct-pgoff-align-in-dax_set_mapping.patch drm-amd-display-clear-update-flags-after-update-has-been-applied.patch drm-amd-display-fix-hibernate-entry-for-dcn35.patch drm-amdgpu-partially-revert-powerplay-__counted_by-changes.patch drm-amdkfd-fix-an-eviction-fence-leak.patch drm-i915-hdcp-fix-connector-refcounting.patch drm-v3d-stop-the-active-perfmon-before-being-destroyed.patch drm-vc4-stop-the-active-perfmon-before-being-destroyed.patch drm-xe-ct-fix-xa_store-error-checking.patch drm-xe-ct-prevent-uaf-in-send_recv.patch drm-xe-guc_submit-fix-xa_store-error-checking.patch fs-proc-kcore.c-allow-translation-of-physical-memory-addresses.patch ice-fix-improper-handling-of-refcount-in-ice_dpll_init_rclk_pins.patch ice-fix-improper-handling-of-refcount-in-ice_sriov_set_msix_vec_count.patch idpf-use-actual-mbx-receive-payload-length.patch kthread-unpark-only-parked-kthread.patch mmc-sdhci-of-dwcmshc-prevent-stale-command-interrupt-handling.patch mptcp-fallback-when-mptcp-opts-are-dropped-after-1st-data.patch mptcp-handle-consistently-dss-corruption.patch mptcp-pm-do-not-remove-closing-subflows.patch net-dsa-lan9303-ensure-chip-reset-and-wait-for-ready-status.patch net-explicitly-clear-the-sk-pointer-when-pf-create-fails.patch net-fix-an-unsafe-loop-on-the-list.patch net-phy-realtek-fix-mmd-access-on-rtl8126a-integrated-phy.patch net-phy-remove-led-entry-from-leds-list-on-unregister.patch nouveau-dmem-fix-vulnerability-in-migrate_to_ram-upon-copy-error.patch opp-fix-error-code-in-dev_pm_opp_set_config.patch pm-domains-fix-alloc-free-in-dev_pm_domain_attach-detach_list.patch powercap-intel_rapl_tpmi-fix-bogus-register-reading.patch revert-mmc-mvsdio-use-sg_miter-for-pio.patch scsi-fnic-move-flush_work-initialization-out-of-if-block.patch scsi-ufs-use-pre-calculated-offsets-in-ufshcd_init_lrb.patch scsi-wd33c93-don-t-use-stale-scsi_pointer-value.patch secretmem-disable-memfd_secret-if-arch-cannot-set-direct-map.patch selftests-mm-fix-incorrect-buffer-mirror-size-in-hmm2-double_map-test.patch selftests-rseq-fix-mm_cid-test-failure.patch thermal-core-free-tzp-copy-along-with-the-thermal-zone.patch thermal-core-reference-count-the-zone-in-thermal_zone_get_by_id.patch --- diff --git a/queue-6.11/acpi-resource-make-asus-expertbook-b2402-matches-cover-more-models.patch b/queue-6.11/acpi-resource-make-asus-expertbook-b2402-matches-cover-more-models.patch new file mode 100644 index 00000000000..714b4921580 --- /dev/null +++ b/queue-6.11/acpi-resource-make-asus-expertbook-b2402-matches-cover-more-models.patch @@ -0,0 +1,62 @@ +From 564a278573783cd8859829767851744087e676d8 Mon Sep 17 00:00:00 2001 +From: Hans de Goede +Date: Sat, 5 Oct 2024 23:28:16 +0200 +Subject: ACPI: resource: Make Asus ExpertBook B2402 matches cover more models + +From: Hans de Goede + +commit 564a278573783cd8859829767851744087e676d8 upstream. + +The Asus ExpertBook B2402CBA / B2402FBA are the non flip / flip versions +of the 14" Asus ExpertBook B2 with 12th gen Intel processors. + +It has been reported that the B2402FVA which is the 14" Asus ExpertBook +B2 flip with 13th gen Intel processors needs to skip the IRQ override too. + +And looking at Asus website there also is a B2402CVA which is the non flip +model with 13th gen Intel processors. + +Summarizing the following 4 models of the Asus ExpertBook B2 are known: + +B2402CBA: 12th gen Intel CPU, non flip +B2402FBA: 12th gen Intel CPU, flip +B2402CVA: 13th gen Intel CPU, non flip +B2402FVA: 13th gen Intel CPU, flip + +Fold the 2 existing quirks for the B2402CBA and B2402FBA into a single +quirk covering B2402* to also cover the 2 other models while at the same +time reducing the number of quirks. + +Reported-by: Stefan Blum +Closes: https://lore.kernel.org/platform-driver-x86/a983e6d5-c7ab-4758-be9b-7dcfc1b44ed3@gmail.com/ +Cc: All applicable +Signed-off-by: Hans de Goede +Link: https://patch.msgid.link/20241005212819.354681-2-hdegoede@redhat.com +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + drivers/acpi/resource.c | 11 ++--------- + 1 file changed, 2 insertions(+), 9 deletions(-) + +--- a/drivers/acpi/resource.c ++++ b/drivers/acpi/resource.c +@@ -483,17 +483,10 @@ static const struct dmi_system_id irq1_l + }, + }, + { +- /* Asus ExpertBook B2402CBA */ ++ /* Asus ExpertBook B2402 (B2402CBA / B2402FBA / B2402CVA / B2402FVA) */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."), +- DMI_MATCH(DMI_BOARD_NAME, "B2402CBA"), +- }, +- }, +- { +- /* Asus ExpertBook B2402FBA */ +- .matches = { +- DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."), +- DMI_MATCH(DMI_BOARD_NAME, "B2402FBA"), ++ DMI_MATCH(DMI_BOARD_NAME, "B2402"), + }, + }, + { diff --git a/queue-6.11/acpi-resource-make-asus-expertbook-b2502-matches-cover-more-models.patch b/queue-6.11/acpi-resource-make-asus-expertbook-b2502-matches-cover-more-models.patch new file mode 100644 index 00000000000..094ed9ca8d1 --- /dev/null +++ b/queue-6.11/acpi-resource-make-asus-expertbook-b2502-matches-cover-more-models.patch @@ -0,0 +1,62 @@ +From 435f2d87579e2408ab6502248f2270fc3c9e636e Mon Sep 17 00:00:00 2001 +From: Hans de Goede +Date: Sat, 5 Oct 2024 23:28:17 +0200 +Subject: ACPI: resource: Make Asus ExpertBook B2502 matches cover more models + +From: Hans de Goede + +commit 435f2d87579e2408ab6502248f2270fc3c9e636e upstream. + +Like the various 14" Asus ExpertBook B2 B2402* models there are also +4 variants of the 15" Asus ExpertBook B2 B2502* models: + +B2502CBA: 12th gen Intel CPU, non flip +B2502FBA: 12th gen Intel CPU, flip +B2502CVA: 13th gen Intel CPU, non flip +B2502FVA: 13th gen Intel CPU, flip + +Currently there already are DMI quirks for the B2502CBA, B2502FBA and +B2502CVA models. Asus website shows that there also is a B2502FVA. + +Rather then adding a 4th quirk fold the 3 existing quirks into a single +quirk covering B2502* to also cover the last model while at the same time +reducing the number of quirks. + +Cc: All applicable +Signed-off-by: Hans de Goede +Link: https://patch.msgid.link/20241005212819.354681-3-hdegoede@redhat.com +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + drivers/acpi/resource.c | 18 ++---------------- + 1 file changed, 2 insertions(+), 16 deletions(-) + +--- a/drivers/acpi/resource.c ++++ b/drivers/acpi/resource.c +@@ -490,24 +490,10 @@ static const struct dmi_system_id irq1_l + }, + }, + { +- /* Asus ExpertBook B2502 */ ++ /* Asus ExpertBook B2502 (B2502CBA / B2502FBA / B2502CVA / B2502FVA) */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."), +- DMI_MATCH(DMI_BOARD_NAME, "B2502CBA"), +- }, +- }, +- { +- /* Asus ExpertBook B2502FBA */ +- .matches = { +- DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."), +- DMI_MATCH(DMI_BOARD_NAME, "B2502FBA"), +- }, +- }, +- { +- /* Asus ExpertBook B2502CVA */ +- .matches = { +- DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."), +- DMI_MATCH(DMI_BOARD_NAME, "B2502CVA"), ++ DMI_MATCH(DMI_BOARD_NAME, "B2502"), + }, + }, + { diff --git a/queue-6.11/ata-libata-avoid-superfluous-disk-spin-down-spin-up-during-hibernation.patch b/queue-6.11/ata-libata-avoid-superfluous-disk-spin-down-spin-up-during-hibernation.patch new file mode 100644 index 00000000000..fd3bc9f6724 --- /dev/null +++ b/queue-6.11/ata-libata-avoid-superfluous-disk-spin-down-spin-up-during-hibernation.patch @@ -0,0 +1,76 @@ +From a38719e3157118428e34fbd45b0d0707a5877784 Mon Sep 17 00:00:00 2001 +From: Niklas Cassel +Date: Tue, 8 Oct 2024 15:58:44 +0200 +Subject: ata: libata: avoid superfluous disk spin down + spin up during hibernation + +From: Niklas Cassel + +commit a38719e3157118428e34fbd45b0d0707a5877784 upstream. + +A user reported that commit aa3998dbeb3a ("ata: libata-scsi: Disable scsi +device manage_system_start_stop") introduced a spin down + immediate spin +up of the disk both when entering and when resuming from hibernation. +This behavior was not there before, and causes an increased latency both +when entering and when resuming from hibernation. + +Hibernation is done by three consecutive PM events, in the following order: +1) PM_EVENT_FREEZE +2) PM_EVENT_THAW +3) PM_EVENT_HIBERNATE + +Commit aa3998dbeb3a ("ata: libata-scsi: Disable scsi device +manage_system_start_stop") modified ata_eh_handle_port_suspend() to call +ata_dev_power_set_standby() (which spins down the disk), for both event +PM_EVENT_FREEZE and event PM_EVENT_HIBERNATE. + +Documentation/driver-api/pm/devices.rst, section "Entering Hibernation", +explicitly mentions that PM_EVENT_FREEZE does not have to be put the device +in a low-power state, and actually recommends not doing so. Thus, let's not +spin down the disk on PM_EVENT_FREEZE. (The disk will instead be spun down +during the subsequent PM_EVENT_HIBERNATE event.) + +This way, PM_EVENT_FREEZE will behave as it did before commit aa3998dbeb3a +("ata: libata-scsi: Disable scsi device manage_system_start_stop"), while +PM_EVENT_HIBERNATE will continue to spin down the disk. + +This will avoid the superfluous spin down + spin up when entering and +resuming from hibernation, while still making sure that the disk is spun +down before actually entering hibernation. + +Cc: stable@vger.kernel.org # v6.6+ +Fixes: aa3998dbeb3a ("ata: libata-scsi: Disable scsi device manage_system_start_stop") +Reviewed-by: Damien Le Moal +Link: https://lore.kernel.org/r/20241008135843.1266244-2-cassel@kernel.org +Signed-off-by: Niklas Cassel +Signed-off-by: Greg Kroah-Hartman +--- + drivers/ata/libata-eh.c | 18 ++++++++++++++---- + 1 file changed, 14 insertions(+), 4 deletions(-) + +--- a/drivers/ata/libata-eh.c ++++ b/drivers/ata/libata-eh.c +@@ -4059,10 +4059,20 @@ static void ata_eh_handle_port_suspend(s + + WARN_ON(ap->pflags & ATA_PFLAG_SUSPENDED); + +- /* Set all devices attached to the port in standby mode */ +- ata_for_each_link(link, ap, HOST_FIRST) { +- ata_for_each_dev(dev, link, ENABLED) +- ata_dev_power_set_standby(dev); ++ /* ++ * We will reach this point for all of the PM events: ++ * PM_EVENT_SUSPEND (if runtime pm, PM_EVENT_AUTO will also be set) ++ * PM_EVENT_FREEZE, and PM_EVENT_HIBERNATE. ++ * ++ * We do not want to perform disk spin down for PM_EVENT_FREEZE. ++ * (Spin down will be performed by the subsequent PM_EVENT_HIBERNATE.) ++ */ ++ if (!(ap->pm_mesg.event & PM_EVENT_FREEZE)) { ++ /* Set all devices attached to the port in standby mode */ ++ ata_for_each_link(link, ap, HOST_FIRST) { ++ ata_for_each_dev(dev, link, ENABLED) ++ ata_dev_power_set_standby(dev); ++ } + } + + /* diff --git a/queue-6.11/bluetooth-hci_conn-fix-uaf-in-hci_enhanced_setup_sync.patch b/queue-6.11/bluetooth-hci_conn-fix-uaf-in-hci_enhanced_setup_sync.patch new file mode 100644 index 00000000000..705219cc6ca --- /dev/null +++ b/queue-6.11/bluetooth-hci_conn-fix-uaf-in-hci_enhanced_setup_sync.patch @@ -0,0 +1,97 @@ +From 18fd04ad856df07733f5bb07e7f7168e7443d393 Mon Sep 17 00:00:00 2001 +From: Luiz Augusto von Dentz +Date: Wed, 2 Oct 2024 11:17:26 -0400 +Subject: Bluetooth: hci_conn: Fix UAF in hci_enhanced_setup_sync + +From: Luiz Augusto von Dentz + +commit 18fd04ad856df07733f5bb07e7f7168e7443d393 upstream. + +This checks if the ACL connection remains valid as it could be destroyed +while hci_enhanced_setup_sync is pending on cmd_sync leading to the +following trace: + +BUG: KASAN: slab-use-after-free in hci_enhanced_setup_sync+0x91b/0xa60 +Read of size 1 at addr ffff888002328ffd by task kworker/u5:2/37 + +CPU: 0 UID: 0 PID: 37 Comm: kworker/u5:2 Not tainted 6.11.0-rc6-01300-g810be445d8d6 #7099 +Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 +Workqueue: hci0 hci_cmd_sync_work +Call Trace: + + dump_stack_lvl+0x5d/0x80 + ? hci_enhanced_setup_sync+0x91b/0xa60 + print_report+0x152/0x4c0 + ? hci_enhanced_setup_sync+0x91b/0xa60 + ? __virt_addr_valid+0x1fa/0x420 + ? hci_enhanced_setup_sync+0x91b/0xa60 + kasan_report+0xda/0x1b0 + ? hci_enhanced_setup_sync+0x91b/0xa60 + hci_enhanced_setup_sync+0x91b/0xa60 + ? __pfx_hci_enhanced_setup_sync+0x10/0x10 + ? __pfx___mutex_lock+0x10/0x10 + hci_cmd_sync_work+0x1c2/0x330 + process_one_work+0x7d9/0x1360 + ? __pfx_lock_acquire+0x10/0x10 + ? __pfx_process_one_work+0x10/0x10 + ? assign_work+0x167/0x240 + worker_thread+0x5b7/0xf60 + ? __kthread_parkme+0xac/0x1c0 + ? __pfx_worker_thread+0x10/0x10 + ? __pfx_worker_thread+0x10/0x10 + kthread+0x293/0x360 + ? __pfx_kthread+0x10/0x10 + ret_from_fork+0x2f/0x70 + ? __pfx_kthread+0x10/0x10 + ret_from_fork_asm+0x1a/0x30 + + +Allocated by task 34: + kasan_save_stack+0x30/0x50 + kasan_save_track+0x14/0x30 + __kasan_kmalloc+0x8f/0xa0 + __hci_conn_add+0x187/0x17d0 + hci_connect_sco+0x2e1/0xb90 + sco_sock_connect+0x2a2/0xb80 + __sys_connect+0x227/0x2a0 + __x64_sys_connect+0x6d/0xb0 + do_syscall_64+0x71/0x140 + entry_SYSCALL_64_after_hwframe+0x76/0x7e + +Freed by task 37: + kasan_save_stack+0x30/0x50 + kasan_save_track+0x14/0x30 + kasan_save_free_info+0x3b/0x60 + __kasan_slab_free+0x101/0x160 + kfree+0xd0/0x250 + device_release+0x9a/0x210 + kobject_put+0x151/0x280 + hci_conn_del+0x448/0xbf0 + hci_abort_conn_sync+0x46f/0x980 + hci_cmd_sync_work+0x1c2/0x330 + process_one_work+0x7d9/0x1360 + worker_thread+0x5b7/0xf60 + kthread+0x293/0x360 + ret_from_fork+0x2f/0x70 + ret_from_fork_asm+0x1a/0x30 + +Cc: stable@vger.kernel.org +Fixes: e07a06b4eb41 ("Bluetooth: Convert SCO configure_datapath to hci_sync") +Signed-off-by: Luiz Augusto von Dentz +Signed-off-by: Greg Kroah-Hartman +--- + net/bluetooth/hci_conn.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/net/bluetooth/hci_conn.c ++++ b/net/bluetooth/hci_conn.c +@@ -289,6 +289,9 @@ static int hci_enhanced_setup_sync(struc + + kfree(conn_handle); + ++ if (!hci_conn_valid(hdev, conn)) ++ return -ECANCELED; ++ + bt_dev_dbg(hdev, "hcon %p", conn); + + configure_datapath_sync(hdev, &conn->codec); diff --git a/queue-6.11/btrfs-add-cancellation-points-to-trim-loops.patch b/queue-6.11/btrfs-add-cancellation-points-to-trim-loops.patch new file mode 100644 index 00000000000..8339adc4398 --- /dev/null +++ b/queue-6.11/btrfs-add-cancellation-points-to-trim-loops.patch @@ -0,0 +1,97 @@ +From 69313850dce33ce8c24b38576a279421f4c60996 Mon Sep 17 00:00:00 2001 +From: Luca Stefani +Date: Tue, 17 Sep 2024 22:33:05 +0200 +Subject: btrfs: add cancellation points to trim loops + +From: Luca Stefani + +commit 69313850dce33ce8c24b38576a279421f4c60996 upstream. + +There are reports that system cannot suspend due to running trim because +the task responsible for trimming the device isn't able to finish in +time, especially since we have a free extent discarding phase, which can +trim a lot of unallocated space. There are no limits on the trim size +(unlike the block group part). + +Since trime isn't a critical call it can be interrupted at any time, +in such cases we stop the trim, report the amount of discarded bytes and +return an error. + +Link: https://bugzilla.kernel.org/show_bug.cgi?id=219180 +Link: https://bugzilla.suse.com/show_bug.cgi?id=1229737 +CC: stable@vger.kernel.org # 5.15+ +Signed-off-by: Luca Stefani +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/extent-tree.c | 7 ++++++- + fs/btrfs/free-space-cache.c | 4 ++-- + fs/btrfs/free-space-cache.h | 6 ++++++ + 3 files changed, 14 insertions(+), 3 deletions(-) + +--- a/fs/btrfs/extent-tree.c ++++ b/fs/btrfs/extent-tree.c +@@ -1316,6 +1316,11 @@ static int btrfs_issue_discard(struct bl + start += bytes_to_discard; + bytes_left -= bytes_to_discard; + *discarded_bytes += bytes_to_discard; ++ ++ if (btrfs_trim_interrupted()) { ++ ret = -ERESTARTSYS; ++ break; ++ } + } + + return ret; +@@ -6470,7 +6475,7 @@ static int btrfs_trim_free_extents(struc + start += len; + *trimmed += bytes; + +- if (fatal_signal_pending(current)) { ++ if (btrfs_trim_interrupted()) { + ret = -ERESTARTSYS; + break; + } +--- a/fs/btrfs/free-space-cache.c ++++ b/fs/btrfs/free-space-cache.c +@@ -3809,7 +3809,7 @@ next: + if (async && *total_trimmed) + break; + +- if (fatal_signal_pending(current)) { ++ if (btrfs_trim_interrupted()) { + ret = -ERESTARTSYS; + break; + } +@@ -4000,7 +4000,7 @@ next: + } + block_group->discard_cursor = start; + +- if (fatal_signal_pending(current)) { ++ if (btrfs_trim_interrupted()) { + if (start != offset) + reset_trimming_bitmap(ctl, offset); + ret = -ERESTARTSYS; +--- a/fs/btrfs/free-space-cache.h ++++ b/fs/btrfs/free-space-cache.h +@@ -10,6 +10,7 @@ + #include + #include + #include ++#include + #include "fs.h" + + struct inode; +@@ -56,6 +57,11 @@ static inline bool btrfs_free_space_trim + return (info->trim_state == BTRFS_TRIM_STATE_TRIMMING); + } + ++static inline bool btrfs_trim_interrupted(void) ++{ ++ return fatal_signal_pending(current) || freezing(current); ++} ++ + /* + * Deltas are an effective way to populate global statistics. Give macro names + * to make it clear what we're doing. An example is discard_extents in diff --git a/queue-6.11/btrfs-split-remaining-space-to-discard-in-chunks.patch b/queue-6.11/btrfs-split-remaining-space-to-discard-in-chunks.patch new file mode 100644 index 00000000000..a1458c9c465 --- /dev/null +++ b/queue-6.11/btrfs-split-remaining-space-to-discard-in-chunks.patch @@ -0,0 +1,78 @@ +From a99fcb0158978ed332009449b484e5f3ca2d7df4 Mon Sep 17 00:00:00 2001 +From: Luca Stefani +Date: Tue, 17 Sep 2024 22:33:04 +0200 +Subject: btrfs: split remaining space to discard in chunks + +From: Luca Stefani + +commit a99fcb0158978ed332009449b484e5f3ca2d7df4 upstream. + +Per Qu Wenruo in case we have a very large disk, e.g. 8TiB device, +mostly empty although we will do the split according to our super block +locations, the last super block ends at 256G, we can submit a huge +discard for the range [256G, 8T), causing a large delay. + +Split the space left to discard based on BTRFS_MAX_DISCARD_CHUNK_SIZE in +preparation of introduction of cancellation points to trim. The value +of the chunk size is arbitrary, it can be higher or derived from actual +device capabilities but we can't easily read that using +bio_discard_limit(). + +Link: https://bugzilla.kernel.org/show_bug.cgi?id=219180 +Link: https://bugzilla.suse.com/show_bug.cgi?id=1229737 +CC: stable@vger.kernel.org # 5.15+ +Signed-off-by: Luca Stefani +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/extent-tree.c | 19 +++++++++++++++---- + fs/btrfs/volumes.h | 6 ++++++ + 2 files changed, 21 insertions(+), 4 deletions(-) + +--- a/fs/btrfs/extent-tree.c ++++ b/fs/btrfs/extent-tree.c +@@ -1300,13 +1300,24 @@ static int btrfs_issue_discard(struct bl + bytes_left = end - start; + } + +- if (bytes_left) { ++ while (bytes_left) { ++ u64 bytes_to_discard = min(BTRFS_MAX_DISCARD_CHUNK_SIZE, bytes_left); ++ + ret = blkdev_issue_discard(bdev, start >> SECTOR_SHIFT, +- bytes_left >> SECTOR_SHIFT, ++ bytes_to_discard >> SECTOR_SHIFT, + GFP_NOFS); +- if (!ret) +- *discarded_bytes += bytes_left; ++ ++ if (ret) { ++ if (ret != -EOPNOTSUPP) ++ break; ++ continue; ++ } ++ ++ start += bytes_to_discard; ++ bytes_left -= bytes_to_discard; ++ *discarded_bytes += bytes_to_discard; + } ++ + return ret; + } + +--- a/fs/btrfs/volumes.h ++++ b/fs/btrfs/volumes.h +@@ -30,6 +30,12 @@ struct btrfs_zoned_device_info; + + #define BTRFS_MAX_DATA_CHUNK_SIZE (10ULL * SZ_1G) + ++/* ++ * Arbitratry maximum size of one discard request to limit potentially long time ++ * spent in blkdev_issue_discard(). ++ */ ++#define BTRFS_MAX_DISCARD_CHUNK_SIZE (SZ_1G) ++ + extern struct mutex uuid_mutex; + + #define BTRFS_STRIPE_LEN SZ_64K diff --git a/queue-6.11/device-dax-correct-pgoff-align-in-dax_set_mapping.patch b/queue-6.11/device-dax-correct-pgoff-align-in-dax_set_mapping.patch new file mode 100644 index 00000000000..e22d09b5d5d --- /dev/null +++ b/queue-6.11/device-dax-correct-pgoff-align-in-dax_set_mapping.patch @@ -0,0 +1,112 @@ +From 7fcbd9785d4c17ea533c42f20a9083a83f301fa6 Mon Sep 17 00:00:00 2001 +From: "Kun(llfl)" +Date: Fri, 27 Sep 2024 15:45:09 +0800 +Subject: device-dax: correct pgoff align in dax_set_mapping() +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Kun(llfl) + +commit 7fcbd9785d4c17ea533c42f20a9083a83f301fa6 upstream. + +pgoff should be aligned using ALIGN_DOWN() instead of ALIGN(). Otherwise, +vmf->address not aligned to fault_size will be aligned to the next +alignment, that can result in memory failure getting the wrong address. + +It's a subtle situation that only can be observed in +page_mapped_in_vma() after the page is page fault handled by +dev_dax_huge_fault. Generally, there is little chance to perform +page_mapped_in_vma in dev-dax's page unless in specific error injection +to the dax device to trigger an MCE - memory-failure. In that case, +page_mapped_in_vma() will be triggered to determine which task is +accessing the failure address and kill that task in the end. + + +We used self-developed dax device (which is 2M aligned mapping) , to +perform error injection to random address. It turned out that error +injected to non-2M-aligned address was causing endless MCE until panic. +Because page_mapped_in_vma() kept resulting wrong address and the task +accessing the failure address was never killed properly: + + +[ 3783.719419] Memory failure: 0x200c9742: recovery action for dax page: +Recovered +[ 3784.049006] mce: Uncorrected hardware memory error in user-access at +200c9742380 +[ 3784.049190] Memory failure: 0x200c9742: recovery action for dax page: +Recovered +[ 3784.448042] mce: Uncorrected hardware memory error in user-access at +200c9742380 +[ 3784.448186] Memory failure: 0x200c9742: recovery action for dax page: +Recovered +[ 3784.792026] mce: Uncorrected hardware memory error in user-access at +200c9742380 +[ 3784.792179] Memory failure: 0x200c9742: recovery action for dax page: +Recovered +[ 3785.162502] mce: Uncorrected hardware memory error in user-access at +200c9742380 +[ 3785.162633] Memory failure: 0x200c9742: recovery action for dax page: +Recovered +[ 3785.461116] mce: Uncorrected hardware memory error in user-access at +200c9742380 +[ 3785.461247] Memory failure: 0x200c9742: recovery action for dax page: +Recovered +[ 3785.764730] mce: Uncorrected hardware memory error in user-access at +200c9742380 +[ 3785.764859] Memory failure: 0x200c9742: recovery action for dax page: +Recovered +[ 3786.042128] mce: Uncorrected hardware memory error in user-access at +200c9742380 +[ 3786.042259] Memory failure: 0x200c9742: recovery action for dax page: +Recovered +[ 3786.464293] mce: Uncorrected hardware memory error in user-access at +200c9742380 +[ 3786.464423] Memory failure: 0x200c9742: recovery action for dax page: +Recovered +[ 3786.818090] mce: Uncorrected hardware memory error in user-access at +200c9742380 +[ 3786.818217] Memory failure: 0x200c9742: recovery action for dax page: +Recovered +[ 3787.085297] mce: Uncorrected hardware memory error in user-access at +200c9742380 +[ 3787.085424] Memory failure: 0x200c9742: recovery action for dax page: +Recovered + +It took us several weeks to pinpoint this problem,  but we eventually +used bpftrace to trace the page fault and mce address and successfully +identified the issue. + + +Joao added: + +; Likely we never reproduce in production because we always pin +: device-dax regions in the region align they provide (Qemu does +: similarly with prealloc in hugetlb/file backed memory). I think this +: bug requires that we touch *unpinned* device-dax regions unaligned to +: the device-dax selected alignment (page size i.e. 4K/2M/1G) + +Link: https://lkml.kernel.org/r/23c02a03e8d666fef11bbe13e85c69c8b4ca0624.1727421694.git.llfl@linux.alibaba.com +Fixes: b9b5777f09be ("device-dax: use ALIGN() for determining pgoff") +Signed-off-by: Kun(llfl) +Tested-by: JianXiong Zhao +Reviewed-by: Joao Martins +Cc: Dan Williams +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + drivers/dax/device.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/dax/device.c ++++ b/drivers/dax/device.c +@@ -86,7 +86,7 @@ static void dax_set_mapping(struct vm_fa + nr_pages = 1; + + pgoff = linear_page_index(vmf->vma, +- ALIGN(vmf->address, fault_size)); ++ ALIGN_DOWN(vmf->address, fault_size)); + + for (i = 0; i < nr_pages; i++) { + struct page *page = pfn_to_page(pfn_t_to_pfn(pfn) + i); diff --git a/queue-6.11/drm-amd-display-clear-update-flags-after-update-has-been-applied.patch b/queue-6.11/drm-amd-display-clear-update-flags-after-update-has-been-applied.patch new file mode 100644 index 00000000000..2d15d89adae --- /dev/null +++ b/queue-6.11/drm-amd-display-clear-update-flags-after-update-has-been-applied.patch @@ -0,0 +1,124 @@ +From 0a9906cc45d21e21ca8bb2b98b79fd7c05420fda Mon Sep 17 00:00:00 2001 +From: Josip Pavic +Date: Tue, 24 Sep 2024 17:25:54 -0400 +Subject: drm/amd/display: Clear update flags after update has been applied + +From: Josip Pavic + +commit 0a9906cc45d21e21ca8bb2b98b79fd7c05420fda upstream. + +[Why] +Since the surface/stream update flags aren't cleared after applying +updates, those same updates may be applied again in a future call to +update surfaces/streams for surfaces/streams that aren't actually part +of that update (i.e. applying an update for one surface/stream can +trigger unintended programming on a different surface/stream). + +For example, when an update results in a call to +program_front_end_for_ctx, that function may call program_pipe on all +pipes. If there are surface update flags that were never cleared on the +surface some pipe is attached to, then the same update will be +programmed again. + +[How] +Clear the surface and stream update flags after applying the updates. + +Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3441 +Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3616 +Cc: Melissa Wen +Reviewed-by: Aric Cyr +Signed-off-by: Josip Pavic +Signed-off-by: Rodrigo Siqueira +Tested-by: Daniel Wheeler +Signed-off-by: Alex Deucher +(cherry picked from commit 7671f62c10f2a4c77d89b39fd50fab7f918d6809) +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/display/dc/core/dc.c | 45 +++++++++++++++++++++++-------- + 1 file changed, 34 insertions(+), 11 deletions(-) + +--- a/drivers/gpu/drm/amd/display/dc/core/dc.c ++++ b/drivers/gpu/drm/amd/display/dc/core/dc.c +@@ -5120,11 +5120,26 @@ static bool update_planes_and_stream_v3( + return true; + } + ++static void clear_update_flags(struct dc_surface_update *srf_updates, ++ int surface_count, struct dc_stream_state *stream) ++{ ++ int i; ++ ++ if (stream) ++ stream->update_flags.raw = 0; ++ ++ for (i = 0; i < surface_count; i++) ++ if (srf_updates[i].surface) ++ srf_updates[i].surface->update_flags.raw = 0; ++} ++ + bool dc_update_planes_and_stream(struct dc *dc, + struct dc_surface_update *srf_updates, int surface_count, + struct dc_stream_state *stream, + struct dc_stream_update *stream_update) + { ++ bool ret = false; ++ + dc_exit_ips_for_hw_access(dc); + /* + * update planes and stream version 3 separates FULL and FAST updates +@@ -5141,10 +5156,16 @@ bool dc_update_planes_and_stream(struct + * features as they are now transparent to the new sequence. + */ + if (dc->ctx->dce_version >= DCN_VERSION_4_01) +- return update_planes_and_stream_v3(dc, srf_updates, ++ ret = update_planes_and_stream_v3(dc, srf_updates, + surface_count, stream, stream_update); +- return update_planes_and_stream_v2(dc, srf_updates, ++ else ++ ret = update_planes_and_stream_v2(dc, srf_updates, + surface_count, stream, stream_update); ++ ++ if (ret) ++ clear_update_flags(srf_updates, surface_count, stream); ++ ++ return ret; + } + + void dc_commit_updates_for_stream(struct dc *dc, +@@ -5154,6 +5175,8 @@ void dc_commit_updates_for_stream(struct + struct dc_stream_update *stream_update, + struct dc_state *state) + { ++ bool ret = false; ++ + dc_exit_ips_for_hw_access(dc); + /* TODO: Since change commit sequence can have a huge impact, + * we decided to only enable it for DCN3x. However, as soon as +@@ -5161,17 +5184,17 @@ void dc_commit_updates_for_stream(struct + * the new sequence for all ASICs. + */ + if (dc->ctx->dce_version >= DCN_VERSION_4_01) { +- update_planes_and_stream_v3(dc, srf_updates, surface_count, ++ ret = update_planes_and_stream_v3(dc, srf_updates, surface_count, + stream, stream_update); +- return; +- } +- if (dc->ctx->dce_version >= DCN_VERSION_3_2) { +- update_planes_and_stream_v2(dc, srf_updates, surface_count, ++ } else if (dc->ctx->dce_version >= DCN_VERSION_3_2) { ++ ret = update_planes_and_stream_v2(dc, srf_updates, surface_count, + stream, stream_update); +- return; +- } +- update_planes_and_stream_v1(dc, srf_updates, surface_count, stream, +- stream_update, state); ++ } else ++ ret = update_planes_and_stream_v1(dc, srf_updates, surface_count, stream, ++ stream_update, state); ++ ++ if (ret) ++ clear_update_flags(srf_updates, surface_count, stream); + } + + uint8_t dc_get_current_stream_count(struct dc *dc) diff --git a/queue-6.11/drm-amd-display-fix-hibernate-entry-for-dcn35.patch b/queue-6.11/drm-amd-display-fix-hibernate-entry-for-dcn35.patch new file mode 100644 index 00000000000..a008b539417 --- /dev/null +++ b/queue-6.11/drm-amd-display-fix-hibernate-entry-for-dcn35.patch @@ -0,0 +1,44 @@ +From 79bc412ef787cf25773d0ece93f8739ce0e6ac1e Mon Sep 17 00:00:00 2001 +From: Hamza Mahfooz +Date: Fri, 4 Oct 2024 15:22:57 -0400 +Subject: drm/amd/display: fix hibernate entry for DCN35+ + +From: Hamza Mahfooz + +commit 79bc412ef787cf25773d0ece93f8739ce0e6ac1e upstream. + +Since, two suspend-resume cycles are required to enter hibernate and, +since we only need to enable idle optimizations in the first cycle +(which is pretty much equivalent to s2idle). We can check in_s0ix, to +prevent the system from entering idle optimizations before it actually +enters hibernate (from display's perspective). Also, call +dc_set_power_state() before dc_allow_idle_optimizations(), since it's +safer to do so because dc_set_power_state() writes to DMUB. + +Acked-by: Alex Deucher +Signed-off-by: Hamza Mahfooz +Signed-off-by: Alex Deucher +(cherry picked from commit 2fe79508d9c393bb9931b0037c5ecaee09a8dc39) +Cc: stable@vger.kernel.org # 6.10+ +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 ++++--- + 1 file changed, 4 insertions(+), 3 deletions(-) + +--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c ++++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +@@ -2950,10 +2950,11 @@ static int dm_suspend(void *handle) + + hpd_rx_irq_work_suspend(dm); + +- if (adev->dm.dc->caps.ips_support) +- dc_allow_idle_optimizations(adev->dm.dc, true); +- + dc_set_power_state(dm->dc, DC_ACPI_CM_POWER_STATE_D3); ++ ++ if (dm->dc->caps.ips_support && adev->in_s0ix) ++ dc_allow_idle_optimizations(dm->dc, true); ++ + dc_dmub_srv_set_power_state(dm->dc->ctx->dmub_srv, DC_ACPI_CM_POWER_STATE_D3); + + return 0; diff --git a/queue-6.11/drm-amdgpu-partially-revert-powerplay-__counted_by-changes.patch b/queue-6.11/drm-amdgpu-partially-revert-powerplay-__counted_by-changes.patch new file mode 100644 index 00000000000..eec3b60a3a8 --- /dev/null +++ b/queue-6.11/drm-amdgpu-partially-revert-powerplay-__counted_by-changes.patch @@ -0,0 +1,137 @@ +From d6b9f492e229be1d1bd360c3ac5bee4635bacf99 Mon Sep 17 00:00:00 2001 +From: Alex Deucher +Date: Wed, 2 Oct 2024 17:27:25 -0400 +Subject: drm/amdgpu: partially revert powerplay `__counted_by` changes + +From: Alex Deucher + +commit d6b9f492e229be1d1bd360c3ac5bee4635bacf99 upstream. + +Partially revert +commit 0ca9f757a0e2 ("drm/amd/pm: powerplay: Add `__counted_by` attribute for flexible arrays") + +The count attribute for these arrays does not get set until +after the arrays are allocated and populated leading to false +UBSAN warnings. + +Fixes: 0ca9f757a0e2 ("drm/amd/pm: powerplay: Add `__counted_by` attribute for flexible arrays") +Reviewed-by: Mario Limonciello +Reviewed-by: Lijo Lazar +Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3662 +Signed-off-by: Alex Deucher +(cherry picked from commit 8a5ae927b653b43623e55610d2215ee94c027e8c) +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/pm/powerplay/inc/hwmgr.h | 26 ++++++++++---------- + 1 file changed, 13 insertions(+), 13 deletions(-) + +diff --git a/drivers/gpu/drm/amd/pm/powerplay/inc/hwmgr.h b/drivers/gpu/drm/amd/pm/powerplay/inc/hwmgr.h +index 9118fcddbf11..227bf0e84a13 100644 +--- a/drivers/gpu/drm/amd/pm/powerplay/inc/hwmgr.h ++++ b/drivers/gpu/drm/amd/pm/powerplay/inc/hwmgr.h +@@ -60,7 +60,7 @@ struct vi_dpm_level { + + struct vi_dpm_table { + uint32_t count; +- struct vi_dpm_level dpm_level[] __counted_by(count); ++ struct vi_dpm_level dpm_level[]; + }; + + #define PCIE_PERF_REQ_REMOVE_REGISTRY 0 +@@ -91,7 +91,7 @@ struct phm_set_power_state_input { + + struct phm_clock_array { + uint32_t count; +- uint32_t values[] __counted_by(count); ++ uint32_t values[]; + }; + + struct phm_clock_voltage_dependency_record { +@@ -123,7 +123,7 @@ struct phm_acpclock_voltage_dependency_record { + + struct phm_clock_voltage_dependency_table { + uint32_t count; +- struct phm_clock_voltage_dependency_record entries[] __counted_by(count); ++ struct phm_clock_voltage_dependency_record entries[]; + }; + + struct phm_phase_shedding_limits_record { +@@ -140,7 +140,7 @@ struct phm_uvd_clock_voltage_dependency_record { + + struct phm_uvd_clock_voltage_dependency_table { + uint8_t count; +- struct phm_uvd_clock_voltage_dependency_record entries[] __counted_by(count); ++ struct phm_uvd_clock_voltage_dependency_record entries[]; + }; + + struct phm_acp_clock_voltage_dependency_record { +@@ -150,7 +150,7 @@ struct phm_acp_clock_voltage_dependency_record { + + struct phm_acp_clock_voltage_dependency_table { + uint32_t count; +- struct phm_acp_clock_voltage_dependency_record entries[] __counted_by(count); ++ struct phm_acp_clock_voltage_dependency_record entries[]; + }; + + struct phm_vce_clock_voltage_dependency_record { +@@ -161,32 +161,32 @@ struct phm_vce_clock_voltage_dependency_record { + + struct phm_phase_shedding_limits_table { + uint32_t count; +- struct phm_phase_shedding_limits_record entries[] __counted_by(count); ++ struct phm_phase_shedding_limits_record entries[]; + }; + + struct phm_vceclock_voltage_dependency_table { + uint8_t count; +- struct phm_vceclock_voltage_dependency_record entries[] __counted_by(count); ++ struct phm_vceclock_voltage_dependency_record entries[]; + }; + + struct phm_uvdclock_voltage_dependency_table { + uint8_t count; +- struct phm_uvdclock_voltage_dependency_record entries[] __counted_by(count); ++ struct phm_uvdclock_voltage_dependency_record entries[]; + }; + + struct phm_samuclock_voltage_dependency_table { + uint8_t count; +- struct phm_samuclock_voltage_dependency_record entries[] __counted_by(count); ++ struct phm_samuclock_voltage_dependency_record entries[]; + }; + + struct phm_acpclock_voltage_dependency_table { + uint32_t count; +- struct phm_acpclock_voltage_dependency_record entries[] __counted_by(count); ++ struct phm_acpclock_voltage_dependency_record entries[]; + }; + + struct phm_vce_clock_voltage_dependency_table { + uint8_t count; +- struct phm_vce_clock_voltage_dependency_record entries[] __counted_by(count); ++ struct phm_vce_clock_voltage_dependency_record entries[]; + }; + + +@@ -393,7 +393,7 @@ union phm_cac_leakage_record { + + struct phm_cac_leakage_table { + uint32_t count; +- union phm_cac_leakage_record entries[] __counted_by(count); ++ union phm_cac_leakage_record entries[]; + }; + + struct phm_samu_clock_voltage_dependency_record { +@@ -404,7 +404,7 @@ struct phm_samu_clock_voltage_dependency_record { + + struct phm_samu_clock_voltage_dependency_table { + uint8_t count; +- struct phm_samu_clock_voltage_dependency_record entries[] __counted_by(count); ++ struct phm_samu_clock_voltage_dependency_record entries[]; + }; + + struct phm_cac_tdp_table { +-- +2.47.0 + diff --git a/queue-6.11/drm-amdkfd-fix-an-eviction-fence-leak.patch b/queue-6.11/drm-amdkfd-fix-an-eviction-fence-leak.patch new file mode 100644 index 00000000000..d0ed7714ac5 --- /dev/null +++ b/queue-6.11/drm-amdkfd-fix-an-eviction-fence-leak.patch @@ -0,0 +1,57 @@ +From d7d7b947a4fa6d0a82ff2bf0db413edc63738e3a Mon Sep 17 00:00:00 2001 +From: Lang Yu +Date: Fri, 27 Sep 2024 18:27:46 +0800 +Subject: drm/amdkfd: Fix an eviction fence leak + +From: Lang Yu + +commit d7d7b947a4fa6d0a82ff2bf0db413edc63738e3a upstream. + +Only creating a new reference for each process instead of each VM. + +Fixes: 9a1c1339abf9 ("drm/amdkfd: Run restore_workers on freezable WQs") +Suggested-by: Felix Kuehling +Signed-off-by: Lang Yu +Reviewed-by: Felix Kuehling +Signed-off-by: Alex Deucher +(cherry picked from commit 5fa436289483ae56427b0896c31f72361223c758) +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 4 ++-- + drivers/gpu/drm/amd/amdkfd/kfd_process.c | 7 +++++-- + 2 files changed, 7 insertions(+), 4 deletions(-) + +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c +@@ -1438,8 +1438,8 @@ static int init_kfd_vm(struct amdgpu_vm + list_add_tail(&vm->vm_list_node, + &(vm->process_info->vm_list_head)); + vm->process_info->n_vms++; +- +- *ef = dma_fence_get(&vm->process_info->eviction_fence->base); ++ if (ef) ++ *ef = dma_fence_get(&vm->process_info->eviction_fence->base); + mutex_unlock(&vm->process_info->lock); + + return 0; +--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c ++++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c +@@ -1676,12 +1676,15 @@ int kfd_process_device_init_vm(struct kf + + ret = amdgpu_amdkfd_gpuvm_acquire_process_vm(dev->adev, avm, + &p->kgd_process_info, +- &ef); ++ p->ef ? NULL : &ef); + if (ret) { + dev_err(dev->adev->dev, "Failed to create process VM object\n"); + return ret; + } +- RCU_INIT_POINTER(p->ef, ef); ++ ++ if (!p->ef) ++ RCU_INIT_POINTER(p->ef, ef); ++ + pdd->drm_priv = drm_file->private_data; + + ret = kfd_process_device_reserve_ib_mem(pdd); diff --git a/queue-6.11/drm-i915-hdcp-fix-connector-refcounting.patch b/queue-6.11/drm-i915-hdcp-fix-connector-refcounting.patch new file mode 100644 index 00000000000..c8bd1836cb5 --- /dev/null +++ b/queue-6.11/drm-i915-hdcp-fix-connector-refcounting.patch @@ -0,0 +1,68 @@ +From 4cc2718f621a6a57a02581125bb6d914ce74d23b Mon Sep 17 00:00:00 2001 +From: Jani Nikula +Date: Tue, 24 Sep 2024 18:30:22 +0300 +Subject: drm/i915/hdcp: fix connector refcounting +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Jani Nikula + +commit 4cc2718f621a6a57a02581125bb6d914ce74d23b upstream. + +We acquire a connector reference before scheduling an HDCP prop work, +and expect the work function to release the reference. + +However, if the work was already queued, it won't be queued multiple +times, and the reference is not dropped. + +Release the reference immediately if the work was already queued. + +Fixes: a6597faa2d59 ("drm/i915: Protect workers against disappearing connectors") +Cc: Sean Paul +Cc: Suraj Kandpal +Cc: Ville Syrjälä +Cc: stable@vger.kernel.org # v5.10+ +Reviewed-by: Suraj Kandpal +Link: https://patchwork.freedesktop.org/patch/msgid/20240924153022.2255299-1-jani.nikula@intel.com +Signed-off-by: Jani Nikula +(cherry picked from commit abc0742c79bdb3b164eacab24aea0916d2ec1cb5) +Signed-off-by: Joonas Lahtinen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/i915/display/intel_hdcp.c | 10 +++++++--- + 1 file changed, 7 insertions(+), 3 deletions(-) + +--- a/drivers/gpu/drm/i915/display/intel_hdcp.c ++++ b/drivers/gpu/drm/i915/display/intel_hdcp.c +@@ -1089,7 +1089,8 @@ static void intel_hdcp_update_value(stru + hdcp->value = value; + if (update_property) { + drm_connector_get(&connector->base); +- queue_work(i915->unordered_wq, &hdcp->prop_work); ++ if (!queue_work(i915->unordered_wq, &hdcp->prop_work)) ++ drm_connector_put(&connector->base); + } + } + +@@ -2517,7 +2518,8 @@ void intel_hdcp_update_pipe(struct intel + mutex_lock(&hdcp->mutex); + hdcp->value = DRM_MODE_CONTENT_PROTECTION_DESIRED; + drm_connector_get(&connector->base); +- queue_work(i915->unordered_wq, &hdcp->prop_work); ++ if (!queue_work(i915->unordered_wq, &hdcp->prop_work)) ++ drm_connector_put(&connector->base); + mutex_unlock(&hdcp->mutex); + } + +@@ -2534,7 +2536,9 @@ void intel_hdcp_update_pipe(struct intel + */ + if (!desired_and_not_enabled && !content_protection_type_changed) { + drm_connector_get(&connector->base); +- queue_work(i915->unordered_wq, &hdcp->prop_work); ++ if (!queue_work(i915->unordered_wq, &hdcp->prop_work)) ++ drm_connector_put(&connector->base); ++ + } + } + diff --git a/queue-6.11/drm-v3d-stop-the-active-perfmon-before-being-destroyed.patch b/queue-6.11/drm-v3d-stop-the-active-perfmon-before-being-destroyed.patch new file mode 100644 index 00000000000..7d5943f0487 --- /dev/null +++ b/queue-6.11/drm-v3d-stop-the-active-perfmon-before-being-destroyed.patch @@ -0,0 +1,113 @@ +From 7d1fd3638ee3a9f9bca4785fffb638ca19120718 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Ma=C3=ADra=20Canal?= +Date: Fri, 4 Oct 2024 10:02:29 -0300 +Subject: drm/v3d: Stop the active perfmon before being destroyed +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Maíra Canal + +commit 7d1fd3638ee3a9f9bca4785fffb638ca19120718 upstream. + +When running `kmscube` with one or more performance monitors enabled +via `GALLIUM_HUD`, the following kernel panic can occur: + +[ 55.008324] Unable to handle kernel paging request at virtual address 00000000052004a4 +[ 55.008368] Mem abort info: +[ 55.008377] ESR = 0x0000000096000005 +[ 55.008387] EC = 0x25: DABT (current EL), IL = 32 bits +[ 55.008402] SET = 0, FnV = 0 +[ 55.008412] EA = 0, S1PTW = 0 +[ 55.008421] FSC = 0x05: level 1 translation fault +[ 55.008434] Data abort info: +[ 55.008442] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 +[ 55.008455] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 +[ 55.008467] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 +[ 55.008481] user pgtable: 4k pages, 39-bit VAs, pgdp=00000001046c6000 +[ 55.008497] [00000000052004a4] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 +[ 55.008525] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP +[ 55.008542] Modules linked in: rfcomm [...] vc4 v3d snd_soc_hdmi_codec drm_display_helper +gpu_sched drm_shmem_helper cec drm_dma_helper drm_kms_helper i2c_brcmstb +drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight +[ 55.008799] CPU: 2 PID: 166 Comm: v3d_bin Tainted: G C 6.6.47+rpt-rpi-v8 #1 Debian 1:6.6.47-1+rpt1 +[ 55.008824] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) +[ 55.008838] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) +[ 55.008855] pc : __mutex_lock.constprop.0+0x90/0x608 +[ 55.008879] lr : __mutex_lock.constprop.0+0x58/0x608 +[ 55.008895] sp : ffffffc080673cf0 +[ 55.008904] x29: ffffffc080673cf0 x28: 0000000000000000 x27: ffffff8106188a28 +[ 55.008926] x26: ffffff8101e78040 x25: ffffff8101baa6c0 x24: ffffffd9d989f148 +[ 55.008947] x23: ffffffda1c2a4008 x22: 0000000000000002 x21: ffffffc080673d38 +[ 55.008968] x20: ffffff8101238000 x19: ffffff8104f83188 x18: 0000000000000000 +[ 55.008988] x17: 0000000000000000 x16: ffffffda1bd04d18 x15: 00000055bb08bc90 +[ 55.009715] x14: 0000000000000000 x13: 0000000000000000 x12: ffffffda1bd4cbb0 +[ 55.010433] x11: 00000000fa83b2da x10: 0000000000001a40 x9 : ffffffda1bd04d04 +[ 55.011162] x8 : ffffff8102097b80 x7 : 0000000000000000 x6 : 00000000030a5857 +[ 55.011880] x5 : 00ffffffffffffff x4 : 0300000005200470 x3 : 0300000005200470 +[ 55.012598] x2 : ffffff8101238000 x1 : 0000000000000021 x0 : 0300000005200470 +[ 55.013292] Call trace: +[ 55.013959] __mutex_lock.constprop.0+0x90/0x608 +[ 55.014646] __mutex_lock_slowpath+0x1c/0x30 +[ 55.015317] mutex_lock+0x50/0x68 +[ 55.015961] v3d_perfmon_stop+0x40/0xe0 [v3d] +[ 55.016627] v3d_bin_job_run+0x10c/0x2d8 [v3d] +[ 55.017282] drm_sched_main+0x178/0x3f8 [gpu_sched] +[ 55.017921] kthread+0x11c/0x128 +[ 55.018554] ret_from_fork+0x10/0x20 +[ 55.019168] Code: f9400260 f1001c1f 54001ea9 927df000 (b9403401) +[ 55.019776] ---[ end trace 0000000000000000 ]--- +[ 55.020411] note: v3d_bin[166] exited with preempt_count 1 + +This issue arises because, upon closing the file descriptor (which happens +when we interrupt `kmscube`), the active performance monitor is not +stopped. Although all perfmons are destroyed in `v3d_perfmon_close_file()`, +the active performance monitor's pointer (`v3d->active_perfmon`) is still +retained. + +If `kmscube` is run again, the driver will attempt to stop the active +performance monitor using the stale pointer in `v3d->active_perfmon`. +However, this pointer is no longer valid because the previous process has +already terminated, and all performance monitors associated with it have +been destroyed and freed. + +To fix this, when the active performance monitor belongs to a given +process, explicitly stop it before destroying and freeing it. + +Cc: stable@vger.kernel.org # v5.15+ +Closes: https://github.com/raspberrypi/linux/issues/6389 +Fixes: 26a4dc29b74a ("drm/v3d: Expose performance counters to userspace") +Signed-off-by: Maíra Canal +Reviewed-by: Juan A. Suarez +Link: https://patchwork.freedesktop.org/patch/msgid/20241004130625.918580-2-mcanal@igalia.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/v3d/v3d_perfmon.c | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +--- a/drivers/gpu/drm/v3d/v3d_perfmon.c ++++ b/drivers/gpu/drm/v3d/v3d_perfmon.c +@@ -289,6 +289,11 @@ void v3d_perfmon_open_file(struct v3d_fi + static int v3d_perfmon_idr_del(int id, void *elem, void *data) + { + struct v3d_perfmon *perfmon = elem; ++ struct v3d_dev *v3d = (struct v3d_dev *)data; ++ ++ /* If the active perfmon is being destroyed, stop it first */ ++ if (perfmon == v3d->active_perfmon) ++ v3d_perfmon_stop(v3d, perfmon, false); + + v3d_perfmon_put(perfmon); + +@@ -297,8 +302,10 @@ static int v3d_perfmon_idr_del(int id, v + + void v3d_perfmon_close_file(struct v3d_file_priv *v3d_priv) + { ++ struct v3d_dev *v3d = v3d_priv->v3d; ++ + mutex_lock(&v3d_priv->perfmon.lock); +- idr_for_each(&v3d_priv->perfmon.idr, v3d_perfmon_idr_del, NULL); ++ idr_for_each(&v3d_priv->perfmon.idr, v3d_perfmon_idr_del, v3d); + idr_destroy(&v3d_priv->perfmon.idr); + mutex_unlock(&v3d_priv->perfmon.lock); + mutex_destroy(&v3d_priv->perfmon.lock); diff --git a/queue-6.11/drm-vc4-stop-the-active-perfmon-before-being-destroyed.patch b/queue-6.11/drm-vc4-stop-the-active-perfmon-before-being-destroyed.patch new file mode 100644 index 00000000000..c0ae9bd08e0 --- /dev/null +++ b/queue-6.11/drm-vc4-stop-the-active-perfmon-before-being-destroyed.patch @@ -0,0 +1,62 @@ +From 0b2ad4f6f2bec74a5287d96cb2325a5e11706f22 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Ma=C3=ADra=20Canal?= +Date: Fri, 4 Oct 2024 09:36:00 -0300 +Subject: drm/vc4: Stop the active perfmon before being destroyed +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Maíra Canal + +commit 0b2ad4f6f2bec74a5287d96cb2325a5e11706f22 upstream. + +Upon closing the file descriptor, the active performance monitor is not +stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`, +the active performance monitor's pointer (`vc4->active_perfmon`) is still +retained. + +If we open a new file descriptor and submit a few jobs with performance +monitors, the driver will attempt to stop the active performance monitor +using the stale pointer in `vc4->active_perfmon`. However, this pointer +is no longer valid because the previous process has already terminated, +and all performance monitors associated with it have been destroyed and +freed. + +To fix this, when the active performance monitor belongs to a given +process, explicitly stop it before destroying and freeing it. + +Cc: stable@vger.kernel.org # v4.17+ +Cc: Boris Brezillon +Cc: Juan A. Suarez Romero +Fixes: 65101d8c9108 ("drm/vc4: Expose performance counters to userspace") +Signed-off-by: Maíra Canal +Reviewed-by: Juan A. Suarez +Link: https://patchwork.freedesktop.org/patch/msgid/20241004123817.890016-2-mcanal@igalia.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/vc4/vc4_perfmon.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +--- a/drivers/gpu/drm/vc4/vc4_perfmon.c ++++ b/drivers/gpu/drm/vc4/vc4_perfmon.c +@@ -116,6 +116,11 @@ void vc4_perfmon_open_file(struct vc4_fi + static int vc4_perfmon_idr_del(int id, void *elem, void *data) + { + struct vc4_perfmon *perfmon = elem; ++ struct vc4_dev *vc4 = (struct vc4_dev *)data; ++ ++ /* If the active perfmon is being destroyed, stop it first */ ++ if (perfmon == vc4->active_perfmon) ++ vc4_perfmon_stop(vc4, perfmon, false); + + vc4_perfmon_put(perfmon); + +@@ -130,7 +135,7 @@ void vc4_perfmon_close_file(struct vc4_f + return; + + mutex_lock(&vc4file->perfmon.lock); +- idr_for_each(&vc4file->perfmon.idr, vc4_perfmon_idr_del, NULL); ++ idr_for_each(&vc4file->perfmon.idr, vc4_perfmon_idr_del, vc4); + idr_destroy(&vc4file->perfmon.idr); + mutex_unlock(&vc4file->perfmon.lock); + mutex_destroy(&vc4file->perfmon.lock); diff --git a/queue-6.11/drm-xe-ct-fix-xa_store-error-checking.patch b/queue-6.11/drm-xe-ct-fix-xa_store-error-checking.patch new file mode 100644 index 00000000000..2e550754bbc --- /dev/null +++ b/queue-6.11/drm-xe-ct-fix-xa_store-error-checking.patch @@ -0,0 +1,68 @@ +From e863781abe4fe430406dd075ca0cab99165b4e63 Mon Sep 17 00:00:00 2001 +From: Matthew Auld +Date: Tue, 1 Oct 2024 09:43:48 +0100 +Subject: drm/xe/ct: fix xa_store() error checking + +From: Matthew Auld + +commit e863781abe4fe430406dd075ca0cab99165b4e63 upstream. + +Looks like we are meant to use xa_err() to extract the error encoded in +the ptr. + +Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") +Signed-off-by: Matthew Auld +Cc: Matthew Brost +Cc: Badal Nilawar +Cc: # v6.8+ +Reviewed-by: Badal Nilawar +Link: https://patchwork.freedesktop.org/patch/msgid/20241001084346.98516-6-matthew.auld@intel.com +(cherry picked from commit 1aa4b7864707886fa40d959483591f3d3937fa28) +Signed-off-by: Lucas De Marchi +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/xe/xe_guc_ct.c | 23 ++++++++--------------- + 1 file changed, 8 insertions(+), 15 deletions(-) + +--- a/drivers/gpu/drm/xe/xe_guc_ct.c ++++ b/drivers/gpu/drm/xe/xe_guc_ct.c +@@ -658,16 +658,12 @@ static int __guc_ct_send_locked(struct x + num_g2h = 1; + + if (g2h_fence_needs_alloc(g2h_fence)) { +- void *ptr; +- + g2h_fence->seqno = next_ct_seqno(ct, true); +- ptr = xa_store(&ct->fence_lookup, +- g2h_fence->seqno, +- g2h_fence, GFP_ATOMIC); +- if (IS_ERR(ptr)) { +- ret = PTR_ERR(ptr); ++ ret = xa_err(xa_store(&ct->fence_lookup, ++ g2h_fence->seqno, g2h_fence, ++ GFP_ATOMIC)); ++ if (ret) + goto out; +- } + } + + seqno = g2h_fence->seqno; +@@ -870,14 +866,11 @@ retry: + retry_same_fence: + ret = guc_ct_send(ct, action, len, 0, 0, &g2h_fence); + if (unlikely(ret == -ENOMEM)) { +- void *ptr; +- + /* Retry allocation /w GFP_KERNEL */ +- ptr = xa_store(&ct->fence_lookup, +- g2h_fence.seqno, +- &g2h_fence, GFP_KERNEL); +- if (IS_ERR(ptr)) +- return PTR_ERR(ptr); ++ ret = xa_err(xa_store(&ct->fence_lookup, g2h_fence.seqno, ++ &g2h_fence, GFP_KERNEL)); ++ if (ret) ++ return ret; + + goto retry_same_fence; + } else if (unlikely(ret)) { diff --git a/queue-6.11/drm-xe-ct-prevent-uaf-in-send_recv.patch b/queue-6.11/drm-xe-ct-prevent-uaf-in-send_recv.patch new file mode 100644 index 00000000000..50edd8ac8da --- /dev/null +++ b/queue-6.11/drm-xe-ct-prevent-uaf-in-send_recv.patch @@ -0,0 +1,78 @@ +From db7f92af626178ba59dbbcdd5dee9ec24a987a88 Mon Sep 17 00:00:00 2001 +From: Matthew Auld +Date: Tue, 1 Oct 2024 09:43:47 +0100 +Subject: drm/xe/ct: prevent UAF in send_recv() + +From: Matthew Auld + +commit db7f92af626178ba59dbbcdd5dee9ec24a987a88 upstream. + +Ensure we serialize with completion side to prevent UAF with fence going +out of scope on the stack, since we have no clue if it will fire after +the timeout before we can erase from the xa. Also we have some dependent +loads and stores for which we need the correct ordering, and we lack the +needed barriers. Fix this by grabbing the ct->lock after the wait, which +is also held by the completion side. + +v2 (Badal): + - Also print done after acquiring the lock and seeing timeout. + +Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") +Signed-off-by: Matthew Auld +Cc: Matthew Brost +Cc: Badal Nilawar +Cc: # v6.8+ +Reviewed-by: Badal Nilawar +Link: https://patchwork.freedesktop.org/patch/msgid/20241001084346.98516-5-matthew.auld@intel.com +(cherry picked from commit 52789ce35c55ccd30c4b67b9cc5b2af55e0122ea) +Signed-off-by: Lucas De Marchi +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/xe/xe_guc_ct.c | 21 ++++++++++++++++++--- + 1 file changed, 18 insertions(+), 3 deletions(-) + +--- a/drivers/gpu/drm/xe/xe_guc_ct.c ++++ b/drivers/gpu/drm/xe/xe_guc_ct.c +@@ -894,16 +894,26 @@ retry_same_fence: + } + + ret = wait_event_timeout(ct->g2h_fence_wq, g2h_fence.done, HZ); ++ ++ /* ++ * Ensure we serialize with completion side to prevent UAF with fence going out of scope on ++ * the stack, since we have no clue if it will fire after the timeout before we can erase ++ * from the xa. Also we have some dependent loads and stores below for which we need the ++ * correct ordering, and we lack the needed barriers. ++ */ ++ mutex_lock(&ct->lock); + if (!ret) { +- xe_gt_err(gt, "Timed out wait for G2H, fence %u, action %04x", +- g2h_fence.seqno, action[0]); ++ xe_gt_err(gt, "Timed out wait for G2H, fence %u, action %04x, done %s", ++ g2h_fence.seqno, action[0], str_yes_no(g2h_fence.done)); + xa_erase_irq(&ct->fence_lookup, g2h_fence.seqno); ++ mutex_unlock(&ct->lock); + return -ETIME; + } + + if (g2h_fence.retry) { + xe_gt_dbg(gt, "H2G action %#x retrying: reason %#x\n", + action[0], g2h_fence.reason); ++ mutex_unlock(&ct->lock); + goto retry; + } + if (g2h_fence.fail) { +@@ -912,7 +922,12 @@ retry_same_fence: + ret = -EIO; + } + +- return ret > 0 ? response_buffer ? g2h_fence.response_len : g2h_fence.response_data : ret; ++ if (ret > 0) ++ ret = response_buffer ? g2h_fence.response_len : g2h_fence.response_data; ++ ++ mutex_unlock(&ct->lock); ++ ++ return ret; + } + + /** diff --git a/queue-6.11/drm-xe-guc_submit-fix-xa_store-error-checking.patch b/queue-6.11/drm-xe-guc_submit-fix-xa_store-error-checking.patch new file mode 100644 index 00000000000..3d14b7b656c --- /dev/null +++ b/queue-6.11/drm-xe-guc_submit-fix-xa_store-error-checking.patch @@ -0,0 +1,52 @@ +From 42465603a31089a89b5fe25966ecedb841eeaa0f Mon Sep 17 00:00:00 2001 +From: Matthew Auld +Date: Tue, 1 Oct 2024 09:43:49 +0100 +Subject: drm/xe/guc_submit: fix xa_store() error checking + +From: Matthew Auld + +commit 42465603a31089a89b5fe25966ecedb841eeaa0f upstream. + +Looks like we are meant to use xa_err() to extract the error encoded in +the ptr. + +Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") +Signed-off-by: Matthew Auld +Cc: Matthew Brost +Cc: Badal Nilawar +Cc: # v6.8+ +Reviewed-by: Badal Nilawar +Link: https://patchwork.freedesktop.org/patch/msgid/20241001084346.98516-7-matthew.auld@intel.com +(cherry picked from commit f040327238b1a8311598c40ac94464e77fff368c) +Signed-off-by: Lucas De Marchi +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/xe/xe_guc_submit.c | 9 +++------ + 1 file changed, 3 insertions(+), 6 deletions(-) + +--- a/drivers/gpu/drm/xe/xe_guc_submit.c ++++ b/drivers/gpu/drm/xe/xe_guc_submit.c +@@ -393,7 +393,6 @@ static void __release_guc_id(struct xe_g + static int alloc_guc_id(struct xe_guc *guc, struct xe_exec_queue *q) + { + int ret; +- void *ptr; + int i; + + /* +@@ -413,12 +412,10 @@ static int alloc_guc_id(struct xe_guc *g + q->guc->id = ret; + + for (i = 0; i < q->width; ++i) { +- ptr = xa_store(&guc->submission_state.exec_queue_lookup, +- q->guc->id + i, q, GFP_NOWAIT); +- if (IS_ERR(ptr)) { +- ret = PTR_ERR(ptr); ++ ret = xa_err(xa_store(&guc->submission_state.exec_queue_lookup, ++ q->guc->id + i, q, GFP_NOWAIT)); ++ if (ret) + goto err_release; +- } + } + + return 0; diff --git a/queue-6.11/fs-proc-kcore.c-allow-translation-of-physical-memory-addresses.patch b/queue-6.11/fs-proc-kcore.c-allow-translation-of-physical-memory-addresses.patch new file mode 100644 index 00000000000..0b50029053f --- /dev/null +++ b/queue-6.11/fs-proc-kcore.c-allow-translation-of-physical-memory-addresses.patch @@ -0,0 +1,122 @@ +From 3d5854d75e3187147613130561b58f0b06166172 Mon Sep 17 00:00:00 2001 +From: Alexander Gordeev +Date: Mon, 30 Sep 2024 14:21:19 +0200 +Subject: fs/proc/kcore.c: allow translation of physical memory addresses + +From: Alexander Gordeev + +commit 3d5854d75e3187147613130561b58f0b06166172 upstream. + +When /proc/kcore is read an attempt to read the first two pages results in +HW-specific page swap on s390 and another (so called prefix) pages are +accessed instead. That leads to a wrong read. + +Allow architecture-specific translation of memory addresses using +kc_xlate_dev_mem_ptr() and kc_unxlate_dev_mem_ptr() callbacks similarily +to /dev/mem xlate_dev_mem_ptr() and unxlate_dev_mem_ptr() callbacks. That +way an architecture can deal with specific physical memory ranges. + +Re-use the existing /dev/mem callback implementation on s390, which +handles the described prefix pages swapping correctly. + +For other architectures the default callback is basically NOP. It is +expected the condition (vaddr == __va(__pa(vaddr))) always holds true for +KCORE_RAM memory type. + +Link: https://lkml.kernel.org/r/20240930122119.1651546-1-agordeev@linux.ibm.com +Signed-off-by: Alexander Gordeev +Suggested-by: Heiko Carstens +Cc: Vasily Gorbik +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + arch/s390/include/asm/io.h | 2 ++ + fs/proc/kcore.c | 36 ++++++++++++++++++++++++++++++++++-- + 2 files changed, 36 insertions(+), 2 deletions(-) + +--- a/arch/s390/include/asm/io.h ++++ b/arch/s390/include/asm/io.h +@@ -16,8 +16,10 @@ + #include + + #define xlate_dev_mem_ptr xlate_dev_mem_ptr ++#define kc_xlate_dev_mem_ptr xlate_dev_mem_ptr + void *xlate_dev_mem_ptr(phys_addr_t phys); + #define unxlate_dev_mem_ptr unxlate_dev_mem_ptr ++#define kc_unxlate_dev_mem_ptr unxlate_dev_mem_ptr + void unxlate_dev_mem_ptr(phys_addr_t phys, void *addr); + + #define IO_SPACE_LIMIT 0 +--- a/fs/proc/kcore.c ++++ b/fs/proc/kcore.c +@@ -50,6 +50,20 @@ static struct proc_dir_entry *proc_root_ + #define kc_offset_to_vaddr(o) ((o) + PAGE_OFFSET) + #endif + ++#ifndef kc_xlate_dev_mem_ptr ++#define kc_xlate_dev_mem_ptr kc_xlate_dev_mem_ptr ++static inline void *kc_xlate_dev_mem_ptr(phys_addr_t phys) ++{ ++ return __va(phys); ++} ++#endif ++#ifndef kc_unxlate_dev_mem_ptr ++#define kc_unxlate_dev_mem_ptr kc_unxlate_dev_mem_ptr ++static inline void kc_unxlate_dev_mem_ptr(phys_addr_t phys, void *virt) ++{ ++} ++#endif ++ + static LIST_HEAD(kclist_head); + static DECLARE_RWSEM(kclist_lock); + static int kcore_need_update = 1; +@@ -471,6 +485,8 @@ static ssize_t read_kcore_iter(struct ki + while (buflen) { + struct page *page; + unsigned long pfn; ++ phys_addr_t phys; ++ void *__start; + + /* + * If this is the first iteration or the address is not within +@@ -537,7 +553,8 @@ static ssize_t read_kcore_iter(struct ki + } + break; + case KCORE_RAM: +- pfn = __pa(start) >> PAGE_SHIFT; ++ phys = __pa(start); ++ pfn = phys >> PAGE_SHIFT; + page = pfn_to_online_page(pfn); + + /* +@@ -557,13 +574,28 @@ static ssize_t read_kcore_iter(struct ki + fallthrough; + case KCORE_VMEMMAP: + case KCORE_TEXT: ++ if (m->type == KCORE_RAM) { ++ __start = kc_xlate_dev_mem_ptr(phys); ++ if (!__start) { ++ ret = -ENOMEM; ++ if (iov_iter_zero(tsz, iter) != tsz) ++ ret = -EFAULT; ++ goto out; ++ } ++ } else { ++ __start = (void *)start; ++ } ++ + /* + * Sadly we must use a bounce buffer here to be able to + * make use of copy_from_kernel_nofault(), as these + * memory regions might not always be mapped on all + * architectures. + */ +- if (copy_from_kernel_nofault(buf, (void *)start, tsz)) { ++ ret = copy_from_kernel_nofault(buf, __start, tsz); ++ if (m->type == KCORE_RAM) ++ kc_unxlate_dev_mem_ptr(phys, __start); ++ if (ret) { + if (iov_iter_zero(tsz, iter) != tsz) { + ret = -EFAULT; + goto out; diff --git a/queue-6.11/ice-fix-improper-handling-of-refcount-in-ice_dpll_init_rclk_pins.patch b/queue-6.11/ice-fix-improper-handling-of-refcount-in-ice_dpll_init_rclk_pins.patch new file mode 100644 index 00000000000..b5cafc2a19d --- /dev/null +++ b/queue-6.11/ice-fix-improper-handling-of-refcount-in-ice_dpll_init_rclk_pins.patch @@ -0,0 +1,58 @@ +From ccca30a18e36a742e606d5bf0630e75be7711d0a Mon Sep 17 00:00:00 2001 +From: Gui-Dong Han +Date: Tue, 3 Sep 2024 11:48:43 +0000 +Subject: ice: Fix improper handling of refcount in ice_dpll_init_rclk_pins() + +From: Gui-Dong Han + +commit ccca30a18e36a742e606d5bf0630e75be7711d0a upstream. + +This patch addresses a reference count handling issue in the +ice_dpll_init_rclk_pins() function. The function calls ice_dpll_get_pins(), +which increments the reference count of the relevant resources. However, +if the condition WARN_ON((!vsi || !vsi->netdev)) is met, the function +currently returns an error without properly releasing the resources +acquired by ice_dpll_get_pins(), leading to a reference count leak. + +To resolve this, the check has been moved to the top of the function. This +ensures that the function verifies the state before any resources are +acquired, avoiding the need for additional resource management in the +error path. + +This bug was identified by an experimental static analysis tool developed +by our team. The tool specializes in analyzing reference count operations +and detecting potential issues where resources are not properly managed. +In this case, the tool flagged the missing release operation as a +potential problem, which led to the development of this patch. + +Fixes: d7999f5ea64b ("ice: implement dpll interface to control cgu") +Cc: stable@vger.kernel.org +Signed-off-by: Gui-Dong Han +Reviewed-by: Simon Horman +Tested-by: Pucha Himasekhar Reddy (A Contingent worker at Intel) +Signed-off-by: Tony Nguyen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/intel/ice/ice_dpll.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/net/ethernet/intel/ice/ice_dpll.c ++++ b/drivers/net/ethernet/intel/ice/ice_dpll.c +@@ -1628,6 +1628,8 @@ ice_dpll_init_rclk_pins(struct ice_pf *p + struct dpll_pin *parent; + int ret, i; + ++ if (WARN_ON((!vsi || !vsi->netdev))) ++ return -EINVAL; + ret = ice_dpll_get_pins(pf, pin, start_idx, ICE_DPLL_RCLK_NUM_PER_PF, + pf->dplls.clock_id); + if (ret) +@@ -1643,8 +1645,6 @@ ice_dpll_init_rclk_pins(struct ice_pf *p + if (ret) + goto unregister_pins; + } +- if (WARN_ON((!vsi || !vsi->netdev))) +- return -EINVAL; + dpll_netdev_pin_set(vsi->netdev, pf->dplls.rclk.pin); + + return 0; diff --git a/queue-6.11/ice-fix-improper-handling-of-refcount-in-ice_sriov_set_msix_vec_count.patch b/queue-6.11/ice-fix-improper-handling-of-refcount-in-ice_sriov_set_msix_vec_count.patch new file mode 100644 index 00000000000..8f0b246d3f0 --- /dev/null +++ b/queue-6.11/ice-fix-improper-handling-of-refcount-in-ice_sriov_set_msix_vec_count.patch @@ -0,0 +1,71 @@ +From d517cf89874c6039e6294b18d66f40988e62502a Mon Sep 17 00:00:00 2001 +From: Gui-Dong Han +Date: Tue, 3 Sep 2024 11:59:43 +0000 +Subject: ice: Fix improper handling of refcount in ice_sriov_set_msix_vec_count() + +From: Gui-Dong Han + +commit d517cf89874c6039e6294b18d66f40988e62502a upstream. + +This patch addresses an issue with improper reference count handling in the +ice_sriov_set_msix_vec_count() function. + +First, the function calls ice_get_vf_by_id(), which increments the +reference count of the vf pointer. If the subsequent call to +ice_get_vf_vsi() fails, the function currently returns an error without +decrementing the reference count of the vf pointer, leading to a reference +count leak. The correct behavior, as implemented in this patch, is to +decrement the reference count using ice_put_vf(vf) before returning an +error when vsi is NULL. + +Second, the function calls ice_sriov_get_irqs(), which sets +vf->first_vector_idx. If this call returns a negative value, indicating an +error, the function returns an error without decrementing the reference +count of the vf pointer, resulting in another reference count leak. The +patch addresses this by adding a call to ice_put_vf(vf) before returning +an error when vf->first_vector_idx < 0. + +This bug was identified by an experimental static analysis tool developed +by our team. The tool specializes in analyzing reference count operations +and identifying potential mismanagement of reference counts. In this case, +the tool flagged the missing decrement operation as a potential issue, +leading to this patch. + +Fixes: 4035c72dc1ba ("ice: reconfig host after changing MSI-X on VF") +Fixes: 4d38cb44bd32 ("ice: manage VFs MSI-X using resource tracking") +Cc: stable@vger.kernel.org +Signed-off-by: Gui-Dong Han +Reviewed-by: Simon Horman +Tested-by: Rafal Romanowski +Signed-off-by: Tony Nguyen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/intel/ice/ice_sriov.c | 8 ++++++-- + 1 file changed, 6 insertions(+), 2 deletions(-) + +--- a/drivers/net/ethernet/intel/ice/ice_sriov.c ++++ b/drivers/net/ethernet/intel/ice/ice_sriov.c +@@ -1096,8 +1096,10 @@ int ice_sriov_set_msix_vec_count(struct + return -ENOENT; + + vsi = ice_get_vf_vsi(vf); +- if (!vsi) ++ if (!vsi) { ++ ice_put_vf(vf); + return -ENOENT; ++ } + + prev_msix = vf->num_msix; + prev_queues = vf->num_vf_qs; +@@ -1145,8 +1147,10 @@ unroll: + vf->num_msix = prev_msix; + vf->num_vf_qs = prev_queues; + vf->first_vector_idx = ice_sriov_get_irqs(pf, vf->num_msix); +- if (vf->first_vector_idx < 0) ++ if (vf->first_vector_idx < 0) { ++ ice_put_vf(vf); + return -EINVAL; ++ } + + if (needs_rebuild) { + vsi->req_txq = prev_queues; diff --git a/queue-6.11/idpf-use-actual-mbx-receive-payload-length.patch b/queue-6.11/idpf-use-actual-mbx-receive-payload-length.patch new file mode 100644 index 00000000000..7e6f31a2360 --- /dev/null +++ b/queue-6.11/idpf-use-actual-mbx-receive-payload-length.patch @@ -0,0 +1,72 @@ +From 640f70063e6d3a76a63f57e130fba43ba8c7e980 Mon Sep 17 00:00:00 2001 +From: Joshua Hay +Date: Tue, 3 Sep 2024 11:49:56 -0700 +Subject: idpf: use actual mbx receive payload length + +From: Joshua Hay + +commit 640f70063e6d3a76a63f57e130fba43ba8c7e980 upstream. + +When a mailbox message is received, the driver is checking for a non 0 +datalen in the controlq descriptor. If it is valid, the payload is +attached to the ctlq message to give to the upper layer. However, the +payload response size given to the upper layer was taken from the buffer +metadata which is _always_ the max buffer size. This meant the API was +returning 4K as the payload size for all messages. This went unnoticed +since the virtchnl exchange response logic was checking for a response +size less than 0 (error), not less than exact size, or not greater than +or equal to the max mailbox buffer size (4K). All of these checks will +pass in the success case since the size provided is always 4K. However, +this breaks anyone that wants to validate the exact response size. + +Fetch the actual payload length from the value provided in the +descriptor data_len field (instead of the buffer metadata). + +Unfortunately, this means we lose some extra error parsing for variable +sized virtchnl responses such as create vport and get ptypes. However, +the original checks weren't really helping anyways since the size was +_always_ 4K. + +Fixes: 34c21fa894a1 ("idpf: implement virtchnl transaction manager") +Cc: stable@vger.kernel.org # 6.9+ +Signed-off-by: Joshua Hay +Reviewed-by: Przemek Kitszel +Tested-by: Krishneil Singh +Signed-off-by: Tony Nguyen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/intel/idpf/idpf_virtchnl.c | 9 +-------- + 1 file changed, 1 insertion(+), 8 deletions(-) + +--- a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c ++++ b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c +@@ -666,7 +666,7 @@ idpf_vc_xn_forward_reply(struct idpf_ada + + if (ctlq_msg->data_len) { + payload = ctlq_msg->ctx.indirect.payload->va; +- payload_size = ctlq_msg->ctx.indirect.payload->size; ++ payload_size = ctlq_msg->data_len; + } + + xn->reply_sz = payload_size; +@@ -1295,10 +1295,6 @@ int idpf_send_create_vport_msg(struct id + err = reply_sz; + goto free_vport_params; + } +- if (reply_sz < IDPF_CTLQ_MAX_BUF_LEN) { +- err = -EIO; +- goto free_vport_params; +- } + + return 0; + +@@ -2602,9 +2598,6 @@ int idpf_send_get_rx_ptype_msg(struct id + if (reply_sz < 0) + return reply_sz; + +- if (reply_sz < IDPF_CTLQ_MAX_BUF_LEN) +- return -EIO; +- + ptypes_recvd += le16_to_cpu(ptype_info->num_ptypes); + if (ptypes_recvd > max_ptype) + return -EINVAL; diff --git a/queue-6.11/kthread-unpark-only-parked-kthread.patch b/queue-6.11/kthread-unpark-only-parked-kthread.patch new file mode 100644 index 00000000000..9ddefb7a069 --- /dev/null +++ b/queue-6.11/kthread-unpark-only-parked-kthread.patch @@ -0,0 +1,65 @@ +From 214e01ad4ed7158cab66498810094fac5d09b218 Mon Sep 17 00:00:00 2001 +From: Frederic Weisbecker +Date: Fri, 13 Sep 2024 23:46:34 +0200 +Subject: kthread: unpark only parked kthread + +From: Frederic Weisbecker + +commit 214e01ad4ed7158cab66498810094fac5d09b218 upstream. + +Calling into kthread unparking unconditionally is mostly harmless when +the kthread is already unparked. The wake up is then simply ignored +because the target is not in TASK_PARKED state. + +However if the kthread is per CPU, the wake up is preceded by a call +to kthread_bind() which expects the task to be inactive and in +TASK_PARKED state, which obviously isn't the case if it is unparked. + +As a result, calling kthread_stop() on an unparked per-cpu kthread +triggers such a warning: + + WARNING: CPU: 0 PID: 11 at kernel/kthread.c:525 __kthread_bind_mask kernel/kthread.c:525 + + kthread_stop+0x17a/0x630 kernel/kthread.c:707 + destroy_workqueue+0x136/0xc40 kernel/workqueue.c:5810 + wg_destruct+0x1e2/0x2e0 drivers/net/wireguard/device.c:257 + netdev_run_todo+0xe1a/0x1000 net/core/dev.c:10693 + default_device_exit_batch+0xa14/0xa90 net/core/dev.c:11769 + ops_exit_list net/core/net_namespace.c:178 [inline] + cleanup_net+0x89d/0xcc0 net/core/net_namespace.c:640 + process_one_work kernel/workqueue.c:3231 [inline] + process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 + worker_thread+0x86d/0xd70 kernel/workqueue.c:3393 + kthread+0x2f0/0x390 kernel/kthread.c:389 + ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 + ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 + + +Fix this with skipping unecessary unparking while stopping a kthread. + +Link: https://lkml.kernel.org/r/20240913214634.12557-1-frederic@kernel.org +Fixes: 5c25b5ff89f0 ("workqueue: Tag bound workers with KTHREAD_IS_PER_CPU") +Signed-off-by: Frederic Weisbecker +Reported-by: syzbot+943d34fa3cf2191e3068@syzkaller.appspotmail.com +Tested-by: syzbot+943d34fa3cf2191e3068@syzkaller.appspotmail.com +Suggested-by: Thomas Gleixner +Cc: Hillf Danton +Cc: Tejun Heo +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + kernel/kthread.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/kernel/kthread.c ++++ b/kernel/kthread.c +@@ -623,6 +623,8 @@ void kthread_unpark(struct task_struct * + { + struct kthread *kthread = to_kthread(k); + ++ if (!test_bit(KTHREAD_SHOULD_PARK, &kthread->flags)) ++ return; + /* + * Newly created kthread was parked when the CPU was offline. + * The binding was lost and we need to set it again. diff --git a/queue-6.11/mmc-sdhci-of-dwcmshc-prevent-stale-command-interrupt-handling.patch b/queue-6.11/mmc-sdhci-of-dwcmshc-prevent-stale-command-interrupt-handling.patch new file mode 100644 index 00000000000..e9a46326c85 --- /dev/null +++ b/queue-6.11/mmc-sdhci-of-dwcmshc-prevent-stale-command-interrupt-handling.patch @@ -0,0 +1,130 @@ +From 27e8fe0da3b75520edfba9cee0030aeb5aef1505 Mon Sep 17 00:00:00 2001 +From: Michal Wilczynski +Date: Tue, 8 Oct 2024 12:03:27 +0200 +Subject: mmc: sdhci-of-dwcmshc: Prevent stale command interrupt handling + +From: Michal Wilczynski + +commit 27e8fe0da3b75520edfba9cee0030aeb5aef1505 upstream. + +While working with the T-Head 1520 LicheePi4A SoC, certain conditions +arose that allowed me to reproduce a race issue in the sdhci code. + +To reproduce the bug, you need to enable the sdio1 controller in the +device tree file +`arch/riscv/boot/dts/thead/th1520-lichee-module-4a.dtsi` as follows: + +&sdio1 { + bus-width = <4>; + max-frequency = <100000000>; + no-sd; + no-mmc; + broken-cd; + cap-sd-highspeed; + post-power-on-delay-ms = <50>; + status = "okay"; + wakeup-source; + keep-power-in-suspend; +}; + +When resetting the SoC using the reset button, the following messages +appear in the dmesg log: + +[ 8.164898] mmc2: Got command interrupt 0x00000001 even though no +command operation was in progress. +[ 8.174054] mmc2: sdhci: ============ SDHCI REGISTER DUMP =========== +[ 8.180503] mmc2: sdhci: Sys addr: 0x00000000 | Version: 0x00000005 +[ 8.186950] mmc2: sdhci: Blk size: 0x00000000 | Blk cnt: 0x00000000 +[ 8.193395] mmc2: sdhci: Argument: 0x00000000 | Trn mode: 0x00000000 +[ 8.199841] mmc2: sdhci: Present: 0x03da0000 | Host ctl: 0x00000000 +[ 8.206287] mmc2: sdhci: Power: 0x0000000f | Blk gap: 0x00000000 +[ 8.212733] mmc2: sdhci: Wake-up: 0x00000000 | Clock: 0x0000decf +[ 8.219178] mmc2: sdhci: Timeout: 0x00000000 | Int stat: 0x00000000 +[ 8.225622] mmc2: sdhci: Int enab: 0x00ff1003 | Sig enab: 0x00ff1003 +[ 8.232068] mmc2: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00000000 +[ 8.238513] mmc2: sdhci: Caps: 0x3f69c881 | Caps_1: 0x08008177 +[ 8.244959] mmc2: sdhci: Cmd: 0x00000502 | Max curr: 0x00191919 +[ 8.254115] mmc2: sdhci: Resp[0]: 0x00001009 | Resp[1]: 0x00000000 +[ 8.260561] mmc2: sdhci: Resp[2]: 0x00000000 | Resp[3]: 0x00000000 +[ 8.267005] mmc2: sdhci: Host ctl2: 0x00001000 +[ 8.271453] mmc2: sdhci: ADMA Err: 0x00000000 | ADMA Ptr: +0x0000000000000000 +[ 8.278594] mmc2: sdhci: ============================================ + +I also enabled some traces to better understand the problem: + + kworker/3:1-62 [003] ..... 8.163538: mmc_request_start: +mmc2: start struct mmc_request[000000000d30cc0c]: cmd_opcode=5 +cmd_arg=0x0 cmd_flags=0x2e1 cmd_retries=0 stop_opcode=0 stop_arg=0x0 +stop_flags=0x0 stop_retries=0 sbc_opcode=0 sbc_arg=0x0 sbc_flags=0x0 +sbc_retires=0 blocks=0 block_size=0 blk_addr=0 data_flags=0x0 tag=0 +can_retune=0 doing_retune=0 retune_now=0 need_retune=0 hold_retune=1 +retune_period=0 + -0 [000] d.h2. 8.164816: sdhci_cmd_irq: +hw_name=ffe70a0000.mmc quirks=0x2008008 quirks2=0x8 intmask=0x10000 +intmask_p=0x18000 + irq/24-mmc2-96 [000] ..... 8.164840: sdhci_thread_irq: +msg= + irq/24-mmc2-96 [000] d.h2. 8.164896: sdhci_cmd_irq: +hw_name=ffe70a0000.mmc quirks=0x2008008 quirks2=0x8 intmask=0x1 +intmask_p=0x1 + irq/24-mmc2-96 [000] ..... 8.285142: mmc_request_done: +mmc2: end struct mmc_request[000000000d30cc0c]: cmd_opcode=5 +cmd_err=-110 cmd_resp=0x0 0x0 0x0 0x0 cmd_retries=0 stop_opcode=0 +stop_err=0 stop_resp=0x0 0x0 0x0 0x0 stop_retries=0 sbc_opcode=0 +sbc_err=0 sbc_resp=0x0 0x0 0x0 0x0 sbc_retries=0 bytes_xfered=0 +data_err=0 tag=0 can_retune=0 doing_retune=0 retune_now=0 need_retune=0 +hold_retune=1 retune_period=0 + +Here's what happens: the __mmc_start_request function is called with +opcode 5. Since the power to the Wi-Fi card, which resides on this SDIO +bus, is initially off after the reset, an interrupt SDHCI_INT_TIMEOUT is +triggered. Immediately after that, a second interrupt SDHCI_INT_RESPONSE +is triggered. Depending on the exact timing, these conditions can +trigger the following race problem: + +1) The sdhci_cmd_irq top half handles the command as an error. It sets + host->cmd to NULL and host->pending_reset to true. +2) The sdhci_thread_irq bottom half is scheduled next and executes faster + than the second interrupt handler for SDHCI_INT_RESPONSE. It clears + host->pending_reset before the SDHCI_INT_RESPONSE handler runs. +3) The pending interrupt SDHCI_INT_RESPONSE handler gets called, triggering + a code path that prints: "mmc2: Got command interrupt 0x00000001 even + though no command operation was in progress." + +To solve this issue, we need to clear pending interrupts when resetting +host->pending_reset. This ensures that after sdhci_threaded_irq restores +interrupts, there are no pending stale interrupts. + +The behavior observed here is non-compliant with the SDHCI standard. +Place the code in the sdhci-of-dwcmshc driver to account for a +hardware-specific quirk instead of the core SDHCI code. + +Signed-off-by: Michal Wilczynski +Acked-by: Adrian Hunter +Fixes: 43658a542ebf ("mmc: sdhci-of-dwcmshc: Add support for T-Head TH1520") +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20241008100327.4108895-1-m.wilczynski@samsung.com +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mmc/host/sdhci-of-dwcmshc.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/drivers/mmc/host/sdhci-of-dwcmshc.c ++++ b/drivers/mmc/host/sdhci-of-dwcmshc.c +@@ -746,6 +746,14 @@ static void th1520_sdhci_reset(struct sd + + sdhci_reset(host, mask); + ++ /* The T-Head 1520 SoC does not comply with the SDHCI specification ++ * regarding the "Software Reset for CMD line should clear 'Command ++ * Complete' in the Normal Interrupt Status Register." Clear the bit ++ * here to compensate for this quirk. ++ */ ++ if (mask & SDHCI_RESET_CMD) ++ sdhci_writel(host, SDHCI_INT_RESPONSE, SDHCI_INT_STATUS); ++ + if (priv->flags & FLAG_IO_FIXED_1V8) { + ctrl_2 = sdhci_readw(host, SDHCI_HOST_CONTROL2); + if (!(ctrl_2 & SDHCI_CTRL_VDD_180)) { diff --git a/queue-6.11/mptcp-fallback-when-mptcp-opts-are-dropped-after-1st-data.patch b/queue-6.11/mptcp-fallback-when-mptcp-opts-are-dropped-after-1st-data.patch new file mode 100644 index 00000000000..8ed66b5e700 --- /dev/null +++ b/queue-6.11/mptcp-fallback-when-mptcp-opts-are-dropped-after-1st-data.patch @@ -0,0 +1,85 @@ +From 119d51e225febc8152476340a880f5415a01e99e Mon Sep 17 00:00:00 2001 +From: "Matthieu Baerts (NGI0)" +Date: Tue, 8 Oct 2024 13:04:54 +0200 +Subject: mptcp: fallback when MPTCP opts are dropped after 1st data + +From: Matthieu Baerts (NGI0) + +commit 119d51e225febc8152476340a880f5415a01e99e upstream. + +As reported by Christoph [1], before this patch, an MPTCP connection was +wrongly reset when a host received a first data packet with MPTCP +options after the 3wHS, but got the next ones without. + +According to the MPTCP v1 specs [2], a fallback should happen in this +case, because the host didn't receive a DATA_ACK from the other peer, +nor receive data for more than the initial window which implies a +DATA_ACK being received by the other peer. + +The patch here re-uses the same logic as the one used in other places: +by looking at allow_infinite_fallback, which is disabled at the creation +of an additional subflow. It's not looking at the first DATA_ACK (or +implying one received from the other side) as suggested by the RFC, but +it is in continuation with what was already done, which is safer, and it +fixes the reported issue. The next step, looking at this first DATA_ACK, +is tracked in [4]. + +This patch has been validated using the following Packetdrill script: + + 0 socket(..., SOCK_STREAM, IPPROTO_MPTCP) = 3 + +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 + +0 bind(3, ..., ...) = 0 + +0 listen(3, 1) = 0 + + // 3WHS is OK + +0.0 < S 0:0(0) win 65535 + +0.0 > S. 0:0(0) ack 1 + +0.1 < . 1:1(0) ack 1 win 2048 + +0 accept(3, ..., ...) = 4 + + // Data from the client with valid MPTCP options (no DATA_ACK: normal) + +0.1 < P. 1:501(500) ack 1 win 2048 + // From here, the MPTCP options will be dropped by a middlebox + +0.0 > . 1:1(0) ack 501 + + +0.1 read(4, ..., 500) = 500 + +0 write(4, ..., 100) = 100 + + // The server replies with data, still thinking MPTCP is being used + +0.0 > P. 1:101(100) ack 501 + // But the client already did a fallback to TCP, because the two previous packets have been received without MPTCP options + +0.1 < . 501:501(0) ack 101 win 2048 + + +0.0 < P. 501:601(100) ack 101 win 2048 + // The server should fallback to TCP, not reset: it didn't get a DATA_ACK, nor data for more than the initial window + +0.0 > . 101:101(0) ack 601 + +Note that this script requires Packetdrill with MPTCP support, see [3]. + +Fixes: dea2b1ea9c70 ("mptcp: do not reset MP_CAPABLE subflow on mapping errors") +Cc: stable@vger.kernel.org +Reported-by: Christoph Paasch +Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/518 [1] +Link: https://datatracker.ietf.org/doc/html/rfc8684#name-fallback [2] +Link: https://github.com/multipath-tcp/packetdrill [3] +Link: https://github.com/multipath-tcp/mptcp_net-next/issues/519 [4] +Reviewed-by: Paolo Abeni +Signed-off-by: Matthieu Baerts (NGI0) +Link: https://patch.msgid.link/20241008-net-mptcp-fallback-fixes-v1-3-c6fb8e93e551@kernel.org +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/mptcp/subflow.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/net/mptcp/subflow.c ++++ b/net/mptcp/subflow.c +@@ -1276,7 +1276,7 @@ static bool subflow_can_fallback(struct + else if (READ_ONCE(msk->csum_enabled)) + return !subflow->valid_csum_seen; + else +- return !subflow->fully_established; ++ return READ_ONCE(msk->allow_infinite_fallback); + } + + static void mptcp_subflow_fail(struct mptcp_sock *msk, struct sock *ssk) diff --git a/queue-6.11/mptcp-handle-consistently-dss-corruption.patch b/queue-6.11/mptcp-handle-consistently-dss-corruption.patch new file mode 100644 index 00000000000..06280267ce7 --- /dev/null +++ b/queue-6.11/mptcp-handle-consistently-dss-corruption.patch @@ -0,0 +1,107 @@ +From e32d262c89e2b22cb0640223f953b548617ed8a6 Mon Sep 17 00:00:00 2001 +From: Paolo Abeni +Date: Tue, 8 Oct 2024 13:04:52 +0200 +Subject: mptcp: handle consistently DSS corruption + +From: Paolo Abeni + +commit e32d262c89e2b22cb0640223f953b548617ed8a6 upstream. + +Bugged peer implementation can send corrupted DSS options, consistently +hitting a few warning in the data path. Use DEBUG_NET assertions, to +avoid the splat on some builds and handle consistently the error, dumping +related MIBs and performing fallback and/or reset according to the +subflow type. + +Fixes: 6771bfd9ee24 ("mptcp: update mptcp ack sequence from work queue") +Cc: stable@vger.kernel.org +Signed-off-by: Paolo Abeni +Reviewed-by: Matthieu Baerts (NGI0) +Signed-off-by: Matthieu Baerts (NGI0) +Link: https://patch.msgid.link/20241008-net-mptcp-fallback-fixes-v1-1-c6fb8e93e551@kernel.org +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/mptcp/mib.c | 2 ++ + net/mptcp/mib.h | 2 ++ + net/mptcp/protocol.c | 24 +++++++++++++++++++++--- + net/mptcp/subflow.c | 4 +++- + 4 files changed, 28 insertions(+), 4 deletions(-) + +--- a/net/mptcp/mib.c ++++ b/net/mptcp/mib.c +@@ -26,6 +26,8 @@ static const struct snmp_mib mptcp_snmp_ + SNMP_MIB_ITEM("MPJoinAckRx", MPTCP_MIB_JOINACKRX), + SNMP_MIB_ITEM("MPJoinAckHMacFailure", MPTCP_MIB_JOINACKMAC), + SNMP_MIB_ITEM("DSSNotMatching", MPTCP_MIB_DSSNOMATCH), ++ SNMP_MIB_ITEM("DSSCorruptionFallback", MPTCP_MIB_DSSCORRUPTIONFALLBACK), ++ SNMP_MIB_ITEM("DSSCorruptionReset", MPTCP_MIB_DSSCORRUPTIONRESET), + SNMP_MIB_ITEM("InfiniteMapTx", MPTCP_MIB_INFINITEMAPTX), + SNMP_MIB_ITEM("InfiniteMapRx", MPTCP_MIB_INFINITEMAPRX), + SNMP_MIB_ITEM("DSSNoMatchTCP", MPTCP_MIB_DSSTCPMISMATCH), +--- a/net/mptcp/mib.h ++++ b/net/mptcp/mib.h +@@ -21,6 +21,8 @@ enum linux_mptcp_mib_field { + MPTCP_MIB_JOINACKRX, /* Received an ACK + MP_JOIN */ + MPTCP_MIB_JOINACKMAC, /* HMAC was wrong on ACK + MP_JOIN */ + MPTCP_MIB_DSSNOMATCH, /* Received a new mapping that did not match the previous one */ ++ MPTCP_MIB_DSSCORRUPTIONFALLBACK,/* DSS corruption detected, fallback */ ++ MPTCP_MIB_DSSCORRUPTIONRESET, /* DSS corruption detected, MPJ subflow reset */ + MPTCP_MIB_INFINITEMAPTX, /* Sent an infinite mapping */ + MPTCP_MIB_INFINITEMAPRX, /* Received an infinite mapping */ + MPTCP_MIB_DSSTCPMISMATCH, /* DSS-mapping did not map with TCP's sequence numbers */ +--- a/net/mptcp/protocol.c ++++ b/net/mptcp/protocol.c +@@ -620,6 +620,18 @@ static bool mptcp_check_data_fin(struct + return ret; + } + ++static void mptcp_dss_corruption(struct mptcp_sock *msk, struct sock *ssk) ++{ ++ if (READ_ONCE(msk->allow_infinite_fallback)) { ++ MPTCP_INC_STATS(sock_net(ssk), ++ MPTCP_MIB_DSSCORRUPTIONFALLBACK); ++ mptcp_do_fallback(ssk); ++ } else { ++ MPTCP_INC_STATS(sock_net(ssk), MPTCP_MIB_DSSCORRUPTIONRESET); ++ mptcp_subflow_reset(ssk); ++ } ++} ++ + static bool __mptcp_move_skbs_from_subflow(struct mptcp_sock *msk, + struct sock *ssk, + unsigned int *bytes) +@@ -692,10 +704,16 @@ static bool __mptcp_move_skbs_from_subfl + moved += len; + seq += len; + +- if (WARN_ON_ONCE(map_remaining < len)) +- break; ++ if (unlikely(map_remaining < len)) { ++ DEBUG_NET_WARN_ON_ONCE(1); ++ mptcp_dss_corruption(msk, ssk); ++ } + } else { +- WARN_ON_ONCE(!fin); ++ if (unlikely(!fin)) { ++ DEBUG_NET_WARN_ON_ONCE(1); ++ mptcp_dss_corruption(msk, ssk); ++ } ++ + sk_eat_skb(ssk, skb); + done = true; + } +--- a/net/mptcp/subflow.c ++++ b/net/mptcp/subflow.c +@@ -971,8 +971,10 @@ static bool skb_is_fully_mapped(struct s + unsigned int skb_consumed; + + skb_consumed = tcp_sk(ssk)->copied_seq - TCP_SKB_CB(skb)->seq; +- if (WARN_ON_ONCE(skb_consumed >= skb->len)) ++ if (unlikely(skb_consumed >= skb->len)) { ++ DEBUG_NET_WARN_ON_ONCE(1); + return true; ++ } + + return skb->len - skb_consumed <= subflow->map_data_len - + mptcp_subflow_get_map_offset(subflow); diff --git a/queue-6.11/mptcp-pm-do-not-remove-closing-subflows.patch b/queue-6.11/mptcp-pm-do-not-remove-closing-subflows.patch new file mode 100644 index 00000000000..a098c95dceb --- /dev/null +++ b/queue-6.11/mptcp-pm-do-not-remove-closing-subflows.patch @@ -0,0 +1,41 @@ +From db0a37b7ac27d8ca27d3dc676a16d081c16ec7b9 Mon Sep 17 00:00:00 2001 +From: "Matthieu Baerts (NGI0)" +Date: Tue, 8 Oct 2024 13:04:55 +0200 +Subject: mptcp: pm: do not remove closing subflows + +From: Matthieu Baerts (NGI0) + +commit db0a37b7ac27d8ca27d3dc676a16d081c16ec7b9 upstream. + +In a previous fix, the in-kernel path-manager has been modified not to +retrigger the removal of a subflow if it was already closed, e.g. when +the initial subflow is removed, but kept in the subflows list. + +To be complete, this fix should also skip the subflows that are in any +closing state: mptcp_close_ssk() will initiate the closure, but the +switch to the TCP_CLOSE state depends on the other peer. + +Fixes: 58e1b66b4e4b ("mptcp: pm: do not remove already closed subflows") +Cc: stable@vger.kernel.org +Suggested-by: Paolo Abeni +Acked-by: Paolo Abeni +Signed-off-by: Matthieu Baerts (NGI0) +Link: https://patch.msgid.link/20241008-net-mptcp-fallback-fixes-v1-4-c6fb8e93e551@kernel.org +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/mptcp/pm_netlink.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/net/mptcp/pm_netlink.c ++++ b/net/mptcp/pm_netlink.c +@@ -856,7 +856,8 @@ static void mptcp_pm_nl_rm_addr_or_subfl + int how = RCV_SHUTDOWN | SEND_SHUTDOWN; + u8 id = subflow_get_local_id(subflow); + +- if (inet_sk_state_load(ssk) == TCP_CLOSE) ++ if ((1 << inet_sk_state_load(ssk)) & ++ (TCPF_FIN_WAIT1 | TCPF_FIN_WAIT2 | TCPF_CLOSING | TCPF_CLOSE)) + continue; + if (rm_type == MPTCP_MIB_RMADDR && remote_id != rm_id) + continue; diff --git a/queue-6.11/net-dsa-lan9303-ensure-chip-reset-and-wait-for-ready-status.patch b/queue-6.11/net-dsa-lan9303-ensure-chip-reset-and-wait-for-ready-status.patch new file mode 100644 index 00000000000..6e4813f2d64 --- /dev/null +++ b/queue-6.11/net-dsa-lan9303-ensure-chip-reset-and-wait-for-ready-status.patch @@ -0,0 +1,83 @@ +From 5c14e51d2d7df49fe0d4e64a12c58d2542f452ff Mon Sep 17 00:00:00 2001 +From: Anatolij Gustschin +Date: Fri, 4 Oct 2024 13:36:54 +0200 +Subject: net: dsa: lan9303: ensure chip reset and wait for READY status + +From: Anatolij Gustschin + +commit 5c14e51d2d7df49fe0d4e64a12c58d2542f452ff upstream. + +Accessing device registers seems to be not reliable, the chip +revision is sometimes detected wrongly (0 instead of expected 1). + +Ensure that the chip reset is performed via reset GPIO and then +wait for 'Device Ready' status in HW_CFG register before doing +any register initializations. + +Cc: stable@vger.kernel.org +Fixes: a1292595e006 ("net: dsa: add new DSA switch driver for the SMSC-LAN9303") +Signed-off-by: Anatolij Gustschin +[alex: reworked using read_poll_timeout()] +Signed-off-by: Alexander Sverdlin +Reviewed-by: Vladimir Oltean +Link: https://patch.msgid.link/20241004113655.3436296-1-alexander.sverdlin@siemens.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/dsa/lan9303-core.c | 29 +++++++++++++++++++++++++++++ + 1 file changed, 29 insertions(+) + +--- a/drivers/net/dsa/lan9303-core.c ++++ b/drivers/net/dsa/lan9303-core.c +@@ -6,6 +6,7 @@ + #include + #include + #include ++#include + #include + #include + #include +@@ -839,6 +840,8 @@ static void lan9303_handle_reset(struct + if (!chip->reset_gpio) + return; + ++ gpiod_set_value_cansleep(chip->reset_gpio, 1); ++ + if (chip->reset_duration != 0) + msleep(chip->reset_duration); + +@@ -864,8 +867,34 @@ static int lan9303_disable_processing(st + static int lan9303_check_device(struct lan9303 *chip) + { + int ret; ++ int err; + u32 reg; + ++ /* In I2C-managed configurations this polling loop will clash with ++ * switch's reading of EEPROM right after reset and this behaviour is ++ * not configurable. While lan9303_read() already has quite long retry ++ * timeout, seems not all cases are being detected as arbitration error. ++ * ++ * According to datasheet, EEPROM loader has 30ms timeout (in case of ++ * missing EEPROM). ++ * ++ * Loading of the largest supported EEPROM is expected to take at least ++ * 5.9s. ++ */ ++ err = read_poll_timeout(lan9303_read, ret, ++ !ret && reg & LAN9303_HW_CFG_READY, ++ 20000, 6000000, false, ++ chip->regmap, LAN9303_HW_CFG, ®); ++ if (ret) { ++ dev_err(chip->dev, "failed to read HW_CFG reg: %pe\n", ++ ERR_PTR(ret)); ++ return ret; ++ } ++ if (err) { ++ dev_err(chip->dev, "HW_CFG not ready: 0x%08x\n", reg); ++ return err; ++ } ++ + ret = lan9303_read(chip->regmap, LAN9303_CHIP_REV, ®); + if (ret) { + dev_err(chip->dev, "failed to read chip revision register: %d\n", diff --git a/queue-6.11/net-explicitly-clear-the-sk-pointer-when-pf-create-fails.patch b/queue-6.11/net-explicitly-clear-the-sk-pointer-when-pf-create-fails.patch new file mode 100644 index 00000000000..45cadc2eacb --- /dev/null +++ b/queue-6.11/net-explicitly-clear-the-sk-pointer-when-pf-create-fails.patch @@ -0,0 +1,56 @@ +From 631083143315d1b192bd7d915b967b37819e88ea Mon Sep 17 00:00:00 2001 +From: Ignat Korchagin +Date: Thu, 3 Oct 2024 18:01:51 +0100 +Subject: net: explicitly clear the sk pointer, when pf->create fails + +From: Ignat Korchagin + +commit 631083143315d1b192bd7d915b967b37819e88ea upstream. + +We have recently noticed the exact same KASAN splat as in commit +6cd4a78d962b ("net: do not leave a dangling sk pointer, when socket +creation fails"). The problem is that commit did not fully address the +problem, as some pf->create implementations do not use sk_common_release +in their error paths. + +For example, we can use the same reproducer as in the above commit, but +changing ping to arping. arping uses AF_PACKET socket and if packet_create +fails, it will just sk_free the allocated sk object. + +While we could chase all the pf->create implementations and make sure they +NULL the freed sk object on error from the socket, we can't guarantee +future protocols will not make the same mistake. + +So it is easier to just explicitly NULL the sk pointer upon return from +pf->create in __sock_create. We do know that pf->create always releases the +allocated sk object on error, so if the pointer is not NULL, it is +definitely dangling. + +Fixes: 6cd4a78d962b ("net: do not leave a dangling sk pointer, when socket creation fails") +Signed-off-by: Ignat Korchagin +Cc: stable@vger.kernel.org +Reviewed-by: Eric Dumazet +Link: https://patch.msgid.link/20241003170151.69445-1-ignat@cloudflare.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/socket.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +--- a/net/socket.c ++++ b/net/socket.c +@@ -1569,8 +1569,13 @@ int __sock_create(struct net *net, int f + rcu_read_unlock(); + + err = pf->create(net, sock, protocol, kern); +- if (err < 0) ++ if (err < 0) { ++ /* ->create should release the allocated sock->sk object on error ++ * but it may leave the dangling pointer ++ */ ++ sock->sk = NULL; + goto out_module_put; ++ } + + /* + * Now to bump the refcnt of the [loadable] module that owns this diff --git a/queue-6.11/net-fix-an-unsafe-loop-on-the-list.patch b/queue-6.11/net-fix-an-unsafe-loop-on-the-list.patch new file mode 100644 index 00000000000..dfac6a6117c --- /dev/null +++ b/queue-6.11/net-fix-an-unsafe-loop-on-the-list.patch @@ -0,0 +1,60 @@ +From 1dae9f1187189bc09ff6d25ca97ead711f7e26f9 Mon Sep 17 00:00:00 2001 +From: Anastasia Kovaleva +Date: Thu, 3 Oct 2024 13:44:31 +0300 +Subject: net: Fix an unsafe loop on the list + +From: Anastasia Kovaleva + +commit 1dae9f1187189bc09ff6d25ca97ead711f7e26f9 upstream. + +The kernel may crash when deleting a genetlink family if there are still +listeners for that family: + +Oops: Kernel access of bad area, sig: 11 [#1] + ... + NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0 + LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0 + Call Trace: +__netlink_clear_multicast_users+0x74/0xc0 +genl_unregister_family+0xd4/0x2d0 + +Change the unsafe loop on the list to a safe one, because inside the +loop there is an element removal from this list. + +Fixes: b8273570f802 ("genetlink: fix netns vs. netlink table locking (2)") +Cc: stable@vger.kernel.org +Signed-off-by: Anastasia Kovaleva +Reviewed-by: Dmitry Bogdanov +Reviewed-by: Kuniyuki Iwashima +Link: https://patch.msgid.link/20241003104431.12391-1-a.kovaleva@yadro.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + include/net/sock.h | 2 ++ + net/netlink/af_netlink.c | 3 ++- + 2 files changed, 4 insertions(+), 1 deletion(-) + +--- a/include/net/sock.h ++++ b/include/net/sock.h +@@ -892,6 +892,8 @@ static inline void sk_add_bind_node(stru + hlist_for_each_entry_safe(__sk, tmp, list, sk_node) + #define sk_for_each_bound(__sk, list) \ + hlist_for_each_entry(__sk, list, sk_bind_node) ++#define sk_for_each_bound_safe(__sk, tmp, list) \ ++ hlist_for_each_entry_safe(__sk, tmp, list, sk_bind_node) + + /** + * sk_for_each_entry_offset_rcu - iterate over a list at a given struct offset +--- a/net/netlink/af_netlink.c ++++ b/net/netlink/af_netlink.c +@@ -2136,8 +2136,9 @@ void __netlink_clear_multicast_users(str + { + struct sock *sk; + struct netlink_table *tbl = &nl_table[ksk->sk_protocol]; ++ struct hlist_node *tmp; + +- sk_for_each_bound(sk, &tbl->mc_list) ++ sk_for_each_bound_safe(sk, tmp, &tbl->mc_list) + netlink_update_socket_mc(nlk_sk(sk), group, 0); + } + diff --git a/queue-6.11/net-phy-realtek-fix-mmd-access-on-rtl8126a-integrated-phy.patch b/queue-6.11/net-phy-realtek-fix-mmd-access-on-rtl8126a-integrated-phy.patch new file mode 100644 index 00000000000..56687f40790 --- /dev/null +++ b/queue-6.11/net-phy-realtek-fix-mmd-access-on-rtl8126a-integrated-phy.patch @@ -0,0 +1,77 @@ +From a6ad589c1d118f9d5b1bc4c6888d42919f830340 Mon Sep 17 00:00:00 2001 +From: Heiner Kallweit +Date: Mon, 7 Oct 2024 11:57:41 +0200 +Subject: net: phy: realtek: Fix MMD access on RTL8126A-integrated PHY + +From: Heiner Kallweit + +commit a6ad589c1d118f9d5b1bc4c6888d42919f830340 upstream. + +All MMD reads return 0 for the RTL8126A-integrated PHY. Therefore phylib +assumes it doesn't support EEE, what results in higher power consumption, +and a significantly higher chip temperature in my case. +To fix this split out the PHY driver for the RTL8126A-integrated PHY +and set the read_mmd/write_mmd callbacks to read from vendor-specific +registers. + +Fixes: 5befa3728b85 ("net: phy: realtek: add support for RTL8126A-integrated 5Gbps PHY") +Cc: stable@vger.kernel.org +Signed-off-by: Heiner Kallweit +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/phy/realtek.c | 24 +++++++++++++++++++++++- + 1 file changed, 23 insertions(+), 1 deletion(-) + +diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c +index c15d2f66ef0d..166f6a728373 100644 +--- a/drivers/net/phy/realtek.c ++++ b/drivers/net/phy/realtek.c +@@ -1081,6 +1081,16 @@ static int rtl8221b_vn_cg_c45_match_phy_device(struct phy_device *phydev) + return rtlgen_is_c45_match(phydev, RTL_8221B_VN_CG, true); + } + ++static int rtl8251b_c22_match_phy_device(struct phy_device *phydev) ++{ ++ return rtlgen_is_c45_match(phydev, RTL_8251B, false); ++} ++ ++static int rtl8251b_c45_match_phy_device(struct phy_device *phydev) ++{ ++ return rtlgen_is_c45_match(phydev, RTL_8251B, true); ++} ++ + static int rtlgen_resume(struct phy_device *phydev) + { + int ret = genphy_resume(phydev); +@@ -1418,7 +1428,7 @@ static struct phy_driver realtek_drvs[] = { + .suspend = genphy_c45_pma_suspend, + .resume = rtlgen_c45_resume, + }, { +- PHY_ID_MATCH_EXACT(0x001cc862), ++ .match_phy_device = rtl8251b_c45_match_phy_device, + .name = "RTL8251B 5Gbps PHY", + .get_features = rtl822x_get_features, + .config_aneg = rtl822x_config_aneg, +@@ -1427,6 +1437,18 @@ static struct phy_driver realtek_drvs[] = { + .resume = rtlgen_resume, + .read_page = rtl821x_read_page, + .write_page = rtl821x_write_page, ++ }, { ++ .match_phy_device = rtl8251b_c22_match_phy_device, ++ .name = "RTL8126A-internal 5Gbps PHY", ++ .get_features = rtl822x_get_features, ++ .config_aneg = rtl822x_config_aneg, ++ .read_status = rtl822x_read_status, ++ .suspend = genphy_suspend, ++ .resume = rtlgen_resume, ++ .read_page = rtl821x_read_page, ++ .write_page = rtl821x_write_page, ++ .read_mmd = rtl822x_read_mmd, ++ .write_mmd = rtl822x_write_mmd, + }, { + PHY_ID_MATCH_EXACT(0x001ccad0), + .name = "RTL8224 2.5Gbps PHY", +-- +2.47.0 + diff --git a/queue-6.11/net-phy-remove-led-entry-from-leds-list-on-unregister.patch b/queue-6.11/net-phy-remove-led-entry-from-leds-list-on-unregister.patch new file mode 100644 index 00000000000..33c66079b94 --- /dev/null +++ b/queue-6.11/net-phy-remove-led-entry-from-leds-list-on-unregister.patch @@ -0,0 +1,58 @@ +From f50b5d74c68e551667e265123659b187a30fe3a5 Mon Sep 17 00:00:00 2001 +From: Christian Marangi +Date: Fri, 4 Oct 2024 20:27:58 +0200 +Subject: net: phy: Remove LED entry from LEDs list on unregister + +From: Christian Marangi + +commit f50b5d74c68e551667e265123659b187a30fe3a5 upstream. + +Commit c938ab4da0eb ("net: phy: Manual remove LEDs to ensure correct +ordering") correctly fixed a problem with using devm_ but missed +removing the LED entry from the LEDs list. + +This cause kernel panic on specific scenario where the port for the PHY +is torn down and up and the kmod for the PHY is removed. + +On setting the port down the first time, the assosiacted LEDs are +correctly unregistered. The associated kmod for the PHY is now removed. +The kmod is now added again and the port is now put up, the associated LED +are registered again. +On putting the port down again for the second time after these step, the +LED list now have 4 elements. With the first 2 already unregistered +previously and the 2 new one registered again. + +This cause a kernel panic as the first 2 element should have been +removed. + +Fix this by correctly removing the element when LED is unregistered. + +Reported-by: Daniel Golle +Tested-by: Daniel Golle +Cc: stable@vger.kernel.org +Fixes: c938ab4da0eb ("net: phy: Manual remove LEDs to ensure correct ordering") +Signed-off-by: Christian Marangi +Reviewed-by: Andrew Lunn +Link: https://patch.msgid.link/20241004182759.14032-1-ansuelsmth@gmail.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/phy/phy_device.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/drivers/net/phy/phy_device.c ++++ b/drivers/net/phy/phy_device.c +@@ -3249,10 +3249,11 @@ static __maybe_unused int phy_led_hw_is_ + + static void phy_leds_unregister(struct phy_device *phydev) + { +- struct phy_led *phyled; ++ struct phy_led *phyled, *tmp; + +- list_for_each_entry(phyled, &phydev->leds, list) { ++ list_for_each_entry_safe(phyled, tmp, &phydev->leds, list) { + led_classdev_unregister(&phyled->led_cdev); ++ list_del(&phyled->list); + } + } + diff --git a/queue-6.11/nouveau-dmem-fix-vulnerability-in-migrate_to_ram-upon-copy-error.patch b/queue-6.11/nouveau-dmem-fix-vulnerability-in-migrate_to_ram-upon-copy-error.patch new file mode 100644 index 00000000000..2bf20f1e928 --- /dev/null +++ b/queue-6.11/nouveau-dmem-fix-vulnerability-in-migrate_to_ram-upon-copy-error.patch @@ -0,0 +1,48 @@ +From 835745a377a4519decd1a36d6b926e369b3033e2 Mon Sep 17 00:00:00 2001 +From: Yonatan Maman +Date: Tue, 8 Oct 2024 14:59:43 +0300 +Subject: nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy error + +From: Yonatan Maman + +commit 835745a377a4519decd1a36d6b926e369b3033e2 upstream. + +The `nouveau_dmem_copy_one` function ensures that the copy push command is +sent to the device firmware but does not track whether it was executed +successfully. + +In the case of a copy error (e.g., firmware or hardware failure), the +copy push command will be sent via the firmware channel, and +`nouveau_dmem_copy_one` will likely report success, leading to the +`migrate_to_ram` function returning a dirty HIGH_USER page to the user. + +This can result in a security vulnerability, as a HIGH_USER page that may +contain sensitive or corrupted data could be returned to the user. + +To prevent this vulnerability, we allocate a zero page. Thus, in case of +an error, a non-dirty (zero) page will be returned to the user. + +Fixes: 5be73b690875 ("drm/nouveau/dmem: device memory helpers for SVM") +Signed-off-by: Yonatan Maman +Co-developed-by: Gal Shalom +Signed-off-by: Gal Shalom +Reviewed-by: Ben Skeggs +Cc: stable@vger.kernel.org +Signed-off-by: Danilo Krummrich +Link: https://patchwork.freedesktop.org/patch/msgid/20241008115943.990286-3-ymaman@nvidia.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/nouveau/nouveau_dmem.c ++++ b/drivers/gpu/drm/nouveau/nouveau_dmem.c +@@ -193,7 +193,7 @@ static vm_fault_t nouveau_dmem_migrate_t + if (!spage || !(src & MIGRATE_PFN_MIGRATE)) + goto done; + +- dpage = alloc_page_vma(GFP_HIGHUSER, vmf->vma, vmf->address); ++ dpage = alloc_page_vma(GFP_HIGHUSER | __GFP_ZERO, vmf->vma, vmf->address); + if (!dpage) + goto done; + diff --git a/queue-6.11/opp-fix-error-code-in-dev_pm_opp_set_config.patch b/queue-6.11/opp-fix-error-code-in-dev_pm_opp_set_config.patch new file mode 100644 index 00000000000..8e7eec903e4 --- /dev/null +++ b/queue-6.11/opp-fix-error-code-in-dev_pm_opp_set_config.patch @@ -0,0 +1,45 @@ +From eb8333673e1ebc2418980b664a84c91b4e98afc4 Mon Sep 17 00:00:00 2001 +From: Dan Carpenter +Date: Mon, 16 Sep 2024 17:07:26 +0300 +Subject: OPP: fix error code in dev_pm_opp_set_config() + +From: Dan Carpenter + +commit eb8333673e1ebc2418980b664a84c91b4e98afc4 upstream. + +This is an error path so set the error code. Smatch complains about the +current code: + + drivers/opp/core.c:2660 dev_pm_opp_set_config() + error: uninitialized symbol 'ret'. + +Fixes: e37440e7e2c2 ("OPP: Call dev_pm_opp_set_opp() for required OPPs") +Signed-off-by: Dan Carpenter +Acked-by: Viresh Kumar +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/3f3660af-4ea0-4a89-b3b7-58de7b16d7a5@stanley.mountain +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/opp/core.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +diff --git a/drivers/opp/core.c b/drivers/opp/core.c +index 494f8860220d..3aa18737470f 100644 +--- a/drivers/opp/core.c ++++ b/drivers/opp/core.c +@@ -2630,8 +2630,10 @@ int dev_pm_opp_set_config(struct device *dev, struct dev_pm_opp_config *config) + + /* Attach genpds */ + if (config->genpd_names) { +- if (config->required_devs) ++ if (config->required_devs) { ++ ret = -EINVAL; + goto err; ++ } + + ret = _opp_attach_genpd(opp_table, dev, config->genpd_names, + config->virt_devs); +-- +2.47.0 + diff --git a/queue-6.11/pm-domains-fix-alloc-free-in-dev_pm_domain_attach-detach_list.patch b/queue-6.11/pm-domains-fix-alloc-free-in-dev_pm_domain_attach-detach_list.patch new file mode 100644 index 00000000000..df79e11510b --- /dev/null +++ b/queue-6.11/pm-domains-fix-alloc-free-in-dev_pm_domain_attach-detach_list.patch @@ -0,0 +1,81 @@ +From 7738568885f2eaecfc10a3f530a2693e5f0ae3d0 Mon Sep 17 00:00:00 2001 +From: Ulf Hansson +Date: Wed, 2 Oct 2024 14:22:23 +0200 +Subject: PM: domains: Fix alloc/free in dev_pm_domain_attach|detach_list() + +From: Ulf Hansson + +commit 7738568885f2eaecfc10a3f530a2693e5f0ae3d0 upstream. + +The dev_pm_domain_attach|detach_list() functions are not resource managed, +hence they should not use devm_* helpers to manage allocation/freeing of +data. Let's fix this by converting to the traditional alloc/free functions. + +Fixes: 161e16a5e50a ("PM: domains: Add helper functions to attach/detach multiple PM domains") +Cc: stable@vger.kernel.org +Signed-off-by: Ulf Hansson +Acked-by: Viresh Kumar +Link: https://lore.kernel.org/r/20241002122232.194245-3-ulf.hansson@linaro.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/base/power/common.c | 25 +++++++++++++++---------- + 1 file changed, 15 insertions(+), 10 deletions(-) + +--- a/drivers/base/power/common.c ++++ b/drivers/base/power/common.c +@@ -195,6 +195,7 @@ int dev_pm_domain_attach_list(struct dev + struct device *pd_dev = NULL; + int ret, i, num_pds = 0; + bool by_id = true; ++ size_t size; + u32 pd_flags = data ? data->pd_flags : 0; + u32 link_flags = pd_flags & PD_FLAG_NO_DEV_LINK ? 0 : + DL_FLAG_STATELESS | DL_FLAG_PM_RUNTIME; +@@ -217,19 +218,17 @@ int dev_pm_domain_attach_list(struct dev + if (num_pds <= 0) + return 0; + +- pds = devm_kzalloc(dev, sizeof(*pds), GFP_KERNEL); ++ pds = kzalloc(sizeof(*pds), GFP_KERNEL); + if (!pds) + return -ENOMEM; + +- pds->pd_devs = devm_kcalloc(dev, num_pds, sizeof(*pds->pd_devs), +- GFP_KERNEL); +- if (!pds->pd_devs) +- return -ENOMEM; +- +- pds->pd_links = devm_kcalloc(dev, num_pds, sizeof(*pds->pd_links), +- GFP_KERNEL); +- if (!pds->pd_links) +- return -ENOMEM; ++ size = sizeof(*pds->pd_devs) + sizeof(*pds->pd_links); ++ pds->pd_devs = kcalloc(num_pds, size, GFP_KERNEL); ++ if (!pds->pd_devs) { ++ ret = -ENOMEM; ++ goto free_pds; ++ } ++ pds->pd_links = (void *)(pds->pd_devs + num_pds); + + if (link_flags && pd_flags & PD_FLAG_DEV_LINK_ON) + link_flags |= DL_FLAG_RPM_ACTIVE; +@@ -272,6 +271,9 @@ err_attach: + device_link_del(pds->pd_links[i]); + dev_pm_domain_detach(pds->pd_devs[i], true); + } ++ kfree(pds->pd_devs); ++free_pds: ++ kfree(pds); + return ret; + } + EXPORT_SYMBOL_GPL(dev_pm_domain_attach_list); +@@ -318,6 +320,9 @@ void dev_pm_domain_detach_list(struct de + device_link_del(list->pd_links[i]); + dev_pm_domain_detach(list->pd_devs[i], true); + } ++ ++ kfree(list->pd_devs); ++ kfree(list); + } + EXPORT_SYMBOL_GPL(dev_pm_domain_detach_list); + diff --git a/queue-6.11/powercap-intel_rapl_tpmi-fix-bogus-register-reading.patch b/queue-6.11/powercap-intel_rapl_tpmi-fix-bogus-register-reading.patch new file mode 100644 index 00000000000..4623b95a568 --- /dev/null +++ b/queue-6.11/powercap-intel_rapl_tpmi-fix-bogus-register-reading.patch @@ -0,0 +1,34 @@ +From 91e8f835a7eda4ba2c0c4002a3108a0e3b22d34e Mon Sep 17 00:00:00 2001 +From: Zhang Rui +Date: Mon, 30 Sep 2024 16:17:56 +0800 +Subject: powercap: intel_rapl_tpmi: Fix bogus register reading + +From: Zhang Rui + +commit 91e8f835a7eda4ba2c0c4002a3108a0e3b22d34e upstream. + +The TPMI_RAPL_REG_DOMAIN_INFO value needs to be multiplied by 8 to get +the register offset. + +Cc: All applicable +Fixes: 903eb9fb85e3 ("powercap: intel_rapl_tpmi: Fix System Domain probing") +Signed-off-by: Zhang Rui +Link: https://patch.msgid.link/20240930081801.28502-2-rui.zhang@intel.com +[ rjw: Changelog edits ] +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + drivers/powercap/intel_rapl_tpmi.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/powercap/intel_rapl_tpmi.c ++++ b/drivers/powercap/intel_rapl_tpmi.c +@@ -192,7 +192,7 @@ static int parse_one_domain(struct tpmi_ + pr_warn(FW_BUG "System domain must support Domain Info register\n"); + return -ENODEV; + } +- tpmi_domain_info = readq(trp->base + offset + TPMI_RAPL_REG_DOMAIN_INFO); ++ tpmi_domain_info = readq(trp->base + offset + TPMI_RAPL_REG_DOMAIN_INFO * 8); + if (!(tpmi_domain_info & TPMI_RAPL_DOMAIN_ROOT)) + return 0; + domain_type = RAPL_DOMAIN_PLATFORM; diff --git a/queue-6.11/revert-mmc-mvsdio-use-sg_miter-for-pio.patch b/queue-6.11/revert-mmc-mvsdio-use-sg_miter-for-pio.patch new file mode 100644 index 00000000000..42f129b15b0 --- /dev/null +++ b/queue-6.11/revert-mmc-mvsdio-use-sg_miter-for-pio.patch @@ -0,0 +1,209 @@ +From 5b35746a0fdc73063a4c7fc6208b7abd644f9ef5 Mon Sep 17 00:00:00 2001 +From: Linus Walleij +Date: Fri, 27 Sep 2024 17:54:28 +0200 +Subject: Revert "mmc: mvsdio: Use sg_miter for PIO" + +From: Linus Walleij + +commit 5b35746a0fdc73063a4c7fc6208b7abd644f9ef5 upstream. + +This reverts commit 2761822c00e8c271f10a10affdbd4917d900d7ea. + +When testing on real hardware the patch does not work. +Revert, try to acquire real hardware, and retry. +These systems typically don't have highmem anyway so the +impact is likely zero. + +Cc: stable@vger.kernel.org +Reported-by: Charlie +Signed-off-by: Linus Walleij +Link: https://lore.kernel.org/r/20240927-kirkwood-mmc-regression-v1-1-2e55bbbb7b19@linaro.org +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mmc/host/mvsdio.c | 71 ++++++++++----------------------------- + 1 file changed, 18 insertions(+), 53 deletions(-) + +diff --git a/drivers/mmc/host/mvsdio.c b/drivers/mmc/host/mvsdio.c +index af7f21888e27..ca01b7d204ba 100644 +--- a/drivers/mmc/host/mvsdio.c ++++ b/drivers/mmc/host/mvsdio.c +@@ -38,9 +38,8 @@ struct mvsd_host { + unsigned int xfer_mode; + unsigned int intr_en; + unsigned int ctrl; +- bool use_pio; +- struct sg_mapping_iter sg_miter; + unsigned int pio_size; ++ void *pio_ptr; + unsigned int sg_frags; + unsigned int ns_per_clk; + unsigned int clock; +@@ -115,18 +114,11 @@ static int mvsd_setup_data(struct mvsd_host *host, struct mmc_data *data) + * data when the buffer is not aligned on a 64 byte + * boundary. + */ +- unsigned int miter_flags = SG_MITER_ATOMIC; /* Used from IRQ */ +- +- if (data->flags & MMC_DATA_READ) +- miter_flags |= SG_MITER_TO_SG; +- else +- miter_flags |= SG_MITER_FROM_SG; +- + host->pio_size = data->blocks * data->blksz; +- sg_miter_start(&host->sg_miter, data->sg, data->sg_len, miter_flags); ++ host->pio_ptr = sg_virt(data->sg); + if (!nodma) +- dev_dbg(host->dev, "fallback to PIO for data\n"); +- host->use_pio = true; ++ dev_dbg(host->dev, "fallback to PIO for data at 0x%p size %d\n", ++ host->pio_ptr, host->pio_size); + return 1; + } else { + dma_addr_t phys_addr; +@@ -137,7 +129,6 @@ static int mvsd_setup_data(struct mvsd_host *host, struct mmc_data *data) + phys_addr = sg_dma_address(data->sg); + mvsd_write(MVSD_SYS_ADDR_LOW, (u32)phys_addr & 0xffff); + mvsd_write(MVSD_SYS_ADDR_HI, (u32)phys_addr >> 16); +- host->use_pio = false; + return 0; + } + } +@@ -297,8 +288,8 @@ static u32 mvsd_finish_data(struct mvsd_host *host, struct mmc_data *data, + { + void __iomem *iobase = host->base; + +- if (host->use_pio) { +- sg_miter_stop(&host->sg_miter); ++ if (host->pio_ptr) { ++ host->pio_ptr = NULL; + host->pio_size = 0; + } else { + dma_unmap_sg(mmc_dev(host->mmc), data->sg, host->sg_frags, +@@ -353,12 +344,9 @@ static u32 mvsd_finish_data(struct mvsd_host *host, struct mmc_data *data, + static irqreturn_t mvsd_irq(int irq, void *dev) + { + struct mvsd_host *host = dev; +- struct sg_mapping_iter *sgm = &host->sg_miter; + void __iomem *iobase = host->base; + u32 intr_status, intr_done_mask; + int irq_handled = 0; +- u16 *p; +- int s; + + intr_status = mvsd_read(MVSD_NOR_INTR_STATUS); + dev_dbg(host->dev, "intr 0x%04x intr_en 0x%04x hw_state 0x%04x\n", +@@ -382,36 +370,15 @@ static irqreturn_t mvsd_irq(int irq, void *dev) + spin_lock(&host->lock); + + /* PIO handling, if needed. Messy business... */ +- if (host->use_pio) { +- /* +- * As we set sgm->consumed this always gives a valid buffer +- * position. +- */ +- if (!sg_miter_next(sgm)) { +- /* This should not happen */ +- dev_err(host->dev, "ran out of scatter segments\n"); +- spin_unlock(&host->lock); +- host->intr_en &= +- ~(MVSD_NOR_RX_READY | MVSD_NOR_RX_FIFO_8W | +- MVSD_NOR_TX_AVAIL | MVSD_NOR_TX_FIFO_8W); +- mvsd_write(MVSD_NOR_INTR_EN, host->intr_en); +- return IRQ_HANDLED; +- } +- p = sgm->addr; +- s = sgm->length; +- if (s > host->pio_size) +- s = host->pio_size; +- } +- +- if (host->use_pio && ++ if (host->pio_size && + (intr_status & host->intr_en & + (MVSD_NOR_RX_READY | MVSD_NOR_RX_FIFO_8W))) { +- ++ u16 *p = host->pio_ptr; ++ int s = host->pio_size; + while (s >= 32 && (intr_status & MVSD_NOR_RX_FIFO_8W)) { + readsw(iobase + MVSD_FIFO, p, 16); + p += 16; + s -= 32; +- sgm->consumed += 32; + intr_status = mvsd_read(MVSD_NOR_INTR_STATUS); + } + /* +@@ -424,7 +391,6 @@ static irqreturn_t mvsd_irq(int irq, void *dev) + put_unaligned(mvsd_read(MVSD_FIFO), p++); + put_unaligned(mvsd_read(MVSD_FIFO), p++); + s -= 4; +- sgm->consumed += 4; + intr_status = mvsd_read(MVSD_NOR_INTR_STATUS); + } + if (s && s < 4 && (intr_status & MVSD_NOR_RX_READY)) { +@@ -432,13 +398,10 @@ static irqreturn_t mvsd_irq(int irq, void *dev) + val[0] = mvsd_read(MVSD_FIFO); + val[1] = mvsd_read(MVSD_FIFO); + memcpy(p, ((void *)&val) + 4 - s, s); +- sgm->consumed += s; + s = 0; + intr_status = mvsd_read(MVSD_NOR_INTR_STATUS); + } +- /* PIO transfer done */ +- host->pio_size -= sgm->consumed; +- if (host->pio_size == 0) { ++ if (s == 0) { + host->intr_en &= + ~(MVSD_NOR_RX_READY | MVSD_NOR_RX_FIFO_8W); + mvsd_write(MVSD_NOR_INTR_EN, host->intr_en); +@@ -450,10 +413,14 @@ static irqreturn_t mvsd_irq(int irq, void *dev) + } + dev_dbg(host->dev, "pio %d intr 0x%04x hw_state 0x%04x\n", + s, intr_status, mvsd_read(MVSD_HW_STATE)); ++ host->pio_ptr = p; ++ host->pio_size = s; + irq_handled = 1; +- } else if (host->use_pio && ++ } else if (host->pio_size && + (intr_status & host->intr_en & + (MVSD_NOR_TX_AVAIL | MVSD_NOR_TX_FIFO_8W))) { ++ u16 *p = host->pio_ptr; ++ int s = host->pio_size; + /* + * The TX_FIFO_8W bit is unreliable. When set, bursting + * 16 halfwords all at once in the FIFO drops data. Actually +@@ -464,7 +431,6 @@ static irqreturn_t mvsd_irq(int irq, void *dev) + mvsd_write(MVSD_FIFO, get_unaligned(p++)); + mvsd_write(MVSD_FIFO, get_unaligned(p++)); + s -= 4; +- sgm->consumed += 4; + intr_status = mvsd_read(MVSD_NOR_INTR_STATUS); + } + if (s < 4) { +@@ -473,13 +439,10 @@ static irqreturn_t mvsd_irq(int irq, void *dev) + memcpy(((void *)&val) + 4 - s, p, s); + mvsd_write(MVSD_FIFO, val[0]); + mvsd_write(MVSD_FIFO, val[1]); +- sgm->consumed += s; + s = 0; + intr_status = mvsd_read(MVSD_NOR_INTR_STATUS); + } +- /* PIO transfer done */ +- host->pio_size -= sgm->consumed; +- if (host->pio_size == 0) { ++ if (s == 0) { + host->intr_en &= + ~(MVSD_NOR_TX_AVAIL | MVSD_NOR_TX_FIFO_8W); + mvsd_write(MVSD_NOR_INTR_EN, host->intr_en); +@@ -487,6 +450,8 @@ static irqreturn_t mvsd_irq(int irq, void *dev) + } + dev_dbg(host->dev, "pio %d intr 0x%04x hw_state 0x%04x\n", + s, intr_status, mvsd_read(MVSD_HW_STATE)); ++ host->pio_ptr = p; ++ host->pio_size = s; + irq_handled = 1; + } + +-- +2.47.0 + diff --git a/queue-6.11/scsi-fnic-move-flush_work-initialization-out-of-if-block.patch b/queue-6.11/scsi-fnic-move-flush_work-initialization-out-of-if-block.patch new file mode 100644 index 00000000000..6a71f76f165 --- /dev/null +++ b/queue-6.11/scsi-fnic-move-flush_work-initialization-out-of-if-block.patch @@ -0,0 +1,66 @@ +From f30e5f77d2f205ac14d09dec40fd4bb76712f13d Mon Sep 17 00:00:00 2001 +From: Martin Wilck +Date: Mon, 30 Sep 2024 15:30:14 +0200 +Subject: scsi: fnic: Move flush_work initialization out of if block + +From: Martin Wilck + +commit f30e5f77d2f205ac14d09dec40fd4bb76712f13d upstream. + +After commit 379a58caa199 ("scsi: fnic: Move fnic_fnic_flush_tx() to a +work queue"), it can happen that a work item is sent to an uninitialized +work queue. This may has the effect that the item being queued is never +actually queued, and any further actions depending on it will not +proceed. + +The following warning is observed while the fnic driver is loaded: + +kernel: WARNING: CPU: 11 PID: 0 at ../kernel/workqueue.c:1524 __queue_work+0x373/0x410 +kernel: +kernel: queue_work_on+0x3a/0x50 +kernel: fnic_wq_copy_cmpl_handler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] +kernel: fnic_isr_msix_wq_copy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] +kernel: __handle_irq_event_percpu+0x36/0x1a0 +kernel: handle_irq_event_percpu+0x30/0x70 +kernel: handle_irq_event+0x34/0x60 +kernel: handle_edge_irq+0x7e/0x1a0 +kernel: __common_interrupt+0x3b/0xb0 +kernel: common_interrupt+0x58/0xa0 +kernel: + +It has been observed that this may break the rediscovery of Fibre +Channel devices after a temporary fabric failure. + +This patch fixes it by moving the work queue initialization out of +an if block in fnic_probe(). + +Signed-off-by: Martin Wilck +Fixes: 379a58caa199 ("scsi: fnic: Move fnic_fnic_flush_tx() to a work queue") +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20240930133014.71615-1-mwilck@suse.com +Reviewed-by: Lee Duncan +Reviewed-by: Karan Tilak Kumar +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/scsi/fnic/fnic_main.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/scsi/fnic/fnic_main.c ++++ b/drivers/scsi/fnic/fnic_main.c +@@ -830,7 +830,6 @@ static int fnic_probe(struct pci_dev *pd + spin_lock_init(&fnic->vlans_lock); + INIT_WORK(&fnic->fip_frame_work, fnic_handle_fip_frame); + INIT_WORK(&fnic->event_work, fnic_handle_event); +- INIT_WORK(&fnic->flush_work, fnic_flush_tx); + skb_queue_head_init(&fnic->fip_frame_queue); + INIT_LIST_HEAD(&fnic->evlist); + INIT_LIST_HEAD(&fnic->vlans); +@@ -948,6 +947,7 @@ static int fnic_probe(struct pci_dev *pd + + INIT_WORK(&fnic->link_work, fnic_handle_link); + INIT_WORK(&fnic->frame_work, fnic_handle_frame); ++ INIT_WORK(&fnic->flush_work, fnic_flush_tx); + skb_queue_head_init(&fnic->frame_queue); + skb_queue_head_init(&fnic->tx_queue); + diff --git a/queue-6.11/scsi-ufs-use-pre-calculated-offsets-in-ufshcd_init_lrb.patch b/queue-6.11/scsi-ufs-use-pre-calculated-offsets-in-ufshcd_init_lrb.patch new file mode 100644 index 00000000000..15c4a5852ed --- /dev/null +++ b/queue-6.11/scsi-ufs-use-pre-calculated-offsets-in-ufshcd_init_lrb.patch @@ -0,0 +1,41 @@ +From d5130c5a093257aa4542aaded8034ef116a7624a Mon Sep 17 00:00:00 2001 +From: Avri Altman +Date: Tue, 10 Sep 2024 07:45:43 +0300 +Subject: scsi: ufs: Use pre-calculated offsets in ufshcd_init_lrb() + +From: Avri Altman + +commit d5130c5a093257aa4542aaded8034ef116a7624a upstream. + +Replace manual offset calculations for response_upiu and prd_table in +ufshcd_init_lrb() with pre-calculated offsets already stored in the +utp_transfer_req_desc structure. The pre-calculated offsets are set +differently in ufshcd_host_memory_configure() based on the +UFSHCD_QUIRK_PRDT_BYTE_GRAN quirk, ensuring correct alignment and +access. + +Fixes: 26f968d7de82 ("scsi: ufs: Introduce UFSHCD_QUIRK_PRDT_BYTE_GRAN quirk") +Cc: stable@vger.kernel.org +Signed-off-by: Avri Altman +Link: https://lore.kernel.org/r/20240910044543.3812642-1-avri.altman@wdc.com +Acked-by: Bart Van Assche +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/ufs/core/ufshcd.c | 5 ++--- + 1 file changed, 2 insertions(+), 3 deletions(-) + +--- a/drivers/ufs/core/ufshcd.c ++++ b/drivers/ufs/core/ufshcd.c +@@ -2920,9 +2920,8 @@ static void ufshcd_init_lrb(struct ufs_h + struct utp_transfer_req_desc *utrdlp = hba->utrdl_base_addr; + dma_addr_t cmd_desc_element_addr = hba->ucdl_dma_addr + + i * ufshcd_get_ucd_size(hba); +- u16 response_offset = offsetof(struct utp_transfer_cmd_desc, +- response_upiu); +- u16 prdt_offset = offsetof(struct utp_transfer_cmd_desc, prd_table); ++ u16 response_offset = le16_to_cpu(utrdlp[i].response_upiu_offset); ++ u16 prdt_offset = le16_to_cpu(utrdlp[i].prd_table_offset); + + lrb->utr_descriptor_ptr = utrdlp + i; + lrb->utrd_dma_addr = hba->utrdl_dma_addr + diff --git a/queue-6.11/scsi-wd33c93-don-t-use-stale-scsi_pointer-value.patch b/queue-6.11/scsi-wd33c93-don-t-use-stale-scsi_pointer-value.patch new file mode 100644 index 00000000000..389dfed39f3 --- /dev/null +++ b/queue-6.11/scsi-wd33c93-don-t-use-stale-scsi_pointer-value.patch @@ -0,0 +1,43 @@ +From 9023ed8d91eb1fcc93e64dc4962f7412b1c4cbec Mon Sep 17 00:00:00 2001 +From: Daniel Palmer +Date: Thu, 3 Oct 2024 13:29:47 +1000 +Subject: scsi: wd33c93: Don't use stale scsi_pointer value + +From: Daniel Palmer + +commit 9023ed8d91eb1fcc93e64dc4962f7412b1c4cbec upstream. + +A regression was introduced with commit dbb2da557a6a ("scsi: wd33c93: +Move the SCSI pointer to private command data") which results in an oops +in wd33c93_intr(). That commit added the scsi_pointer variable and +initialized it from hostdata->connected. However, during selection, +hostdata->connected is not yet valid. Fix this by getting the current +scsi_pointer from hostdata->selecting. + +Cc: Daniel Palmer +Cc: Michael Schmitz +Cc: stable@kernel.org +Fixes: dbb2da557a6a ("scsi: wd33c93: Move the SCSI pointer to private command data") +Signed-off-by: Daniel Palmer +Co-developed-by: Finn Thain +Signed-off-by: Finn Thain +Link: https://lore.kernel.org/r/09e11a0a54e6aa2a88bd214526d305aaf018f523.1727926187.git.fthain@linux-m68k.org +Reviewed-by: Michael Schmitz +Reviewed-by: Bart Van Assche +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/scsi/wd33c93.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/scsi/wd33c93.c ++++ b/drivers/scsi/wd33c93.c +@@ -831,7 +831,7 @@ wd33c93_intr(struct Scsi_Host *instance) + /* construct an IDENTIFY message with correct disconnect bit */ + + hostdata->outgoing_msg[0] = IDENTIFY(0, cmd->device->lun); +- if (scsi_pointer->phase) ++ if (WD33C93_scsi_pointer(cmd)->phase) + hostdata->outgoing_msg[0] |= 0x40; + + if (hostdata->sync_stat[cmd->device->id] == SS_FIRST) { diff --git a/queue-6.11/secretmem-disable-memfd_secret-if-arch-cannot-set-direct-map.patch b/queue-6.11/secretmem-disable-memfd_secret-if-arch-cannot-set-direct-map.patch new file mode 100644 index 00000000000..bfb0c8a35a1 --- /dev/null +++ b/queue-6.11/secretmem-disable-memfd_secret-if-arch-cannot-set-direct-map.patch @@ -0,0 +1,75 @@ +From 532b53cebe58f34ce1c0f34d866f5c0e335c53c6 Mon Sep 17 00:00:00 2001 +From: Patrick Roy +Date: Tue, 1 Oct 2024 09:00:41 +0100 +Subject: secretmem: disable memfd_secret() if arch cannot set direct map + +From: Patrick Roy + +commit 532b53cebe58f34ce1c0f34d866f5c0e335c53c6 upstream. + +Return -ENOSYS from memfd_secret() syscall if !can_set_direct_map(). This +is the case for example on some arm64 configurations, where marking 4k +PTEs in the direct map not present can only be done if the direct map is +set up at 4k granularity in the first place (as ARM's break-before-make +semantics do not easily allow breaking apart large/gigantic pages). + +More precisely, on arm64 systems with !can_set_direct_map(), +set_direct_map_invalid_noflush() is a no-op, however it returns success +(0) instead of an error. This means that memfd_secret will seemingly +"work" (e.g. syscall succeeds, you can mmap the fd and fault in pages), +but it does not actually achieve its goal of removing its memory from the +direct map. + +Note that with this patch, memfd_secret() will start erroring on systems +where can_set_direct_map() returns false (arm64 with +CONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n and +CONFIG_KFENCE=n), but that still seems better than the current silent +failure. Since CONFIG_RODATA_FULL_DEFAULT_ENABLED defaults to 'y', most +arm64 systems actually have a working memfd_secret() and aren't be +affected. + +From going through the iterations of the original memfd_secret patch +series, it seems that disabling the syscall in these scenarios was the +intended behavior [1] (preferred over having +set_direct_map_invalid_noflush return an error as that would result in +SIGBUSes at page-fault time), however the check for it got dropped between +v16 [2] and v17 [3], when secretmem moved away from CMA allocations. + +[1]: https://lore.kernel.org/lkml/20201124164930.GK8537@kernel.org/ +[2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t +[3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/ + +Link: https://lkml.kernel.org/r/20241001080056.784735-1-roypat@amazon.co.uk +Fixes: 1507f51255c9 ("mm: introduce memfd_secret system call to create "secret" memory areas") +Signed-off-by: Patrick Roy +Reviewed-by: Mike Rapoport (Microsoft) +Cc: Alexander Graf +Cc: David Hildenbrand +Cc: James Gowans +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + mm/secretmem.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/mm/secretmem.c ++++ b/mm/secretmem.c +@@ -238,7 +238,7 @@ SYSCALL_DEFINE1(memfd_secret, unsigned i + /* make sure local flags do not confict with global fcntl.h */ + BUILD_BUG_ON(SECRETMEM_FLAGS_MASK & O_CLOEXEC); + +- if (!secretmem_enable) ++ if (!secretmem_enable || !can_set_direct_map()) + return -ENOSYS; + + if (flags & ~(SECRETMEM_FLAGS_MASK | O_CLOEXEC)) +@@ -280,7 +280,7 @@ static struct file_system_type secretmem + + static int __init secretmem_init(void) + { +- if (!secretmem_enable) ++ if (!secretmem_enable || !can_set_direct_map()) + return 0; + + secretmem_mnt = kern_mount(&secretmem_fs); diff --git a/queue-6.11/selftests-mm-fix-incorrect-buffer-mirror-size-in-hmm2-double_map-test.patch b/queue-6.11/selftests-mm-fix-incorrect-buffer-mirror-size-in-hmm2-double_map-test.patch new file mode 100644 index 00000000000..de16027f319 --- /dev/null +++ b/queue-6.11/selftests-mm-fix-incorrect-buffer-mirror-size-in-hmm2-double_map-test.patch @@ -0,0 +1,64 @@ +From 76503e1fa1a53ef041a120825d5ce81c7fe7bdd7 Mon Sep 17 00:00:00 2001 +From: Donet Tom +Date: Fri, 27 Sep 2024 00:07:52 -0500 +Subject: selftests/mm: fix incorrect buffer->mirror size in hmm2 double_map test +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Donet Tom + +commit 76503e1fa1a53ef041a120825d5ce81c7fe7bdd7 upstream. + +The hmm2 double_map test was failing due to an incorrect buffer->mirror +size. The buffer->mirror size was 6, while buffer->ptr size was 6 * +PAGE_SIZE. The test failed because the kernel's copy_to_user function was +attempting to copy a 6 * PAGE_SIZE buffer to buffer->mirror. Since the +size of buffer->mirror was incorrect, copy_to_user failed. + +This patch corrects the buffer->mirror size to 6 * PAGE_SIZE. + +Test Result without this patch +============================== + # RUN hmm2.hmm2_device_private.double_map ... + # hmm-tests.c:1680:double_map:Expected ret (-14) == 0 (0) + # double_map: Test terminated by assertion + # FAIL hmm2.hmm2_device_private.double_map + not ok 53 hmm2.hmm2_device_private.double_map + +Test Result with this patch +=========================== + # RUN hmm2.hmm2_device_private.double_map ... + # OK hmm2.hmm2_device_private.double_map + ok 53 hmm2.hmm2_device_private.double_map + +Link: https://lkml.kernel.org/r/20240927050752.51066-1-donettom@linux.ibm.com +Fixes: fee9f6d1b8df ("mm/hmm/test: add selftests for HMM") +Signed-off-by: Donet Tom +Reviewed-by: Muhammad Usama Anjum +Cc: Jérôme Glisse +Cc: Kees Cook +Cc: Mark Brown +Cc: Przemek Kitszel +Cc: Ritesh Harjani (IBM) +Cc: Shuah Khan +Cc: Ralph Campbell +Cc: Jason Gunthorpe +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + tools/testing/selftests/mm/hmm-tests.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/tools/testing/selftests/mm/hmm-tests.c ++++ b/tools/testing/selftests/mm/hmm-tests.c +@@ -1657,7 +1657,7 @@ TEST_F(hmm2, double_map) + + buffer->fd = -1; + buffer->size = size; +- buffer->mirror = malloc(npages); ++ buffer->mirror = malloc(size); + ASSERT_NE(buffer->mirror, NULL); + + /* Reserve a range of addresses. */ diff --git a/queue-6.11/selftests-rseq-fix-mm_cid-test-failure.patch b/queue-6.11/selftests-rseq-fix-mm_cid-test-failure.patch new file mode 100644 index 00000000000..5389231b4db --- /dev/null +++ b/queue-6.11/selftests-rseq-fix-mm_cid-test-failure.patch @@ -0,0 +1,243 @@ +From a0cc649353bb726d4aa0db60dce467432197b746 Mon Sep 17 00:00:00 2001 +From: Mathieu Desnoyers +Date: Tue, 8 Oct 2024 21:28:01 -0400 +Subject: selftests/rseq: Fix mm_cid test failure + +From: Mathieu Desnoyers + +commit a0cc649353bb726d4aa0db60dce467432197b746 upstream. + +Adapt the rseq.c/rseq.h code to follow GNU C library changes introduced by: + +glibc commit 2e456ccf0c34 ("Linux: Make __rseq_size useful for feature detection (bug 31965)") + +Without this fix, rseq selftests for mm_cid fail: + +./run_param_test.sh +Default parameters +Running test spinlock +Running compare-twice test spinlock +Running mm_cid test spinlock +Error: cpu id getter unavailable + +Fixes: 18c2355838e7 ("selftests/rseq: Implement rseq mm_cid field support") +Signed-off-by: Mathieu Desnoyers +Cc: Peter Zijlstra +CC: Boqun Feng +CC: "Paul E. McKenney" +Cc: Shuah Khan +CC: Carlos O'Donell +CC: Florian Weimer +CC: linux-kselftest@vger.kernel.org +CC: stable@vger.kernel.org +Signed-off-by: Shuah Khan +Signed-off-by: Greg Kroah-Hartman +--- + tools/testing/selftests/rseq/rseq.c | 110 ++++++++++++++++++++++++------------ + tools/testing/selftests/rseq/rseq.h | 10 --- + 2 files changed, 77 insertions(+), 43 deletions(-) + +--- a/tools/testing/selftests/rseq/rseq.c ++++ b/tools/testing/selftests/rseq/rseq.c +@@ -60,12 +60,6 @@ unsigned int rseq_size = -1U; + /* Flags used during rseq registration. */ + unsigned int rseq_flags; + +-/* +- * rseq feature size supported by the kernel. 0 if the registration was +- * unsuccessful. +- */ +-unsigned int rseq_feature_size = -1U; +- + static int rseq_ownership; + static int rseq_reg_success; /* At least one rseq registration has succeded. */ + +@@ -111,6 +105,43 @@ int rseq_available(void) + } + } + ++/* The rseq areas need to be at least 32 bytes. */ ++static ++unsigned int get_rseq_min_alloc_size(void) ++{ ++ unsigned int alloc_size = rseq_size; ++ ++ if (alloc_size < ORIG_RSEQ_ALLOC_SIZE) ++ alloc_size = ORIG_RSEQ_ALLOC_SIZE; ++ return alloc_size; ++} ++ ++/* ++ * Return the feature size supported by the kernel. ++ * ++ * Depending on the value returned by getauxval(AT_RSEQ_FEATURE_SIZE): ++ * ++ * 0: Return ORIG_RSEQ_FEATURE_SIZE (20) ++ * > 0: Return the value from getauxval(AT_RSEQ_FEATURE_SIZE). ++ * ++ * It should never return a value below ORIG_RSEQ_FEATURE_SIZE. ++ */ ++static ++unsigned int get_rseq_kernel_feature_size(void) ++{ ++ unsigned long auxv_rseq_feature_size, auxv_rseq_align; ++ ++ auxv_rseq_align = getauxval(AT_RSEQ_ALIGN); ++ assert(!auxv_rseq_align || auxv_rseq_align <= RSEQ_THREAD_AREA_ALLOC_SIZE); ++ ++ auxv_rseq_feature_size = getauxval(AT_RSEQ_FEATURE_SIZE); ++ assert(!auxv_rseq_feature_size || auxv_rseq_feature_size <= RSEQ_THREAD_AREA_ALLOC_SIZE); ++ if (auxv_rseq_feature_size) ++ return auxv_rseq_feature_size; ++ else ++ return ORIG_RSEQ_FEATURE_SIZE; ++} ++ + int rseq_register_current_thread(void) + { + int rc; +@@ -119,7 +150,7 @@ int rseq_register_current_thread(void) + /* Treat libc's ownership as a successful registration. */ + return 0; + } +- rc = sys_rseq(&__rseq_abi, rseq_size, 0, RSEQ_SIG); ++ rc = sys_rseq(&__rseq_abi, get_rseq_min_alloc_size(), 0, RSEQ_SIG); + if (rc) { + if (RSEQ_READ_ONCE(rseq_reg_success)) { + /* Incoherent success/failure within process. */ +@@ -140,28 +171,12 @@ int rseq_unregister_current_thread(void) + /* Treat libc's ownership as a successful unregistration. */ + return 0; + } +- rc = sys_rseq(&__rseq_abi, rseq_size, RSEQ_ABI_FLAG_UNREGISTER, RSEQ_SIG); ++ rc = sys_rseq(&__rseq_abi, get_rseq_min_alloc_size(), RSEQ_ABI_FLAG_UNREGISTER, RSEQ_SIG); + if (rc) + return -1; + return 0; + } + +-static +-unsigned int get_rseq_feature_size(void) +-{ +- unsigned long auxv_rseq_feature_size, auxv_rseq_align; +- +- auxv_rseq_align = getauxval(AT_RSEQ_ALIGN); +- assert(!auxv_rseq_align || auxv_rseq_align <= RSEQ_THREAD_AREA_ALLOC_SIZE); +- +- auxv_rseq_feature_size = getauxval(AT_RSEQ_FEATURE_SIZE); +- assert(!auxv_rseq_feature_size || auxv_rseq_feature_size <= RSEQ_THREAD_AREA_ALLOC_SIZE); +- if (auxv_rseq_feature_size) +- return auxv_rseq_feature_size; +- else +- return ORIG_RSEQ_FEATURE_SIZE; +-} +- + static __attribute__((constructor)) + void rseq_init(void) + { +@@ -178,28 +193,54 @@ void rseq_init(void) + } + if (libc_rseq_size_p && libc_rseq_offset_p && libc_rseq_flags_p && + *libc_rseq_size_p != 0) { ++ unsigned int libc_rseq_size; ++ + /* rseq registration owned by glibc */ + rseq_offset = *libc_rseq_offset_p; +- rseq_size = *libc_rseq_size_p; ++ libc_rseq_size = *libc_rseq_size_p; + rseq_flags = *libc_rseq_flags_p; +- rseq_feature_size = get_rseq_feature_size(); +- if (rseq_feature_size > rseq_size) +- rseq_feature_size = rseq_size; ++ ++ /* ++ * Previous versions of glibc expose the value ++ * 32 even though the kernel only supported 20 ++ * bytes initially. Therefore treat 32 as a ++ * special-case. glibc 2.40 exposes a 20 bytes ++ * __rseq_size without using getauxval(3) to ++ * query the supported size, while still allocating a 32 ++ * bytes area. Also treat 20 as a special-case. ++ * ++ * Special-cases are handled by using the following ++ * value as active feature set size: ++ * ++ * rseq_size = min(32, get_rseq_kernel_feature_size()) ++ */ ++ switch (libc_rseq_size) { ++ case ORIG_RSEQ_FEATURE_SIZE: ++ fallthrough; ++ case ORIG_RSEQ_ALLOC_SIZE: ++ { ++ unsigned int rseq_kernel_feature_size = get_rseq_kernel_feature_size(); ++ ++ if (rseq_kernel_feature_size < ORIG_RSEQ_ALLOC_SIZE) ++ rseq_size = rseq_kernel_feature_size; ++ else ++ rseq_size = ORIG_RSEQ_ALLOC_SIZE; ++ break; ++ } ++ default: ++ /* Otherwise just use the __rseq_size from libc as rseq_size. */ ++ rseq_size = libc_rseq_size; ++ break; ++ } + return; + } + rseq_ownership = 1; + if (!rseq_available()) { + rseq_size = 0; +- rseq_feature_size = 0; + return; + } + rseq_offset = (void *)&__rseq_abi - rseq_thread_pointer(); + rseq_flags = 0; +- rseq_feature_size = get_rseq_feature_size(); +- if (rseq_feature_size == ORIG_RSEQ_FEATURE_SIZE) +- rseq_size = ORIG_RSEQ_ALLOC_SIZE; +- else +- rseq_size = RSEQ_THREAD_AREA_ALLOC_SIZE; + } + + static __attribute__((destructor)) +@@ -209,7 +250,6 @@ void rseq_exit(void) + return; + rseq_offset = 0; + rseq_size = -1U; +- rseq_feature_size = -1U; + rseq_ownership = 0; + } + +--- a/tools/testing/selftests/rseq/rseq.h ++++ b/tools/testing/selftests/rseq/rseq.h +@@ -68,12 +68,6 @@ extern unsigned int rseq_size; + /* Flags used during rseq registration. */ + extern unsigned int rseq_flags; + +-/* +- * rseq feature size supported by the kernel. 0 if the registration was +- * unsuccessful. +- */ +-extern unsigned int rseq_feature_size; +- + enum rseq_mo { + RSEQ_MO_RELAXED = 0, + RSEQ_MO_CONSUME = 1, /* Unused */ +@@ -193,7 +187,7 @@ static inline uint32_t rseq_current_cpu( + + static inline bool rseq_node_id_available(void) + { +- return (int) rseq_feature_size >= rseq_offsetofend(struct rseq_abi, node_id); ++ return (int) rseq_size >= rseq_offsetofend(struct rseq_abi, node_id); + } + + /* +@@ -207,7 +201,7 @@ static inline uint32_t rseq_current_node + + static inline bool rseq_mm_cid_available(void) + { +- return (int) rseq_feature_size >= rseq_offsetofend(struct rseq_abi, mm_cid); ++ return (int) rseq_size >= rseq_offsetofend(struct rseq_abi, mm_cid); + } + + static inline uint32_t rseq_current_mm_cid(void) diff --git a/queue-6.11/series b/queue-6.11/series index 339e0a3ac60..e3677f3beff 100644 --- a/queue-6.11/series +++ b/queue-6.11/series @@ -167,3 +167,47 @@ usb-storage-ignore-bogus-device-raised-by-jieli-br21-usb-sound-chip.patch usb-dwc3-re-enable-runtime-pm-after-failed-resume.patch usb-gadget-core-force-synchronous-registration.patch hid-intel-ish-hid-fix-uninitialized-variable-rv-in-ish_fw_xfer_direct_dma.patch +acpi-resource-make-asus-expertbook-b2402-matches-cover-more-models.patch +acpi-resource-make-asus-expertbook-b2502-matches-cover-more-models.patch +drm-amdgpu-partially-revert-powerplay-__counted_by-changes.patch +drm-amd-display-clear-update-flags-after-update-has-been-applied.patch +drm-v3d-stop-the-active-perfmon-before-being-destroyed.patch +drm-vc4-stop-the-active-perfmon-before-being-destroyed.patch +drm-amdkfd-fix-an-eviction-fence-leak.patch +drm-amd-display-fix-hibernate-entry-for-dcn35.patch +drm-xe-guc_submit-fix-xa_store-error-checking.patch +drm-i915-hdcp-fix-connector-refcounting.patch +drm-xe-ct-prevent-uaf-in-send_recv.patch +drm-xe-ct-fix-xa_store-error-checking.patch +bluetooth-hci_conn-fix-uaf-in-hci_enhanced_setup_sync.patch +thermal-core-reference-count-the-zone-in-thermal_zone_get_by_id.patch +thermal-core-free-tzp-copy-along-with-the-thermal-zone.patch +scsi-wd33c93-don-t-use-stale-scsi_pointer-value.patch +scsi-fnic-move-flush_work-initialization-out-of-if-block.patch +scsi-ufs-use-pre-calculated-offsets-in-ufshcd_init_lrb.patch +revert-mmc-mvsdio-use-sg_miter-for-pio.patch +mmc-sdhci-of-dwcmshc-prevent-stale-command-interrupt-handling.patch +mptcp-fallback-when-mptcp-opts-are-dropped-after-1st-data.patch +ata-libata-avoid-superfluous-disk-spin-down-spin-up-during-hibernation.patch +opp-fix-error-code-in-dev_pm_opp_set_config.patch +net-explicitly-clear-the-sk-pointer-when-pf-create-fails.patch +net-fix-an-unsafe-loop-on-the-list.patch +net-dsa-lan9303-ensure-chip-reset-and-wait-for-ready-status.patch +net-phy-remove-led-entry-from-leds-list-on-unregister.patch +net-phy-realtek-fix-mmd-access-on-rtl8126a-integrated-phy.patch +mptcp-handle-consistently-dss-corruption.patch +mptcp-pm-do-not-remove-closing-subflows.patch +device-dax-correct-pgoff-align-in-dax_set_mapping.patch +ice-fix-improper-handling-of-refcount-in-ice_dpll_init_rclk_pins.patch +ice-fix-improper-handling-of-refcount-in-ice_sriov_set_msix_vec_count.patch +nouveau-dmem-fix-vulnerability-in-migrate_to_ram-upon-copy-error.patch +powercap-intel_rapl_tpmi-fix-bogus-register-reading.patch +selftests-mm-fix-incorrect-buffer-mirror-size-in-hmm2-double_map-test.patch +selftests-rseq-fix-mm_cid-test-failure.patch +btrfs-split-remaining-space-to-discard-in-chunks.patch +btrfs-add-cancellation-points-to-trim-loops.patch +pm-domains-fix-alloc-free-in-dev_pm_domain_attach-detach_list.patch +idpf-use-actual-mbx-receive-payload-length.patch +kthread-unpark-only-parked-kthread.patch +fs-proc-kcore.c-allow-translation-of-physical-memory-addresses.patch +secretmem-disable-memfd_secret-if-arch-cannot-set-direct-map.patch diff --git a/queue-6.11/thermal-core-free-tzp-copy-along-with-the-thermal-zone.patch b/queue-6.11/thermal-core-free-tzp-copy-along-with-the-thermal-zone.patch new file mode 100644 index 00000000000..107ef6283e6 --- /dev/null +++ b/queue-6.11/thermal-core-free-tzp-copy-along-with-the-thermal-zone.patch @@ -0,0 +1,42 @@ +From 827a07525c099f54d3b15110408824541ec66b3c Mon Sep 17 00:00:00 2001 +From: "Rafael J. Wysocki" +Date: Thu, 3 Oct 2024 14:27:28 +0200 +Subject: thermal: core: Free tzp copy along with the thermal zone + +From: Rafael J. Wysocki + +commit 827a07525c099f54d3b15110408824541ec66b3c upstream. + +The object pointed to by tz->tzp may still be accessed after being +freed in thermal_zone_device_unregister(), so move the freeing of it +to the point after the removal completion has been completed at which +it cannot be accessed any more. + +Fixes: 3d439b1a2ad3 ("thermal/core: Alloc-copy-free the thermal zone parameters structure") +Cc: 6.8+ # 6.8+ +Signed-off-by: Rafael J. Wysocki +Reviewed-by: Lukasz Luba +Link: https://patch.msgid.link/4623516.LvFx2qVVIh@rjwysocki.net +Signed-off-by: Greg Kroah-Hartman +--- + drivers/thermal/thermal_core.c | 4 +--- + 1 file changed, 1 insertion(+), 3 deletions(-) + +--- a/drivers/thermal/thermal_core.c ++++ b/drivers/thermal/thermal_core.c +@@ -1647,14 +1647,12 @@ void thermal_zone_device_unregister(stru + ida_destroy(&tz->ida); + + device_del(&tz->device); +- +- kfree(tz->tzp); +- + put_device(&tz->device); + + thermal_notify_tz_delete(tz); + + wait_for_completion(&tz->removal); ++ kfree(tz->tzp); + kfree(tz); + } + EXPORT_SYMBOL_GPL(thermal_zone_device_unregister); diff --git a/queue-6.11/thermal-core-reference-count-the-zone-in-thermal_zone_get_by_id.patch b/queue-6.11/thermal-core-reference-count-the-zone-in-thermal_zone_get_by_id.patch new file mode 100644 index 00000000000..d6d2d2cbf9e --- /dev/null +++ b/queue-6.11/thermal-core-reference-count-the-zone-in-thermal_zone_get_by_id.patch @@ -0,0 +1,105 @@ +From a42a5839f400e929c489bb1b58f54596c4535167 Mon Sep 17 00:00:00 2001 +From: "Rafael J. Wysocki" +Date: Thu, 3 Oct 2024 14:25:58 +0200 +Subject: thermal: core: Reference count the zone in thermal_zone_get_by_id() + +From: Rafael J. Wysocki + +commit a42a5839f400e929c489bb1b58f54596c4535167 upstream. + +There are places in the thermal netlink code where nothing prevents +the thermal zone object from going away while being accessed after it +has been returned by thermal_zone_get_by_id(). + +To address this, make thermal_zone_get_by_id() get a reference on the +thermal zone device object to be returned with the help of get_device(), +under thermal_list_lock, and adjust all of its callers to this change +with the help of the cleanup.h infrastructure. + +Fixes: 1ce50e7d408e ("thermal: core: genetlink support for events/cmd/sampling") +Cc: 6.8+ # 6.8+ +Signed-off-by: Rafael J. Wysocki +Reviewed-by: Lukasz Luba +Link: https://patch.msgid.link/6112242.lOV4Wx5bFT@rjwysocki.net +Signed-off-by: Greg Kroah-Hartman +--- + drivers/thermal/thermal_core.c | 1 + + drivers/thermal/thermal_core.h | 3 +++ + drivers/thermal/thermal_netlink.c | 9 +++------ + 3 files changed, 7 insertions(+), 6 deletions(-) + +--- a/drivers/thermal/thermal_core.c ++++ b/drivers/thermal/thermal_core.c +@@ -737,6 +737,7 @@ struct thermal_zone_device *thermal_zone + mutex_lock(&thermal_list_lock); + list_for_each_entry(tz, &thermal_tz_list, node) { + if (tz->id == id) { ++ get_device(&tz->device); + match = tz; + break; + } +--- a/drivers/thermal/thermal_core.h ++++ b/drivers/thermal/thermal_core.h +@@ -194,6 +194,9 @@ int for_each_thermal_governor(int (*cb)( + + struct thermal_zone_device *thermal_zone_get_by_id(int id); + ++DEFINE_CLASS(thermal_zone_get_by_id, struct thermal_zone_device *, ++ if (_T) put_device(&_T->device), thermal_zone_get_by_id(id), int id) ++ + static inline bool cdev_is_power_actor(struct thermal_cooling_device *cdev) + { + return cdev->ops->get_requested_power && cdev->ops->state2power && +--- a/drivers/thermal/thermal_netlink.c ++++ b/drivers/thermal/thermal_netlink.c +@@ -443,7 +443,6 @@ static int thermal_genl_cmd_tz_get_trip( + { + struct sk_buff *msg = p->msg; + const struct thermal_trip_desc *td; +- struct thermal_zone_device *tz; + struct nlattr *start_trip; + int id; + +@@ -452,7 +451,7 @@ static int thermal_genl_cmd_tz_get_trip( + + id = nla_get_u32(p->attrs[THERMAL_GENL_ATTR_TZ_ID]); + +- tz = thermal_zone_get_by_id(id); ++ CLASS(thermal_zone_get_by_id, tz)(id); + if (!tz) + return -EINVAL; + +@@ -488,7 +487,6 @@ out_cancel_nest: + static int thermal_genl_cmd_tz_get_temp(struct param *p) + { + struct sk_buff *msg = p->msg; +- struct thermal_zone_device *tz; + int temp, ret, id; + + if (!p->attrs[THERMAL_GENL_ATTR_TZ_ID]) +@@ -496,7 +494,7 @@ static int thermal_genl_cmd_tz_get_temp( + + id = nla_get_u32(p->attrs[THERMAL_GENL_ATTR_TZ_ID]); + +- tz = thermal_zone_get_by_id(id); ++ CLASS(thermal_zone_get_by_id, tz)(id); + if (!tz) + return -EINVAL; + +@@ -514,7 +512,6 @@ static int thermal_genl_cmd_tz_get_temp( + static int thermal_genl_cmd_tz_get_gov(struct param *p) + { + struct sk_buff *msg = p->msg; +- struct thermal_zone_device *tz; + int id, ret = 0; + + if (!p->attrs[THERMAL_GENL_ATTR_TZ_ID]) +@@ -522,7 +519,7 @@ static int thermal_genl_cmd_tz_get_gov(s + + id = nla_get_u32(p->attrs[THERMAL_GENL_ATTR_TZ_ID]); + +- tz = thermal_zone_get_by_id(id); ++ CLASS(thermal_zone_get_by_id, tz)(id); + if (!tz) + return -EINVAL; +