From 7bdfd8369c6a1f3887dbf92a12174fe38ee4de10 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 28 Oct 2024 01:37:20 +0100 Subject: [PATCH] 6.11-stable patches added patches: acpi-button-add-dmi-quirk-for-samsung-galaxy-book2-to-fix-initial-lid-detection-issue.patch acpi-prm-find-efi_memory_runtime-block-for-prm-handler-and-context.patch acpi-resource-add-lg-16t90sp-to-irq1_level_low_skip_override.patch alsa-hda-realtek-add-subwoofer-quirk-for-acer-predator-g9-593.patch alsa-hda-tas2781-select-crc32-instead-of-crc32_sarwate.patch btrfs-clear-force-compress-on-remount-when-compress-mount-option-is-given.patch btrfs-fix-passing-0-to-err_ptr-in-btrfs_search_dir_index_item.patch btrfs-fix-read-corruption-due-to-race-with-extent-map-merging.patch btrfs-qgroup-set-a-more-sane-default-value-for-subtree-drop-threshold.patch btrfs-reject-ro-rw-reconfiguration-if-there-are-hard-ro-requirements.patch btrfs-zoned-fix-zone-unusable-accounting-for-freed-reserved-extent.patch drm-amd-display-disable-psr-su-on-parade-08-01-tcon-too.patch drm-amd-guard-against-bad-data-for-atif-acpi-method.patch drm-bridge-fix-assignment-of-the-of_node-of-the-parent-to-aux-bridge.patch firewire-core-fix-invalid-port-index-for-parent-device.patch fs-don-t-try-and-remove-empty-rbtree-node.patch hv_netvsc-fix-vf-namespace-also-in-synthetic-nic-netdev_register-event.patch kvm-arm64-don-t-eagerly-teardown-the-vgic-on-init-error.patch kvm-arm64-fix-shift-out-of-bounds-bug.patch kvm-arm64-unregister-redistributor-for-failed-vcpu-creation.patch kvm-nsvm-ignore-ncr3-when-loading-pdptes-from-memory.patch loongarch-enable-irq-if-do_ale-triggered-in-irq-enabled-context.patch loongarch-get-correct-cores_per_package-for-smt-systems.patch loongarch-make-kasan-usable-for-variable-cpu_vabits.patch md-raid10-fix-null-ptr-dereference-in-raid10_size.patch nilfs2-fix-kernel-bug-due-to-missing-clearing-of-buffer-delay-flag.patch openat2-explicitly-return-e2big-for-usize-page_size.patch x86-lam-disable-address_masking-in-most-cases.patch x86-sev-ensure-that-rmp-table-fixups-are-reserved.patch xfrm-fix-one-more-kernel-infoleak-in-algo-dumping.patch xfs-don-t-fail-repairs-on-metadata-files-with-no-attr-fork.patch --- ...2-to-fix-initial-lid-detection-issue.patch | 50 +++++++ ...me-block-for-prm-handler-and-context.patch | 114 ++++++++++++++++ ...90sp-to-irq1_level_low_skip_override.patch | 44 +++++++ ...oofer-quirk-for-acer-predator-g9-593.patch | 71 ++++++++++ ...elect-crc32-instead-of-crc32_sarwate.patch | 37 ++++++ ...-when-compress-mount-option-is-given.patch | 73 +++++++++++ ...r_ptr-in-btrfs_search_dir_index_item.patch | 59 +++++++++ ...-due-to-race-with-extent-map-merging.patch | 112 ++++++++++++++++ ...ult-value-for-subtree-drop-threshold.patch | 72 ++++++++++ ...on-if-there-are-hard-ro-requirements.patch | 110 ++++++++++++++++ ...accounting-for-freed-reserved-extent.patch | 51 +++++++ ...able-psr-su-on-parade-08-01-tcon-too.patch | 44 +++++++ ...gainst-bad-data-for-atif-acpi-method.patch | 75 +++++++++++ ...-of_node-of-the-parent-to-aux-bridge.patch | 43 ++++++ ...invalid-port-index-for-parent-device.patch | 50 +++++++ ...n-t-try-and-remove-empty-rbtree-node.patch | 39 ++++++ ...-synthetic-nic-netdev_register-event.patch | 75 +++++++++++ ...erly-teardown-the-vgic-on-init-error.patch | 73 +++++++++++ ...vm-arm64-fix-shift-out-of-bounds-bug.patch | 61 +++++++++ ...distributor-for-failed-vcpu-creation.patch | 97 ++++++++++++++ ...ncr3-when-loading-pdptes-from-memory.patch | 59 +++++++++ ...ale-triggered-in-irq-enabled-context.patch | 70 ++++++++++ ...ct-cores_per_package-for-smt-systems.patch | 58 ++++++++ ...kasan-usable-for-variable-cpu_vabits.patch | 36 +++++ ...-null-ptr-dereference-in-raid10_size.patch | 47 +++++++ ...issing-clearing-of-buffer-delay-flag.patch | 55 ++++++++ ...tly-return-e2big-for-usize-page_size.patch | 35 +++++ queue-6.11/series | 31 +++++ ...isable-address_masking-in-most-cases.patch | 46 +++++++ ...e-that-rmp-table-fixups-are-reserved.patch | 124 ++++++++++++++++++ ...more-kernel-infoleak-in-algo-dumping.patch | 101 ++++++++++++++ ...-on-metadata-files-with-no-attr-fork.patch | 39 ++++++ 32 files changed, 2051 insertions(+) create mode 100644 queue-6.11/acpi-button-add-dmi-quirk-for-samsung-galaxy-book2-to-fix-initial-lid-detection-issue.patch create mode 100644 queue-6.11/acpi-prm-find-efi_memory_runtime-block-for-prm-handler-and-context.patch create mode 100644 queue-6.11/acpi-resource-add-lg-16t90sp-to-irq1_level_low_skip_override.patch create mode 100644 queue-6.11/alsa-hda-realtek-add-subwoofer-quirk-for-acer-predator-g9-593.patch create mode 100644 queue-6.11/alsa-hda-tas2781-select-crc32-instead-of-crc32_sarwate.patch create mode 100644 queue-6.11/btrfs-clear-force-compress-on-remount-when-compress-mount-option-is-given.patch create mode 100644 queue-6.11/btrfs-fix-passing-0-to-err_ptr-in-btrfs_search_dir_index_item.patch create mode 100644 queue-6.11/btrfs-fix-read-corruption-due-to-race-with-extent-map-merging.patch create mode 100644 queue-6.11/btrfs-qgroup-set-a-more-sane-default-value-for-subtree-drop-threshold.patch create mode 100644 queue-6.11/btrfs-reject-ro-rw-reconfiguration-if-there-are-hard-ro-requirements.patch create mode 100644 queue-6.11/btrfs-zoned-fix-zone-unusable-accounting-for-freed-reserved-extent.patch create mode 100644 queue-6.11/drm-amd-display-disable-psr-su-on-parade-08-01-tcon-too.patch create mode 100644 queue-6.11/drm-amd-guard-against-bad-data-for-atif-acpi-method.patch create mode 100644 queue-6.11/drm-bridge-fix-assignment-of-the-of_node-of-the-parent-to-aux-bridge.patch create mode 100644 queue-6.11/firewire-core-fix-invalid-port-index-for-parent-device.patch create mode 100644 queue-6.11/fs-don-t-try-and-remove-empty-rbtree-node.patch create mode 100644 queue-6.11/hv_netvsc-fix-vf-namespace-also-in-synthetic-nic-netdev_register-event.patch create mode 100644 queue-6.11/kvm-arm64-don-t-eagerly-teardown-the-vgic-on-init-error.patch create mode 100644 queue-6.11/kvm-arm64-fix-shift-out-of-bounds-bug.patch create mode 100644 queue-6.11/kvm-arm64-unregister-redistributor-for-failed-vcpu-creation.patch create mode 100644 queue-6.11/kvm-nsvm-ignore-ncr3-when-loading-pdptes-from-memory.patch create mode 100644 queue-6.11/loongarch-enable-irq-if-do_ale-triggered-in-irq-enabled-context.patch create mode 100644 queue-6.11/loongarch-get-correct-cores_per_package-for-smt-systems.patch create mode 100644 queue-6.11/loongarch-make-kasan-usable-for-variable-cpu_vabits.patch create mode 100644 queue-6.11/md-raid10-fix-null-ptr-dereference-in-raid10_size.patch create mode 100644 queue-6.11/nilfs2-fix-kernel-bug-due-to-missing-clearing-of-buffer-delay-flag.patch create mode 100644 queue-6.11/openat2-explicitly-return-e2big-for-usize-page_size.patch create mode 100644 queue-6.11/x86-lam-disable-address_masking-in-most-cases.patch create mode 100644 queue-6.11/x86-sev-ensure-that-rmp-table-fixups-are-reserved.patch create mode 100644 queue-6.11/xfrm-fix-one-more-kernel-infoleak-in-algo-dumping.patch create mode 100644 queue-6.11/xfs-don-t-fail-repairs-on-metadata-files-with-no-attr-fork.patch diff --git a/queue-6.11/acpi-button-add-dmi-quirk-for-samsung-galaxy-book2-to-fix-initial-lid-detection-issue.patch b/queue-6.11/acpi-button-add-dmi-quirk-for-samsung-galaxy-book2-to-fix-initial-lid-detection-issue.patch new file mode 100644 index 00000000000..76d54e63f49 --- /dev/null +++ b/queue-6.11/acpi-button-add-dmi-quirk-for-samsung-galaxy-book2-to-fix-initial-lid-detection-issue.patch @@ -0,0 +1,50 @@ +From 8fa73ee44daefc884c53a25158c25a4107eb5a94 Mon Sep 17 00:00:00 2001 +From: Shubham Panwar +Date: Sun, 20 Oct 2024 15:20:46 +0530 +Subject: ACPI: button: Add DMI quirk for Samsung Galaxy Book2 to fix initial lid detection issue + +From: Shubham Panwar + +commit 8fa73ee44daefc884c53a25158c25a4107eb5a94 upstream. + +Add a DMI quirk for Samsung Galaxy Book2 to fix an initial lid state +detection issue. + +The _LID device incorrectly returns the lid status as "closed" during +boot, causing the system to enter a suspend loop right after booting. + +The quirk ensures that the correct lid state is reported initially, +preventing the system from immediately suspending after startup. It +only addresses the initial lid state detection and ensures proper +system behavior upon boot. + +Signed-off-by: Shubham Panwar +Link: https://patch.msgid.link/20241020095045.6036-2-shubiisp8@gmail.com +[ rjw: Changelog edits ] +Cc: All applicable +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + drivers/acpi/button.c | 11 +++++++++++ + 1 file changed, 11 insertions(+) + +--- a/drivers/acpi/button.c ++++ b/drivers/acpi/button.c +@@ -130,6 +130,17 @@ static const struct dmi_system_id dmi_li + }, + .driver_data = (void *)(long)ACPI_BUTTON_LID_INIT_OPEN, + }, ++ { ++ /* ++ * Samsung galaxybook2 ,initial _LID device notification returns ++ * lid closed. ++ */ ++ .matches = { ++ DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."), ++ DMI_MATCH(DMI_PRODUCT_NAME, "750XED"), ++ }, ++ .driver_data = (void *)(long)ACPI_BUTTON_LID_INIT_OPEN, ++ }, + {} + }; + diff --git a/queue-6.11/acpi-prm-find-efi_memory_runtime-block-for-prm-handler-and-context.patch b/queue-6.11/acpi-prm-find-efi_memory_runtime-block-for-prm-handler-and-context.patch new file mode 100644 index 00000000000..f010084eb10 --- /dev/null +++ b/queue-6.11/acpi-prm-find-efi_memory_runtime-block-for-prm-handler-and-context.patch @@ -0,0 +1,114 @@ +From 088984c8d54c0053fc4ae606981291d741c5924b Mon Sep 17 00:00:00 2001 +From: Koba Ko +Date: Sun, 13 Oct 2024 04:50:10 +0800 +Subject: ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context + +From: Koba Ko + +commit 088984c8d54c0053fc4ae606981291d741c5924b upstream. + +PRMT needs to find the correct type of block to translate the PA-VA +mapping for EFI runtime services. + +The issue arises because the PRMT is finding a block of type +EFI_CONVENTIONAL_MEMORY, which is not appropriate for runtime services +as described in Section 2.2.2 (Runtime Services) of the UEFI +Specification [1]. Since the PRM handler is a type of runtime service, +this causes an exception when the PRM handler is called. + + [Firmware Bug]: Unable to handle paging request in EFI runtime service + WARNING: CPU: 22 PID: 4330 at drivers/firmware/efi/runtime-wrappers.c:341 + __efi_queue_work+0x11c/0x170 + Call trace: + +Let PRMT find a block with EFI_MEMORY_RUNTIME for PRM handler and PRM +context. + +If no suitable block is found, a warning message will be printed, but +the procedure continues to manage the next PRM handler. + +However, if the PRM handler is actually called without proper allocation, +it would result in a failure during error handling. + +By using the correct memory types for runtime services, ensure that the +PRM handler and the context are properly mapped in the virtual address +space during runtime, preventing the paging request error. + +The issue is really that only memory that has been remapped for runtime +by the firmware can be used by the PRM handler, and so the region needs +to have the EFI_MEMORY_RUNTIME attribute. + +Link: https://uefi.org/sites/default/files/resources/UEFI_Spec_2_10_Aug29.pdf # [1] +Fixes: cefc7ca46235 ("ACPI: PRM: implement OperationRegion handler for the PlatformRtMechanism subtype") +Cc: All applicable +Signed-off-by: Koba Ko +Reviewed-by: Matthew R. Ochs +Reviewed-by: Zhang Rui +Reviewed-by: Ard Biesheuvel +Link: https://patch.msgid.link/20241012205010.4165798-1-kobak@nvidia.com +[ rjw: Subject and changelog edits ] +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + drivers/acpi/prmt.c | 27 ++++++++++++++++++++++----- + 1 file changed, 22 insertions(+), 5 deletions(-) + +--- a/drivers/acpi/prmt.c ++++ b/drivers/acpi/prmt.c +@@ -72,17 +72,21 @@ struct prm_module_info { + struct prm_handler_info handlers[] __counted_by(handler_count); + }; + +-static u64 efi_pa_va_lookup(u64 pa) ++static u64 efi_pa_va_lookup(efi_guid_t *guid, u64 pa) + { + efi_memory_desc_t *md; + u64 pa_offset = pa & ~PAGE_MASK; + u64 page = pa & PAGE_MASK; + + for_each_efi_memory_desc(md) { +- if (md->phys_addr < pa && pa < md->phys_addr + PAGE_SIZE * md->num_pages) ++ if ((md->attribute & EFI_MEMORY_RUNTIME) && ++ (md->phys_addr < pa && pa < md->phys_addr + PAGE_SIZE * md->num_pages)) { + return pa_offset + md->virt_addr + page - md->phys_addr; ++ } + } + ++ pr_warn("Failed to find VA for GUID: %pUL, PA: 0x%llx", guid, pa); ++ + return 0; + } + +@@ -148,9 +152,15 @@ acpi_parse_prmt(union acpi_subtable_head + th = &tm->handlers[cur_handler]; + + guid_copy(&th->guid, (guid_t *)handler_info->handler_guid); +- th->handler_addr = (void *)efi_pa_va_lookup(handler_info->handler_address); +- th->static_data_buffer_addr = efi_pa_va_lookup(handler_info->static_data_buffer_address); +- th->acpi_param_buffer_addr = efi_pa_va_lookup(handler_info->acpi_param_buffer_address); ++ th->handler_addr = ++ (void *)efi_pa_va_lookup(&th->guid, handler_info->handler_address); ++ ++ th->static_data_buffer_addr = ++ efi_pa_va_lookup(&th->guid, handler_info->static_data_buffer_address); ++ ++ th->acpi_param_buffer_addr = ++ efi_pa_va_lookup(&th->guid, handler_info->acpi_param_buffer_address); ++ + } while (++cur_handler < tm->handler_count && (handler_info = get_next_handler(handler_info))); + + return 0; +@@ -253,6 +263,13 @@ static acpi_status acpi_platformrt_space + if (!handler || !module) + goto invalid_guid; + ++ if (!handler->handler_addr || ++ !handler->static_data_buffer_addr || ++ !handler->acpi_param_buffer_addr) { ++ buffer->prm_status = PRM_HANDLER_ERROR; ++ return AE_OK; ++ } ++ + ACPI_COPY_NAMESEG(context.signature, "PRMC"); + context.revision = 0x0; + context.reserved = 0x0; diff --git a/queue-6.11/acpi-resource-add-lg-16t90sp-to-irq1_level_low_skip_override.patch b/queue-6.11/acpi-resource-add-lg-16t90sp-to-irq1_level_low_skip_override.patch new file mode 100644 index 00000000000..c49b78e9939 --- /dev/null +++ b/queue-6.11/acpi-resource-add-lg-16t90sp-to-irq1_level_low_skip_override.patch @@ -0,0 +1,44 @@ +From 53f1a907d36fb3aa02a4d34073bcec25823a6c74 Mon Sep 17 00:00:00 2001 +From: Christian Heusel +Date: Thu, 17 Oct 2024 13:16:26 +0200 +Subject: ACPI: resource: Add LG 16T90SP to irq1_level_low_skip_override[] + +From: Christian Heusel + +commit 53f1a907d36fb3aa02a4d34073bcec25823a6c74 upstream. + +The LG Gram Pro 16 2-in-1 (2024) the 16T90SP has its keybopard IRQ (1) +described as ActiveLow in the DSDT, which the kernel overrides to EdgeHigh +which breaks the keyboard. + +Add the 16T90SP to the irq1_level_low_skip_override[] quirk table to fix +this. + +Reported-by: Dirk Holten +Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219382 +Cc: All applicable +Suggested-by: Dirk Holten +Signed-off-by: Christian Heusel +Link: https://patch.msgid.link/20241017-lg-gram-pro-keyboard-v2-1-7c8fbf6ff718@heusel.eu +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + drivers/acpi/resource.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/drivers/acpi/resource.c ++++ b/drivers/acpi/resource.c +@@ -538,6 +538,13 @@ static const struct dmi_system_id irq1_l + DMI_MATCH(DMI_BOARD_NAME, "17U70P"), + }, + }, ++ { ++ /* LG Electronics 16T90SP */ ++ .matches = { ++ DMI_MATCH(DMI_SYS_VENDOR, "LG Electronics"), ++ DMI_MATCH(DMI_BOARD_NAME, "16T90SP"), ++ }, ++ }, + { } + }; + diff --git a/queue-6.11/alsa-hda-realtek-add-subwoofer-quirk-for-acer-predator-g9-593.patch b/queue-6.11/alsa-hda-realtek-add-subwoofer-quirk-for-acer-predator-g9-593.patch new file mode 100644 index 00000000000..b054a3ef132 --- /dev/null +++ b/queue-6.11/alsa-hda-realtek-add-subwoofer-quirk-for-acer-predator-g9-593.patch @@ -0,0 +1,71 @@ +From 35fdc6e1c16099078bcbd73a6c8f1733ae7f1909 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Jos=C3=A9=20Relvas?= +Date: Sun, 20 Oct 2024 11:27:56 +0100 +Subject: ALSA: hda/realtek: Add subwoofer quirk for Acer Predator G9-593 +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: José Relvas + +commit 35fdc6e1c16099078bcbd73a6c8f1733ae7f1909 upstream. + +The Acer Predator G9-593 has a 2+1 speaker system which isn't probed +correctly. +This patch adds a quirk with the proper pin connections. + +Note that I do not own this laptop, so I cannot guarantee that this +fixes the issue. +Testing was done by other users here: +https://discussion.fedoraproject.org/t/-/118482 + +This model appears to have two different dev IDs... + +- 0x1177 (as seen on the forum link above) +- 0x1178 (as seen on https://linux-hardware.org/?probe=127df9999f) + +I don't think the audio system was changed between model revisions, so +the patch applies for both IDs. + +Signed-off-by: José Relvas +Link: https://patch.msgid.link/20241020102756.225258-1-josemonsantorelvas@gmail.com +Cc: +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/pci/hda/patch_realtek.c | 10 ++++++++++ + 1 file changed, 10 insertions(+) + +--- a/sound/pci/hda/patch_realtek.c ++++ b/sound/pci/hda/patch_realtek.c +@@ -7631,6 +7631,7 @@ enum { + ALC286_FIXUP_ACER_AIO_HEADSET_MIC, + ALC256_FIXUP_ASUS_HEADSET_MIC, + ALC256_FIXUP_ASUS_MIC_NO_PRESENCE, ++ ALC255_FIXUP_PREDATOR_SUBWOOFER, + ALC299_FIXUP_PREDATOR_SPK, + ALC256_FIXUP_MEDION_HEADSET_NO_PRESENCE, + ALC289_FIXUP_DELL_SPK1, +@@ -9047,6 +9048,13 @@ static const struct hda_fixup alc269_fix + .chained = true, + .chain_id = ALC256_FIXUP_ASUS_HEADSET_MODE + }, ++ [ALC255_FIXUP_PREDATOR_SUBWOOFER] = { ++ .type = HDA_FIXUP_PINS, ++ .v.pins = (const struct hda_pintbl[]) { ++ { 0x17, 0x90170151 }, /* use as internal speaker (LFE) */ ++ { 0x1b, 0x90170152 } /* use as internal speaker (back) */ ++ } ++ }, + [ALC299_FIXUP_PREDATOR_SPK] = { + .type = HDA_FIXUP_PINS, + .v.pins = (const struct hda_pintbl[]) { +@@ -10138,6 +10146,8 @@ static const struct snd_pci_quirk alc269 + SND_PCI_QUIRK(0x1025, 0x110e, "Acer Aspire ES1-432", ALC255_FIXUP_ACER_MIC_NO_PRESENCE), + SND_PCI_QUIRK(0x1025, 0x1166, "Acer Veriton N4640G", ALC269_FIXUP_LIFEBOOK), + SND_PCI_QUIRK(0x1025, 0x1167, "Acer Veriton N6640G", ALC269_FIXUP_LIFEBOOK), ++ SND_PCI_QUIRK(0x1025, 0x1177, "Acer Predator G9-593", ALC255_FIXUP_PREDATOR_SUBWOOFER), ++ SND_PCI_QUIRK(0x1025, 0x1178, "Acer Predator G9-593", ALC255_FIXUP_PREDATOR_SUBWOOFER), + SND_PCI_QUIRK(0x1025, 0x1246, "Acer Predator Helios 500", ALC299_FIXUP_PREDATOR_SPK), + SND_PCI_QUIRK(0x1025, 0x1247, "Acer vCopperbox", ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS), + SND_PCI_QUIRK(0x1025, 0x1248, "Acer Veriton N4660G", ALC269VC_FIXUP_ACER_MIC_NO_PRESENCE), diff --git a/queue-6.11/alsa-hda-tas2781-select-crc32-instead-of-crc32_sarwate.patch b/queue-6.11/alsa-hda-tas2781-select-crc32-instead-of-crc32_sarwate.patch new file mode 100644 index 00000000000..0cdbdfa288b --- /dev/null +++ b/queue-6.11/alsa-hda-tas2781-select-crc32-instead-of-crc32_sarwate.patch @@ -0,0 +1,37 @@ +From 86c96e7289c5758284b562ac7b5c94429f48d2d9 Mon Sep 17 00:00:00 2001 +From: Eric Biggers +Date: Sun, 20 Oct 2024 10:56:24 -0700 +Subject: ALSA: hda/tas2781: select CRC32 instead of CRC32_SARWATE + +From: Eric Biggers + +commit 86c96e7289c5758284b562ac7b5c94429f48d2d9 upstream. + +Fix the kconfig option for the tas2781 HDA driver to select CRC32 rather +than CRC32_SARWATE. CRC32_SARWATE is an option from the kconfig +'choice' that selects the specific CRC32 implementation. Selecting a +'choice' option seems to have no effect, but even if it did work, it +would be incorrect for a random driver to override the user's choice. +CRC32 is the correct option to select for crc32() to be available. + +Fixes: 5be27f1e3ec9 ("ALSA: hda/tas2781: Add tas2781 HDA driver") +Cc: stable@vger.kernel.org +Signed-off-by: Eric Biggers +Link: https://patch.msgid.link/20241020175624.7095-1-ebiggers@kernel.org +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/pci/hda/Kconfig | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/sound/pci/hda/Kconfig ++++ b/sound/pci/hda/Kconfig +@@ -198,7 +198,7 @@ config SND_HDA_SCODEC_TAS2781_I2C + depends on SND_SOC + select SND_SOC_TAS2781_COMLIB + select SND_SOC_TAS2781_FMWLIB +- select CRC32_SARWATE ++ select CRC32 + help + Say Y or M here to include TAS2781 I2C HD-audio side codec support + in snd-hda-intel driver, such as ALC287. diff --git a/queue-6.11/btrfs-clear-force-compress-on-remount-when-compress-mount-option-is-given.patch b/queue-6.11/btrfs-clear-force-compress-on-remount-when-compress-mount-option-is-given.patch new file mode 100644 index 00000000000..6624c401c64 --- /dev/null +++ b/queue-6.11/btrfs-clear-force-compress-on-remount-when-compress-mount-option-is-given.patch @@ -0,0 +1,73 @@ +From 3510e684b8f6a569c2f8b86870da116e2ffeec2d Mon Sep 17 00:00:00 2001 +From: Filipe Manana +Date: Mon, 14 Oct 2024 16:14:18 +0100 +Subject: btrfs: clear force-compress on remount when compress mount option is given + +From: Filipe Manana + +commit 3510e684b8f6a569c2f8b86870da116e2ffeec2d upstream. + +After the migration to use fs context for processing mount options we had +a slight change in the semantics for remounting a filesystem that was +mounted with compress-force. Before we could clear compress-force by +passing only "-o compress[=algo]" during a remount, but after that change +that does not work anymore, force-compress is still present and one needs +to pass "-o compress-force=no,compress[=algo]" to the mount command. + +Example, when running on a kernel 6.8+: + + $ mount -o compress-force=zlib:9 /dev/sdi /mnt/sdi + $ mount | grep sdi + /dev/sdi on /mnt/sdi type btrfs (rw,relatime,compress-force=zlib:9,discard=async,space_cache=v2,subvolid=5,subvol=/) + + $ mount -o remount,compress=zlib:5 /mnt/sdi + $ mount | grep sdi + /dev/sdi on /mnt/sdi type btrfs (rw,relatime,compress-force=zlib:5,discard=async,space_cache=v2,subvolid=5,subvol=/) + +On a 6.7 kernel (or older): + + $ mount -o compress-force=zlib:9 /dev/sdi /mnt/sdi + $ mount | grep sdi + /dev/sdi on /mnt/sdi type btrfs (rw,relatime,compress-force=zlib:9,discard=async,space_cache=v2,subvolid=5,subvol=/) + + $ mount -o remount,compress=zlib:5 /mnt/sdi + $ mount | grep sdi + /dev/sdi on /mnt/sdi type btrfs (rw,relatime,compress=zlib:5,discard=async,space_cache=v2,subvolid=5,subvol=/) + +So update btrfs_parse_param() to clear "compress-force" when "compress" is +given, providing the same semantics as kernel 6.7 and older. + +Reported-by: Roman Mamedov +Link: https://lore.kernel.org/linux-btrfs/20241014182416.13d0f8b0@nvm/ +CC: stable@vger.kernel.org # 6.8+ +Signed-off-by: Filipe Manana +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/super.c | 9 +++++++++ + 1 file changed, 9 insertions(+) + +diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c +index 98fa0f382480..3f8673f97432 100644 +--- a/fs/btrfs/super.c ++++ b/fs/btrfs/super.c +@@ -340,6 +340,15 @@ static int btrfs_parse_param(struct fs_context *fc, struct fs_parameter *param) + fallthrough; + case Opt_compress: + case Opt_compress_type: ++ /* ++ * Provide the same semantics as older kernels that don't use fs ++ * context, specifying the "compress" option clears ++ * "force-compress" without the need to pass ++ * "compress-force=[no|none]" before specifying "compress". ++ */ ++ if (opt != Opt_compress_force && opt != Opt_compress_force_type) ++ btrfs_clear_opt(ctx->mount_opt, FORCE_COMPRESS); ++ + if (opt == Opt_compress || opt == Opt_compress_force) { + ctx->compress_type = BTRFS_COMPRESS_ZLIB; + ctx->compress_level = BTRFS_ZLIB_DEFAULT_LEVEL; +-- +2.47.0 + diff --git a/queue-6.11/btrfs-fix-passing-0-to-err_ptr-in-btrfs_search_dir_index_item.patch b/queue-6.11/btrfs-fix-passing-0-to-err_ptr-in-btrfs_search_dir_index_item.patch new file mode 100644 index 00000000000..e29d2c75d42 --- /dev/null +++ b/queue-6.11/btrfs-fix-passing-0-to-err_ptr-in-btrfs_search_dir_index_item.patch @@ -0,0 +1,59 @@ +From 75f49c3dc7b7423d3734f2e4dabe3dac8d064338 Mon Sep 17 00:00:00 2001 +From: Yue Haibing +Date: Tue, 22 Oct 2024 17:52:08 +0800 +Subject: btrfs: fix passing 0 to ERR_PTR in btrfs_search_dir_index_item() + +From: Yue Haibing + +commit 75f49c3dc7b7423d3734f2e4dabe3dac8d064338 upstream. + +The ret may be zero in btrfs_search_dir_index_item() and should not +passed to ERR_PTR(). Now btrfs_unlink_subvol() is the only caller to +this, reconstructed it to check ERR_PTR(-ENOENT) while ret >= 0. + +This fixes smatch warnings: + +fs/btrfs/dir-item.c:353 + btrfs_search_dir_index_item() warn: passing zero to 'ERR_PTR' + +Fixes: 9dcbe16fccbb ("btrfs: use btrfs_for_each_slot in btrfs_search_dir_index_item") +CC: stable@vger.kernel.org # 6.1+ +Reviewed-by: Johannes Thumshirn +Signed-off-by: Yue Haibing +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/dir-item.c | 4 ++-- + fs/btrfs/inode.c | 7 ++----- + 2 files changed, 4 insertions(+), 7 deletions(-) + +--- a/fs/btrfs/dir-item.c ++++ b/fs/btrfs/dir-item.c +@@ -347,8 +347,8 @@ btrfs_search_dir_index_item(struct btrfs + return di; + } + /* Adjust return code if the key was not found in the next leaf. */ +- if (ret > 0) +- ret = 0; ++ if (ret >= 0) ++ ret = -ENOENT; + + return ERR_PTR(ret); + } +--- a/fs/btrfs/inode.c ++++ b/fs/btrfs/inode.c +@@ -4344,11 +4344,8 @@ static int btrfs_unlink_subvol(struct bt + */ + if (btrfs_ino(inode) == BTRFS_EMPTY_SUBVOL_DIR_OBJECTID) { + di = btrfs_search_dir_index_item(root, path, dir_ino, &fname.disk_name); +- if (IS_ERR_OR_NULL(di)) { +- if (!di) +- ret = -ENOENT; +- else +- ret = PTR_ERR(di); ++ if (IS_ERR(di)) { ++ ret = PTR_ERR(di); + btrfs_abort_transaction(trans, ret); + goto out; + } diff --git a/queue-6.11/btrfs-fix-read-corruption-due-to-race-with-extent-map-merging.patch b/queue-6.11/btrfs-fix-read-corruption-due-to-race-with-extent-map-merging.patch new file mode 100644 index 00000000000..4d544ab00af --- /dev/null +++ b/queue-6.11/btrfs-fix-read-corruption-due-to-race-with-extent-map-merging.patch @@ -0,0 +1,112 @@ +From 7a2339058ed71f54c1e12e1b3c25aab1b1ba7943 Mon Sep 17 00:00:00 2001 +From: Boris Burkov +Date: Fri, 18 Oct 2024 15:44:34 -0700 +Subject: btrfs: fix read corruption due to race with extent map merging + +From: Boris Burkov + +commit 7a2339058ed71f54c1e12e1b3c25aab1b1ba7943 upstream. + +In debugging some corrupt squashfs files, we observed symptoms of +corrupt page cache pages but correct on-disk contents. Further +investigation revealed that the exact symptom was a correct page +followed by an incorrect, duplicate, page. This got us thinking about +extent maps. + +commit ac05ca913e9f ("Btrfs: fix race between using extent maps and merging them") +enforces a reference count on the primary `em` extent_map being merged, +as that one gets modified. + +However, since, +commit 3d2ac9922465 ("btrfs: introduce new members for extent_map") +both 'em' and 'merge' get modified, which started modifying 'merge' +and thus introduced the same race. + +We were able to reproduce this by looping the affected squashfs workload +in parallel on a bunch of separate btrfs-es while also dropping caches. +We are still working on a simple enough reproducer to make into an fstest. + +The simplest fix is to stop modifying 'merge', which is not essential, +as it is dropped immediately after the merge. This behavior is simply +a consequence of the order of the two extent maps being important in +computing the new values. Modify merge_ondisk_extents to take prev and +next by const* and also take a third merged parameter that it puts the +results in. Note that this introduces the rather odd behavior of passing +'em' to merge_ondisk_extents as a const * and as a regular ptr. + +Fixes: 3d2ac9922465 ("btrfs: introduce new members for extent_map") +CC: stable@vger.kernel.org # 6.11+ +Reviewed-by: Qu Wenruo +Reviewed-by: Filipe Manana +Signed-off-by: Omar Sandoval +Signed-off-by: Boris Burkov +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/extent_map.c | 31 ++++++++++++++++--------------- + 1 file changed, 16 insertions(+), 15 deletions(-) + +--- a/fs/btrfs/extent_map.c ++++ b/fs/btrfs/extent_map.c +@@ -240,13 +240,19 @@ static bool mergeable_maps(const struct + /* + * Handle the on-disk data extents merge for @prev and @next. + * ++ * @prev: left extent to merge ++ * @next: right extent to merge ++ * @merged: the extent we will not discard after the merge; updated with new values ++ * ++ * After this, one of the two extents is the new merged extent and the other is ++ * removed from the tree and likely freed. Note that @merged is one of @prev/@next ++ * so there is const/non-const aliasing occurring here. ++ * + * Only touches disk_bytenr/disk_num_bytes/offset/ram_bytes. + * For now only uncompressed regular extent can be merged. +- * +- * @prev and @next will be both updated to point to the new merged range. +- * Thus one of them should be removed by the caller. + */ +-static void merge_ondisk_extents(struct extent_map *prev, struct extent_map *next) ++static void merge_ondisk_extents(const struct extent_map *prev, const struct extent_map *next, ++ struct extent_map *merged) + { + u64 new_disk_bytenr; + u64 new_disk_num_bytes; +@@ -281,15 +287,10 @@ static void merge_ondisk_extents(struct + new_disk_bytenr; + new_offset = prev->disk_bytenr + prev->offset - new_disk_bytenr; + +- prev->disk_bytenr = new_disk_bytenr; +- prev->disk_num_bytes = new_disk_num_bytes; +- prev->ram_bytes = new_disk_num_bytes; +- prev->offset = new_offset; +- +- next->disk_bytenr = new_disk_bytenr; +- next->disk_num_bytes = new_disk_num_bytes; +- next->ram_bytes = new_disk_num_bytes; +- next->offset = new_offset; ++ merged->disk_bytenr = new_disk_bytenr; ++ merged->disk_num_bytes = new_disk_num_bytes; ++ merged->ram_bytes = new_disk_num_bytes; ++ merged->offset = new_offset; + } + + static void dump_extent_map(struct btrfs_fs_info *fs_info, const char *prefix, +@@ -358,7 +359,7 @@ static void try_merge_map(struct btrfs_i + em->generation = max(em->generation, merge->generation); + + if (em->disk_bytenr < EXTENT_MAP_LAST_BYTE) +- merge_ondisk_extents(merge, em); ++ merge_ondisk_extents(merge, em, em); + em->flags |= EXTENT_FLAG_MERGED; + + validate_extent_map(fs_info, em); +@@ -375,7 +376,7 @@ static void try_merge_map(struct btrfs_i + if (rb && can_merge_extent_map(merge) && mergeable_maps(em, merge)) { + em->len += merge->len; + if (em->disk_bytenr < EXTENT_MAP_LAST_BYTE) +- merge_ondisk_extents(em, merge); ++ merge_ondisk_extents(em, merge, em); + validate_extent_map(fs_info, em); + rb_erase(&merge->rb_node, &tree->root); + RB_CLEAR_NODE(&merge->rb_node); diff --git a/queue-6.11/btrfs-qgroup-set-a-more-sane-default-value-for-subtree-drop-threshold.patch b/queue-6.11/btrfs-qgroup-set-a-more-sane-default-value-for-subtree-drop-threshold.patch new file mode 100644 index 00000000000..f7b8da7cbde --- /dev/null +++ b/queue-6.11/btrfs-qgroup-set-a-more-sane-default-value-for-subtree-drop-threshold.patch @@ -0,0 +1,72 @@ +From 5f9062a48db260fd6b53d86ecfb4d5dc59266316 Mon Sep 17 00:00:00 2001 +From: Qu Wenruo +Date: Tue, 10 Sep 2024 15:21:04 +0930 +Subject: btrfs: qgroup: set a more sane default value for subtree drop threshold + +From: Qu Wenruo + +commit 5f9062a48db260fd6b53d86ecfb4d5dc59266316 upstream. + +Since commit 011b46c30476 ("btrfs: skip subtree scan if it's too high to +avoid low stall in btrfs_commit_transaction()"), btrfs qgroup can +automatically skip large subtree scan at the cost of marking qgroup +inconsistent. + +It's designed to address the final performance problem of snapshot drop +with qgroup enabled, but to be safe the default value is +BTRFS_MAX_LEVEL, requiring a user space daemon to set a different value +to make it work. + +I'd say it's not a good idea to rely on user space tool to set this +default value, especially when some operations (snapshot dropping) can +be triggered immediately after mount, leaving a very small window to +that that sysfs interface. + +So instead of disabling this new feature by default, enable it with a +low threshold (3), so that large subvolume tree drop at mount time won't +cause huge qgroup workload. + +CC: stable@vger.kernel.org # 6.1 +Signed-off-by: Qu Wenruo +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/disk-io.c | 2 +- + fs/btrfs/qgroup.c | 2 +- + fs/btrfs/qgroup.h | 2 ++ + 3 files changed, 4 insertions(+), 2 deletions(-) + +--- a/fs/btrfs/disk-io.c ++++ b/fs/btrfs/disk-io.c +@@ -1960,7 +1960,7 @@ static void btrfs_init_qgroup(struct btr + fs_info->qgroup_seq = 1; + fs_info->qgroup_ulist = NULL; + fs_info->qgroup_rescan_running = false; +- fs_info->qgroup_drop_subtree_thres = BTRFS_MAX_LEVEL; ++ fs_info->qgroup_drop_subtree_thres = BTRFS_QGROUP_DROP_SUBTREE_THRES_DEFAULT; + mutex_init(&fs_info->qgroup_rescan_lock); + } + +--- a/fs/btrfs/qgroup.c ++++ b/fs/btrfs/qgroup.c +@@ -1407,7 +1407,7 @@ int btrfs_quota_disable(struct btrfs_fs_ + fs_info->quota_root = NULL; + fs_info->qgroup_flags &= ~BTRFS_QGROUP_STATUS_FLAG_ON; + fs_info->qgroup_flags &= ~BTRFS_QGROUP_STATUS_FLAG_SIMPLE_MODE; +- fs_info->qgroup_drop_subtree_thres = BTRFS_MAX_LEVEL; ++ fs_info->qgroup_drop_subtree_thres = BTRFS_QGROUP_DROP_SUBTREE_THRES_DEFAULT; + spin_unlock(&fs_info->qgroup_lock); + + btrfs_free_qgroup_config(fs_info); +--- a/fs/btrfs/qgroup.h ++++ b/fs/btrfs/qgroup.h +@@ -121,6 +121,8 @@ struct btrfs_inode; + #define BTRFS_QGROUP_RUNTIME_FLAG_CANCEL_RESCAN (1ULL << 63) + #define BTRFS_QGROUP_RUNTIME_FLAG_NO_ACCOUNTING (1ULL << 62) + ++#define BTRFS_QGROUP_DROP_SUBTREE_THRES_DEFAULT (3) ++ + /* + * Record a dirty extent, and info qgroup to update quota on it + */ diff --git a/queue-6.11/btrfs-reject-ro-rw-reconfiguration-if-there-are-hard-ro-requirements.patch b/queue-6.11/btrfs-reject-ro-rw-reconfiguration-if-there-are-hard-ro-requirements.patch new file mode 100644 index 00000000000..cca9b12a7b3 --- /dev/null +++ b/queue-6.11/btrfs-reject-ro-rw-reconfiguration-if-there-are-hard-ro-requirements.patch @@ -0,0 +1,110 @@ +From 3c36a72c1d27de6618c1c480c793d9924640f5bb Mon Sep 17 00:00:00 2001 +From: Qu Wenruo +Date: Thu, 19 Sep 2024 20:18:11 +0930 +Subject: btrfs: reject ro->rw reconfiguration if there are hard ro requirements + +From: Qu Wenruo + +commit 3c36a72c1d27de6618c1c480c793d9924640f5bb upstream. + +[BUG] +Syzbot reports the following crash: + + BTRFS info (device loop0 state MCS): disabling free space tree + BTRFS info (device loop0 state MCS): clearing compat-ro feature flag for FREE_SPACE_TREE (0x1) + BTRFS info (device loop0 state MCS): clearing compat-ro feature flag for FREE_SPACE_TREE_VALID (0x2) + Oops: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN NOPTI + KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] + Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 + RIP: 0010:backup_super_roots fs/btrfs/disk-io.c:1691 [inline] + RIP: 0010:write_all_supers+0x97a/0x40f0 fs/btrfs/disk-io.c:4041 + Call Trace: + + btrfs_commit_transaction+0x1eae/0x3740 fs/btrfs/transaction.c:2530 + btrfs_delete_free_space_tree+0x383/0x730 fs/btrfs/free-space-tree.c:1312 + btrfs_start_pre_rw_mount+0xf28/0x1300 fs/btrfs/disk-io.c:3012 + btrfs_remount_rw fs/btrfs/super.c:1309 [inline] + btrfs_reconfigure+0xae6/0x2d40 fs/btrfs/super.c:1534 + btrfs_reconfigure_for_mount fs/btrfs/super.c:2020 [inline] + btrfs_get_tree_subvol fs/btrfs/super.c:2079 [inline] + btrfs_get_tree+0x918/0x1920 fs/btrfs/super.c:2115 + vfs_get_tree+0x90/0x2b0 fs/super.c:1800 + do_new_mount+0x2be/0xb40 fs/namespace.c:3472 + do_mount fs/namespace.c:3812 [inline] + __do_sys_mount fs/namespace.c:4020 [inline] + __se_sys_mount+0x2d6/0x3c0 fs/namespace.c:3997 + do_syscall_x64 arch/x86/entry/common.c:52 [inline] + do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 + entry_SYSCALL_64_after_hwframe+0x77/0x7f + +[CAUSE] +To support mounting different subvolume with different RO/RW flags for +the new mount APIs, btrfs introduced two workaround to support this feature: + +- Skip mount option/feature checks if we are mounting a different + subvolume + +- Reconfigure the fs to RW if the initial mount is RO + +Combining these two, we can have the following sequence: + +- Mount the fs ro,rescue=all,clear_cache,space_cache=v1 + rescue=all will mark the fs as hard read-only, so no v2 cache clearing + will happen. + +- Mount a subvolume rw of the same fs. + We go into btrfs_get_tree_subvol(), but fc_mount() returns EBUSY + because our new fc is RW, different from the original fs. + + Now we enter btrfs_reconfigure_for_mount(), which switches the RO flag + first so that we can grab the existing fs_info. + Then we reconfigure the fs to RW. + +- During reconfiguration, option/features check is skipped + This means we will restart the v2 cache clearing, and convert back to + v1 cache. + This will trigger fs writes, and since the original fs has "rescue=all" + option, it skips the csum tree read. + + And eventually causing NULL pointer dereference in super block + writeback. + +[FIX] +For reconfiguration caused by different subvolume RO/RW flags, ensure we +always run btrfs_check_options() to ensure we have proper hard RO +requirements met. + +In fact the function btrfs_check_options() doesn't really do many +complex checks, but hard RO requirement and some feature dependency +checks, thus there is no special reason not to do the check for mount +reconfiguration. + +Reported-by: syzbot+56360f93efa90ff15870@syzkaller.appspotmail.com +Link: https://lore.kernel.org/linux-btrfs/0000000000008c5d090621cb2770@google.com/ +Fixes: f044b318675f ("btrfs: handle the ro->rw transition for mounting different subvolumes") +CC: stable@vger.kernel.org # 6.8+ +Reviewed-by: Johannes Thumshirn +Signed-off-by: Qu Wenruo +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/super.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c +index 3f8673f97432..926d7a9ed99d 100644 +--- a/fs/btrfs/super.c ++++ b/fs/btrfs/super.c +@@ -1507,8 +1507,7 @@ static int btrfs_reconfigure(struct fs_context *fc) + sync_filesystem(sb); + set_bit(BTRFS_FS_STATE_REMOUNTING, &fs_info->fs_state); + +- if (!mount_reconfigure && +- !btrfs_check_options(fs_info, &ctx->mount_opt, fc->sb_flags)) ++ if (!btrfs_check_options(fs_info, &ctx->mount_opt, fc->sb_flags)) + return -EINVAL; + + ret = btrfs_check_features(fs_info, !(fc->sb_flags & SB_RDONLY)); +-- +2.47.0 + diff --git a/queue-6.11/btrfs-zoned-fix-zone-unusable-accounting-for-freed-reserved-extent.patch b/queue-6.11/btrfs-zoned-fix-zone-unusable-accounting-for-freed-reserved-extent.patch new file mode 100644 index 00000000000..53c647bde5c --- /dev/null +++ b/queue-6.11/btrfs-zoned-fix-zone-unusable-accounting-for-freed-reserved-extent.patch @@ -0,0 +1,51 @@ +From bf9821ba4792a0d9a2e72803ae7b4341faf3d532 Mon Sep 17 00:00:00 2001 +From: Naohiro Aota +Date: Tue, 1 Oct 2024 17:03:32 +0900 +Subject: btrfs: zoned: fix zone unusable accounting for freed reserved extent + +From: Naohiro Aota + +commit bf9821ba4792a0d9a2e72803ae7b4341faf3d532 upstream. + +When btrfs reserves an extent and does not use it (e.g, by an error), it +calls btrfs_free_reserved_extent() to free the reserved extent. In the +process, it calls btrfs_add_free_space() and then it accounts the region +bytes as block_group->zone_unusable. + +However, it leaves the space_info->bytes_zone_unusable side not updated. As +a result, ENOSPC can happen while a space_info reservation succeeded. The +reservation is fine because the freed region is not added in +space_info->bytes_zone_unusable, leaving that space as "free". OTOH, +corresponding block group counts it as zone_unusable and its allocation +pointer is not rewound, we cannot allocate an extent from that block group. +That will also negate space_info's async/sync reclaim process, and cause an +ENOSPC error from the extent allocation process. + +Fix that by returning the space to space_info->bytes_zone_unusable. +Ideally, since a bio is not submitted for this reserved region, we should +return the space to free space and rewind the allocation pointer. But, it +needs rework on extent allocation handling, so let it work in this way for +now. + +Fixes: 169e0da91a21 ("btrfs: zoned: track unusable bytes for zones") +CC: stable@vger.kernel.org # 5.15+ +Reviewed-by: Johannes Thumshirn +Signed-off-by: Naohiro Aota +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/block-group.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/fs/btrfs/block-group.c ++++ b/fs/btrfs/block-group.c +@@ -3819,6 +3819,8 @@ void btrfs_free_reserved_bytes(struct bt + spin_lock(&cache->lock); + if (cache->ro) + space_info->bytes_readonly += num_bytes; ++ else if (btrfs_is_zoned(cache->fs_info)) ++ space_info->bytes_zone_unusable += num_bytes; + cache->reserved -= num_bytes; + space_info->bytes_reserved -= num_bytes; + space_info->max_extent_size = 0; diff --git a/queue-6.11/drm-amd-display-disable-psr-su-on-parade-08-01-tcon-too.patch b/queue-6.11/drm-amd-display-disable-psr-su-on-parade-08-01-tcon-too.patch new file mode 100644 index 00000000000..cc4f6f81a6e --- /dev/null +++ b/queue-6.11/drm-amd-display-disable-psr-su-on-parade-08-01-tcon-too.patch @@ -0,0 +1,44 @@ +From ba1959f71117b27f3099ee789e0815360b4081dd Mon Sep 17 00:00:00 2001 +From: Mario Limonciello +Date: Mon, 5 Feb 2024 15:12:33 -0600 +Subject: drm/amd/display: Disable PSR-SU on Parade 08-01 TCON too + +From: Mario Limonciello + +commit ba1959f71117b27f3099ee789e0815360b4081dd upstream. + +Stuart Hayhurst has found that both at bootup and fullscreen VA-API video +is leading to black screens for around 1 second and kernel WARNING [1] traces +when calling dmub_psr_enable() with Parade 08-01 TCON. + +These symptoms all go away with PSR-SU disabled for this TCON, so disable +it for now while DMUB traces [2] from the failure can be analyzed and the failure +state properly root caused. + +Cc: Marc Rossi +Cc: Hamza Mahfooz +Link: https://gitlab.freedesktop.org/drm/amd/uploads/a832dd515b571ee171b3e3b566e99a13/dmesg.log [1] +Link: https://gitlab.freedesktop.org/drm/amd/uploads/8f13ff3b00963c833e23e68aa8116959/output.log [2] +Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2645 +Reviewed-by: Leo Li +Link: https://lore.kernel.org/r/20240205211233.2601-1-mario.limonciello@amd.com +Signed-off-by: Mario Limonciello +Signed-off-by: Alex Deucher +(cherry picked from commit afb634a6823d8d9db23c5fb04f79c5549349628b) +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/display/modules/power/power_helpers.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/gpu/drm/amd/display/modules/power/power_helpers.c ++++ b/drivers/gpu/drm/amd/display/modules/power/power_helpers.c +@@ -841,6 +841,8 @@ bool is_psr_su_specific_panel(struct dc_ + isPSRSUSupported = false; + else if (dpcd_caps->sink_dev_id_str[1] == 0x08 && dpcd_caps->sink_dev_id_str[0] == 0x03) + isPSRSUSupported = false; ++ else if (dpcd_caps->sink_dev_id_str[1] == 0x08 && dpcd_caps->sink_dev_id_str[0] == 0x01) ++ isPSRSUSupported = false; + else if (dpcd_caps->psr_info.force_psrsu_cap == 0x1) + isPSRSUSupported = true; + } diff --git a/queue-6.11/drm-amd-guard-against-bad-data-for-atif-acpi-method.patch b/queue-6.11/drm-amd-guard-against-bad-data-for-atif-acpi-method.patch new file mode 100644 index 00000000000..bc9f62bac2c --- /dev/null +++ b/queue-6.11/drm-amd-guard-against-bad-data-for-atif-acpi-method.patch @@ -0,0 +1,75 @@ +From bf58f03931fdcf7b3c45cb76ac13244477a60f44 Mon Sep 17 00:00:00 2001 +From: Mario Limonciello +Date: Fri, 11 Oct 2024 12:23:15 -0500 +Subject: drm/amd: Guard against bad data for ATIF ACPI method + +From: Mario Limonciello + +commit bf58f03931fdcf7b3c45cb76ac13244477a60f44 upstream. + +If a BIOS provides bad data in response to an ATIF method call +this causes a NULL pointer dereference in the caller. + +``` +? show_regs (arch/x86/kernel/dumpstack.c:478 (discriminator 1)) +? __die (arch/x86/kernel/dumpstack.c:423 arch/x86/kernel/dumpstack.c:434) +? page_fault_oops (arch/x86/mm/fault.c:544 (discriminator 2) arch/x86/mm/fault.c:705 (discriminator 2)) +? do_user_addr_fault (arch/x86/mm/fault.c:440 (discriminator 1) arch/x86/mm/fault.c:1232 (discriminator 1)) +? acpi_ut_update_object_reference (drivers/acpi/acpica/utdelete.c:642) +? exc_page_fault (arch/x86/mm/fault.c:1542) +? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) +? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:387 (discriminator 2)) amdgpu +? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:386 (discriminator 1)) amdgpu +``` + +It has been encountered on at least one system, so guard for it. + +Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)") +Acked-by: Alex Deucher +Signed-off-by: Mario Limonciello +Signed-off-by: Alex Deucher +(cherry picked from commit c9b7c809b89f24e9372a4e7f02d64c950b07fdee) +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 15 ++++++++++++--- + 1 file changed, 12 insertions(+), 3 deletions(-) + +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c +@@ -147,6 +147,7 @@ static union acpi_object *amdgpu_atif_ca + struct acpi_buffer *params) + { + acpi_status status; ++ union acpi_object *obj; + union acpi_object atif_arg_elements[2]; + struct acpi_object_list atif_arg; + struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL }; +@@ -169,16 +170,24 @@ static union acpi_object *amdgpu_atif_ca + + status = acpi_evaluate_object(atif->handle, NULL, &atif_arg, + &buffer); ++ obj = (union acpi_object *)buffer.pointer; + +- /* Fail only if calling the method fails and ATIF is supported */ ++ /* Fail if calling the method fails and ATIF is supported */ + if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) { + DRM_DEBUG_DRIVER("failed to evaluate ATIF got %s\n", + acpi_format_exception(status)); +- kfree(buffer.pointer); ++ kfree(obj); + return NULL; + } + +- return buffer.pointer; ++ if (obj->type != ACPI_TYPE_BUFFER) { ++ DRM_DEBUG_DRIVER("bad object returned from ATIF: %d\n", ++ obj->type); ++ kfree(obj); ++ return NULL; ++ } ++ ++ return obj; + } + + /** diff --git a/queue-6.11/drm-bridge-fix-assignment-of-the-of_node-of-the-parent-to-aux-bridge.patch b/queue-6.11/drm-bridge-fix-assignment-of-the-of_node-of-the-parent-to-aux-bridge.patch new file mode 100644 index 00000000000..4dc761c0b79 --- /dev/null +++ b/queue-6.11/drm-bridge-fix-assignment-of-the-of_node-of-the-parent-to-aux-bridge.patch @@ -0,0 +1,43 @@ +From 85e444a68126a631221ae32c63fce882bb18a262 Mon Sep 17 00:00:00 2001 +From: Abel Vesa +Date: Fri, 18 Oct 2024 15:49:34 +0300 +Subject: drm/bridge: Fix assignment of the of_node of the parent to aux bridge + +From: Abel Vesa + +commit 85e444a68126a631221ae32c63fce882bb18a262 upstream. + +The assignment of the of_node to the aux bridge needs to mark the +of_node as reused as well, otherwise resource providers like pinctrl will +report a gpio as already requested by a different device when both pinconf +and gpios property are present. +Fix that by using the device_set_of_node_from_dev() helper instead. + +Fixes: 6914968a0b52 ("drm/bridge: properly refcount DT nodes in aux bridge drivers") +Cc: stable@vger.kernel.org # 6.8 +Cc: Dmitry Baryshkov +Signed-off-by: Abel Vesa +Reviewed-by: Dmitry Baryshkov +Reviewed-by: Neil Armstrong +Link: https://lore.kernel.org/r/20241018-drm-aux-bridge-mark-of-node-reused-v2-1-aeed1b445c7d@linaro.org +Signed-off-by: Neil Armstrong +Link: https://patchwork.freedesktop.org/patch/msgid/20241018-drm-aux-bridge-mark-of-node-reused-v2-1-aeed1b445c7d@linaro.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/bridge/aux-bridge.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/gpu/drm/bridge/aux-bridge.c ++++ b/drivers/gpu/drm/bridge/aux-bridge.c +@@ -58,9 +58,10 @@ int drm_aux_bridge_register(struct devic + adev->id = ret; + adev->name = "aux_bridge"; + adev->dev.parent = parent; +- adev->dev.of_node = of_node_get(parent->of_node); + adev->dev.release = drm_aux_bridge_release; + ++ device_set_of_node_from_dev(&adev->dev, parent); ++ + ret = auxiliary_device_init(adev); + if (ret) { + ida_free(&drm_aux_bridge_ida, adev->id); diff --git a/queue-6.11/firewire-core-fix-invalid-port-index-for-parent-device.patch b/queue-6.11/firewire-core-fix-invalid-port-index-for-parent-device.patch new file mode 100644 index 00000000000..10031e5ef06 --- /dev/null +++ b/queue-6.11/firewire-core-fix-invalid-port-index-for-parent-device.patch @@ -0,0 +1,50 @@ +From f6a6780e0b9bbcf311a727afed06fee533a5e957 Mon Sep 17 00:00:00 2001 +From: Takashi Sakamoto +Date: Fri, 25 Oct 2024 12:41:37 +0900 +Subject: firewire: core: fix invalid port index for parent device + +From: Takashi Sakamoto + +commit f6a6780e0b9bbcf311a727afed06fee533a5e957 upstream. + +In a commit 24b7f8e5cd65 ("firewire: core: use helper functions for self +ID sequence"), the enumeration over self ID sequence was refactored with +some helper functions with KUnit tests. These helper functions are +guaranteed to work expectedly by the KUnit tests, however their application +includes a mistake to assign invalid value to the index of port connected +to parent device. + +This bug affects the case that any extra node devices which has three or +more ports are connected to 1394 OHCI controller. In the case, the path +to update the tree cache could hits WARN_ON(), and gets general protection +fault due to the access to invalid address computed by the invalid value. + +This commit fixes the bug to assign correct port index. + +Cc: stable@vger.kernel.org +Reported-by: Edmund Raile +Closes: https://lore.kernel.org/lkml/8a9902a4ece9329af1e1e42f5fea76861f0bf0e8.camel@proton.me/ +Fixes: 24b7f8e5cd65 ("firewire: core: use helper functions for self ID sequence") +Link: https://lore.kernel.org/r/20241025034137.99317-1-o-takashi@sakamocchi.jp +Signed-off-by: Takashi Sakamoto +Signed-off-by: Greg Kroah-Hartman +--- + drivers/firewire/core-topology.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/firewire/core-topology.c b/drivers/firewire/core-topology.c +index 6adadb11962e..892b94cfd626 100644 +--- a/drivers/firewire/core-topology.c ++++ b/drivers/firewire/core-topology.c +@@ -204,7 +204,7 @@ static struct fw_node *build_tree(struct fw_card *card, const u32 *sid, int self + // the node->ports array where the parent node should be. Later, + // when we handle the parent node, we fix up the reference. + ++parent_count; +- node->color = i; ++ node->color = port_index; + break; + + case PHY_PACKET_SELF_ID_PORT_STATUS_CHILD: +-- +2.47.0 + diff --git a/queue-6.11/fs-don-t-try-and-remove-empty-rbtree-node.patch b/queue-6.11/fs-don-t-try-and-remove-empty-rbtree-node.patch new file mode 100644 index 00000000000..ef775245b9d --- /dev/null +++ b/queue-6.11/fs-don-t-try-and-remove-empty-rbtree-node.patch @@ -0,0 +1,39 @@ +From 229fd15908fe1f99b1de4cde3326e62d1e892611 Mon Sep 17 00:00:00 2001 +From: Christian Brauner +Date: Wed, 16 Oct 2024 19:49:48 +0200 +Subject: fs: don't try and remove empty rbtree node + +From: Christian Brauner + +commit 229fd15908fe1f99b1de4cde3326e62d1e892611 upstream. + +When copying a namespace we won't have added the new copy into the +namespace rbtree until after the copy succeeded. Calling free_mnt_ns() +will try to remove the copy from the rbtree which is invalid. Simply +free the namespace skeleton directly. + +Link: https://lore.kernel.org/r/20241016-adapter-seilwinde-83c508a7bde1@brauner +Fixes: 1901c92497bd ("fs: keep an index of current mount namespaces") +Tested-by: Brad Spengler +Cc: stable@vger.kernel.org # v6.11+ +Reported-by: Brad Spengler +Suggested-by: Brad Spengler +Signed-off-by: Christian Brauner +Signed-off-by: Greg Kroah-Hartman +--- + fs/namespace.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/fs/namespace.c ++++ b/fs/namespace.c +@@ -3917,7 +3917,9 @@ struct mnt_namespace *copy_mnt_ns(unsign + new = copy_tree(old, old->mnt.mnt_root, copy_flags); + if (IS_ERR(new)) { + namespace_unlock(); +- free_mnt_ns(new_ns); ++ ns_free_inum(&new_ns->ns); ++ dec_mnt_namespaces(new_ns->ucounts); ++ mnt_ns_release(new_ns); + return ERR_CAST(new); + } + if (user_ns != ns->user_ns) { diff --git a/queue-6.11/hv_netvsc-fix-vf-namespace-also-in-synthetic-nic-netdev_register-event.patch b/queue-6.11/hv_netvsc-fix-vf-namespace-also-in-synthetic-nic-netdev_register-event.patch new file mode 100644 index 00000000000..dd3b8618883 --- /dev/null +++ b/queue-6.11/hv_netvsc-fix-vf-namespace-also-in-synthetic-nic-netdev_register-event.patch @@ -0,0 +1,75 @@ +From 4c262801ea60c518b5bebc22a09f5b78b3147da2 Mon Sep 17 00:00:00 2001 +From: Haiyang Zhang +Date: Fri, 18 Oct 2024 11:25:22 -0700 +Subject: hv_netvsc: Fix VF namespace also in synthetic NIC NETDEV_REGISTER event + +From: Haiyang Zhang + +commit 4c262801ea60c518b5bebc22a09f5b78b3147da2 upstream. + +The existing code moves VF to the same namespace as the synthetic NIC +during netvsc_register_vf(). But, if the synthetic device is moved to a +new namespace after the VF registration, the VF won't be moved together. + +To make the behavior more consistent, add a namespace check for synthetic +NIC's NETDEV_REGISTER event (generated during its move), and move the VF +if it is not in the same namespace. + +Cc: stable@vger.kernel.org +Fixes: c0a41b887ce6 ("hv_netvsc: move VF to same namespace as netvsc device") +Suggested-by: Stephen Hemminger +Signed-off-by: Haiyang Zhang +Reviewed-by: Simon Horman +Link: https://patch.msgid.link/1729275922-17595-1-git-send-email-haiyangz@microsoft.com +Signed-off-by: Paolo Abeni +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/hyperv/netvsc_drv.c | 30 ++++++++++++++++++++++++++++++ + 1 file changed, 30 insertions(+) + +--- a/drivers/net/hyperv/netvsc_drv.c ++++ b/drivers/net/hyperv/netvsc_drv.c +@@ -2797,6 +2797,31 @@ static struct hv_driver netvsc_drv = { + }, + }; + ++/* Set VF's namespace same as the synthetic NIC */ ++static void netvsc_event_set_vf_ns(struct net_device *ndev) ++{ ++ struct net_device_context *ndev_ctx = netdev_priv(ndev); ++ struct net_device *vf_netdev; ++ int ret; ++ ++ vf_netdev = rtnl_dereference(ndev_ctx->vf_netdev); ++ if (!vf_netdev) ++ return; ++ ++ if (!net_eq(dev_net(ndev), dev_net(vf_netdev))) { ++ ret = dev_change_net_namespace(vf_netdev, dev_net(ndev), ++ "eth%d"); ++ if (ret) ++ netdev_err(vf_netdev, ++ "Cannot move to same namespace as %s: %d\n", ++ ndev->name, ret); ++ else ++ netdev_info(vf_netdev, ++ "Moved VF to namespace with: %s\n", ++ ndev->name); ++ } ++} ++ + /* + * On Hyper-V, every VF interface is matched with a corresponding + * synthetic interface. The synthetic interface is presented first +@@ -2809,6 +2834,11 @@ static int netvsc_netdev_event(struct no + struct net_device *event_dev = netdev_notifier_info_to_dev(ptr); + int ret = 0; + ++ if (event_dev->netdev_ops == &device_ops && event == NETDEV_REGISTER) { ++ netvsc_event_set_vf_ns(event_dev); ++ return NOTIFY_DONE; ++ } ++ + ret = check_dev_is_matching_vf(event_dev); + if (ret != 0) + return NOTIFY_DONE; diff --git a/queue-6.11/kvm-arm64-don-t-eagerly-teardown-the-vgic-on-init-error.patch b/queue-6.11/kvm-arm64-don-t-eagerly-teardown-the-vgic-on-init-error.patch new file mode 100644 index 00000000000..c383f4e608e --- /dev/null +++ b/queue-6.11/kvm-arm64-don-t-eagerly-teardown-the-vgic-on-init-error.patch @@ -0,0 +1,73 @@ +From df5fd75ee305cb5927e0b1a0b46cc988ad8db2b1 Mon Sep 17 00:00:00 2001 +From: Marc Zyngier +Date: Wed, 9 Oct 2024 19:36:03 +0100 +Subject: KVM: arm64: Don't eagerly teardown the vgic on init error + +From: Marc Zyngier + +commit df5fd75ee305cb5927e0b1a0b46cc988ad8db2b1 upstream. + +As there is very little ordering in the KVM API, userspace can +instanciate a half-baked GIC (missing its memory map, for example) +at almost any time. + +This means that, with the right timing, a thread running vcpu-0 +can enter the kernel without a GIC configured and get a GIC created +behind its back by another thread. Amusingly, it will pick up +that GIC and start messing with the data structures without the +GIC having been fully initialised. + +Similarly, a thread running vcpu-1 can enter the kernel, and try +to init the GIC that was previously created. Since this GIC isn't +properly configured (no memory map), it fails to correctly initialise. + +And that's the point where we decide to teardown the GIC, freeing all +its resources. Behind vcpu-0's back. Things stop pretty abruptly, +with a variety of symptoms. Clearly, this isn't good, we should be +a bit more careful about this. + +It is obvious that this guest is not viable, as it is missing some +important part of its configuration. So instead of trying to tear +bits of it down, let's just mark it as *dead*. It means that any +further interaction from userspace will result in -EIO. The memory +will be released on the "normal" path, when userspace gives up. + +Cc: stable@vger.kernel.org +Reported-by: Alexander Potapenko +Reviewed-by: Oliver Upton +Link: https://lore.kernel.org/r/20241009183603.3221824-1-maz@kernel.org +Signed-off-by: Marc Zyngier +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/kvm/arm.c | 3 +++ + arch/arm64/kvm/vgic/vgic-init.c | 6 +++--- + 2 files changed, 6 insertions(+), 3 deletions(-) + +--- a/arch/arm64/kvm/arm.c ++++ b/arch/arm64/kvm/arm.c +@@ -996,6 +996,9 @@ static int kvm_vcpu_suspend(struct kvm_v + static int check_vcpu_requests(struct kvm_vcpu *vcpu) + { + if (kvm_request_pending(vcpu)) { ++ if (kvm_check_request(KVM_REQ_VM_DEAD, vcpu)) ++ return -EIO; ++ + if (kvm_check_request(KVM_REQ_SLEEP, vcpu)) + kvm_vcpu_sleep(vcpu); + +--- a/arch/arm64/kvm/vgic/vgic-init.c ++++ b/arch/arm64/kvm/vgic/vgic-init.c +@@ -556,10 +556,10 @@ int kvm_vgic_map_resources(struct kvm *k + out: + mutex_unlock(&kvm->arch.config_lock); + out_slots: +- mutex_unlock(&kvm->slots_lock); +- + if (ret) +- kvm_vgic_destroy(kvm); ++ kvm_vm_dead(kvm); ++ ++ mutex_unlock(&kvm->slots_lock); + + return ret; + } diff --git a/queue-6.11/kvm-arm64-fix-shift-out-of-bounds-bug.patch b/queue-6.11/kvm-arm64-fix-shift-out-of-bounds-bug.patch new file mode 100644 index 00000000000..c2c9e54fd8b --- /dev/null +++ b/queue-6.11/kvm-arm64-fix-shift-out-of-bounds-bug.patch @@ -0,0 +1,61 @@ +From c6c167afa090ea0451f91814e1318755a8fb8bb9 Mon Sep 17 00:00:00 2001 +From: Ilkka Koskinen +Date: Wed, 16 Oct 2024 19:57:01 -0700 +Subject: KVM: arm64: Fix shift-out-of-bounds bug + +From: Ilkka Koskinen + +commit c6c167afa090ea0451f91814e1318755a8fb8bb9 upstream. + +Fix a shift-out-of-bounds bug reported by UBSAN when running +VM with MTE enabled host kernel. + +UBSAN: shift-out-of-bounds in arch/arm64/kvm/sys_regs.c:1988:14 +shift exponent 33 is too large for 32-bit type 'int' +CPU: 26 UID: 0 PID: 7629 Comm: qemu-kvm Not tainted 6.12.0-rc2 #34 +Hardware name: IEI NF5280R7/Mitchell MB, BIOS 00.00. 2024-10-12 09:28:54 10/14/2024 +Call trace: + dump_backtrace+0xa0/0x128 + show_stack+0x20/0x38 + dump_stack_lvl+0x74/0x90 + dump_stack+0x18/0x28 + __ubsan_handle_shift_out_of_bounds+0xf8/0x1e0 + reset_clidr+0x10c/0x1c8 + kvm_reset_sys_regs+0x50/0x1c8 + kvm_reset_vcpu+0xec/0x2b0 + __kvm_vcpu_set_target+0x84/0x158 + kvm_vcpu_set_target+0x138/0x168 + kvm_arch_vcpu_ioctl_vcpu_init+0x40/0x2b0 + kvm_arch_vcpu_ioctl+0x28c/0x4b8 + kvm_vcpu_ioctl+0x4bc/0x7a8 + __arm64_sys_ioctl+0xb4/0x100 + invoke_syscall+0x70/0x100 + el0_svc_common.constprop.0+0x48/0xf0 + do_el0_svc+0x24/0x38 + el0_svc+0x3c/0x158 + el0t_64_sync_handler+0x120/0x130 + el0t_64_sync+0x194/0x198 + +Fixes: 7af0c2534f4c ("KVM: arm64: Normalize cache configuration") +Cc: stable@vger.kernel.org +Reviewed-by: Gavin Shan +Signed-off-by: Ilkka Koskinen +Reviewed-by: Anshuman Khandual +Link: https://lore.kernel.org/r/20241017025701.67936-1-ilkka@os.amperecomputing.com +Signed-off-by: Marc Zyngier +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/kvm/sys_regs.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/arm64/kvm/sys_regs.c ++++ b/arch/arm64/kvm/sys_regs.c +@@ -1977,7 +1977,7 @@ static u64 reset_clidr(struct kvm_vcpu * + * one cache line. + */ + if (kvm_has_mte(vcpu->kvm)) +- clidr |= 2 << CLIDR_TTYPE_SHIFT(loc); ++ clidr |= 2ULL << CLIDR_TTYPE_SHIFT(loc); + + __vcpu_sys_reg(vcpu, r->reg) = clidr; + diff --git a/queue-6.11/kvm-arm64-unregister-redistributor-for-failed-vcpu-creation.patch b/queue-6.11/kvm-arm64-unregister-redistributor-for-failed-vcpu-creation.patch new file mode 100644 index 00000000000..df5566891df --- /dev/null +++ b/queue-6.11/kvm-arm64-unregister-redistributor-for-failed-vcpu-creation.patch @@ -0,0 +1,97 @@ +From ae8f8b37610269009326f4318df161206c59843e Mon Sep 17 00:00:00 2001 +From: Oliver Upton +Date: Mon, 7 Oct 2024 22:39:09 +0000 +Subject: KVM: arm64: Unregister redistributor for failed vCPU creation + +From: Oliver Upton + +commit ae8f8b37610269009326f4318df161206c59843e upstream. + +Alex reports that syzkaller has managed to trigger a use-after-free when +tearing down a VM: + + BUG: KASAN: slab-use-after-free in kvm_put_kvm+0x300/0xe68 virt/kvm/kvm_main.c:5769 + Read of size 8 at addr ffffff801c6890d0 by task syz.3.2219/10758 + + CPU: 3 UID: 0 PID: 10758 Comm: syz.3.2219 Not tainted 6.11.0-rc6-dirty #64 + Hardware name: linux,dummy-virt (DT) + Call trace: + dump_backtrace+0x17c/0x1a8 arch/arm64/kernel/stacktrace.c:317 + show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:324 + __dump_stack lib/dump_stack.c:93 [inline] + dump_stack_lvl+0x94/0xc0 lib/dump_stack.c:119 + print_report+0x144/0x7a4 mm/kasan/report.c:377 + kasan_report+0xcc/0x128 mm/kasan/report.c:601 + __asan_report_load8_noabort+0x20/0x2c mm/kasan/report_generic.c:381 + kvm_put_kvm+0x300/0xe68 virt/kvm/kvm_main.c:5769 + kvm_vm_release+0x4c/0x60 virt/kvm/kvm_main.c:1409 + __fput+0x198/0x71c fs/file_table.c:422 + ____fput+0x20/0x30 fs/file_table.c:450 + task_work_run+0x1cc/0x23c kernel/task_work.c:228 + do_notify_resume+0x144/0x1a0 include/linux/resume_user_mode.h:50 + el0_svc+0x64/0x68 arch/arm64/kernel/entry-common.c:169 + el0t_64_sync_handler+0x90/0xfc arch/arm64/kernel/entry-common.c:730 + el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 + +Upon closer inspection, it appears that we do not properly tear down the +MMIO registration for a vCPU that fails creation late in the game, e.g. +a vCPU w/ the same ID already exists in the VM. + +It is important to consider the context of commit that introduced this bug +by moving the unregistration out of __kvm_vgic_vcpu_destroy(). That +change correctly sought to avoid an srcu v. config_lock inversion by +breaking up the vCPU teardown into two parts, one guarded by the +config_lock. + +Fix the use-after-free while avoiding lock inversion by adding a +special-cased unregistration to __kvm_vgic_vcpu_destroy(). This is safe +because failed vCPUs are torn down outside of the config_lock. + +Cc: stable@vger.kernel.org +Fixes: f616506754d3 ("KVM: arm64: vgic: Don't hold config_lock while unregistering redistributors") +Reported-by: Alexander Potapenko +Signed-off-by: Oliver Upton +Link: https://lore.kernel.org/r/20241007223909.2157336-1-oliver.upton@linux.dev +Signed-off-by: Marc Zyngier +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/kvm/vgic/vgic-init.c | 22 +++++++++++++++++++++- + 1 file changed, 21 insertions(+), 1 deletion(-) + +diff --git a/arch/arm64/kvm/vgic/vgic-init.c b/arch/arm64/kvm/vgic/vgic-init.c +index e7c53e8af3d1..57aedf7b2b76 100644 +--- a/arch/arm64/kvm/vgic/vgic-init.c ++++ b/arch/arm64/kvm/vgic/vgic-init.c +@@ -417,8 +417,28 @@ static void __kvm_vgic_vcpu_destroy(struct kvm_vcpu *vcpu) + kfree(vgic_cpu->private_irqs); + vgic_cpu->private_irqs = NULL; + +- if (vcpu->kvm->arch.vgic.vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3) ++ if (vcpu->kvm->arch.vgic.vgic_model == KVM_DEV_TYPE_ARM_VGIC_V3) { ++ /* ++ * If this vCPU is being destroyed because of a failed creation ++ * then unregister the redistributor to avoid leaving behind a ++ * dangling pointer to the vCPU struct. ++ * ++ * vCPUs that have been successfully created (i.e. added to ++ * kvm->vcpu_array) get unregistered in kvm_vgic_destroy(), as ++ * this function gets called while holding kvm->arch.config_lock ++ * in the VM teardown path and would otherwise introduce a lock ++ * inversion w.r.t. kvm->srcu. ++ * ++ * vCPUs that failed creation are torn down outside of the ++ * kvm->arch.config_lock and do not get unregistered in ++ * kvm_vgic_destroy(), meaning it is both safe and necessary to ++ * do so here. ++ */ ++ if (kvm_get_vcpu_by_id(vcpu->kvm, vcpu->vcpu_id) != vcpu) ++ vgic_unregister_redist_iodev(vcpu); ++ + vgic_cpu->rd_iodev.base_addr = VGIC_ADDR_UNDEF; ++ } + } + + void kvm_vgic_vcpu_destroy(struct kvm_vcpu *vcpu) +-- +2.47.0 + diff --git a/queue-6.11/kvm-nsvm-ignore-ncr3-when-loading-pdptes-from-memory.patch b/queue-6.11/kvm-nsvm-ignore-ncr3-when-loading-pdptes-from-memory.patch new file mode 100644 index 00000000000..89dba7aef85 --- /dev/null +++ b/queue-6.11/kvm-nsvm-ignore-ncr3-when-loading-pdptes-from-memory.patch @@ -0,0 +1,59 @@ +From f559b2e9c5c5308850544ab59396b7d53cfc67bd Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Wed, 9 Oct 2024 07:08:38 -0700 +Subject: KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory + +From: Sean Christopherson + +commit f559b2e9c5c5308850544ab59396b7d53cfc67bd upstream. + +Ignore nCR3[4:0] when loading PDPTEs from memory for nested SVM, as bits +4:0 of CR3 are ignored when PAE paging is used, and thus VMRUN doesn't +enforce 32-byte alignment of nCR3. + +In the absolute worst case scenario, failure to ignore bits 4:0 can result +in an out-of-bounds read, e.g. if the target page is at the end of a +memslot, and the VMM isn't using guard pages. + +Per the APM: + + The CR3 register points to the base address of the page-directory-pointer + table. The page-directory-pointer table is aligned on a 32-byte boundary, + with the low 5 address bits 4:0 assumed to be 0. + +And the SDM's much more explicit: + + 4:0 Ignored + +Note, KVM gets this right when loading PDPTRs, it's only the nSVM flow +that is broken. + +Fixes: e4e517b4be01 ("KVM: MMU: Do not unconditionally read PDPTE from guest memory") +Reported-by: Kirk Swidowski +Cc: Andy Nguyen +Cc: 3pvd <3pvd@google.com> +Cc: stable@vger.kernel.org +Signed-off-by: Sean Christopherson +Message-ID: <20241009140838.1036226-1-seanjc@google.com> +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/svm/nested.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +--- a/arch/x86/kvm/svm/nested.c ++++ b/arch/x86/kvm/svm/nested.c +@@ -63,8 +63,12 @@ static u64 nested_svm_get_tdp_pdptr(stru + u64 pdpte; + int ret; + ++ /* ++ * Note, nCR3 is "assumed" to be 32-byte aligned, i.e. the CPU ignores ++ * nCR3[4:0] when loading PDPTEs from memory. ++ */ + ret = kvm_vcpu_read_guest_page(vcpu, gpa_to_gfn(cr3), &pdpte, +- offset_in_page(cr3) + index * 8, 8); ++ (cr3 & GENMASK(11, 5)) + index * 8, 8); + if (ret) + return 0; + return pdpte; diff --git a/queue-6.11/loongarch-enable-irq-if-do_ale-triggered-in-irq-enabled-context.patch b/queue-6.11/loongarch-enable-irq-if-do_ale-triggered-in-irq-enabled-context.patch new file mode 100644 index 00000000000..a4ec8d66c3e --- /dev/null +++ b/queue-6.11/loongarch-enable-irq-if-do_ale-triggered-in-irq-enabled-context.patch @@ -0,0 +1,70 @@ +From 69cc6fad5df4ce652d969be69acc60e269e5eea1 Mon Sep 17 00:00:00 2001 +From: Huacai Chen +Date: Mon, 21 Oct 2024 22:11:19 +0800 +Subject: LoongArch: Enable IRQ if do_ale() triggered in irq-enabled context + +From: Huacai Chen + +commit 69cc6fad5df4ce652d969be69acc60e269e5eea1 upstream. + +Unaligned access exception can be triggered in irq-enabled context such +as user mode, in this case do_ale() may call get_user() which may cause +sleep. Then we will get: + + BUG: sleeping function called from invalid context at arch/loongarch/kernel/access-helper.h:7 + in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 129, name: modprobe + preempt_count: 0, expected: 0 + RCU nest depth: 0, expected: 0 + CPU: 0 UID: 0 PID: 129 Comm: modprobe Tainted: G W 6.12.0-rc1+ #1723 + Tainted: [W]=WARN + Stack : 9000000105e0bd48 0000000000000000 9000000003803944 9000000105e08000 + 9000000105e0bc70 9000000105e0bc78 0000000000000000 0000000000000000 + 9000000105e0bc78 0000000000000001 9000000185e0ba07 9000000105e0b890 + ffffffffffffffff 9000000105e0bc78 73924b81763be05b 9000000100194500 + 000000000000020c 000000000000000a 0000000000000000 0000000000000003 + 00000000000023f0 00000000000e1401 00000000072f8000 0000007ffbb0e260 + 0000000000000000 0000000000000000 9000000005437650 90000000055d5000 + 0000000000000000 0000000000000003 0000007ffbb0e1f0 0000000000000000 + 0000005567b00490 0000000000000000 9000000003803964 0000007ffbb0dfec + 00000000000000b0 0000000000000007 0000000000000003 0000000000071c1d + ... + Call Trace: + [<9000000003803964>] show_stack+0x64/0x1a0 + [<9000000004c57464>] dump_stack_lvl+0x74/0xb0 + [<9000000003861ab4>] __might_resched+0x154/0x1a0 + [<900000000380c96c>] emulate_load_store_insn+0x6c/0xf60 + [<9000000004c58118>] do_ale+0x78/0x180 + [<9000000003801bc8>] handle_ale+0x128/0x1e0 + +So enable IRQ if unaligned access exception is triggered in irq-enabled +context to fix it. + +Cc: stable@vger.kernel.org +Reported-by: Binbin Zhou +Signed-off-by: Huacai Chen +Signed-off-by: Greg Kroah-Hartman +--- + arch/loongarch/kernel/traps.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/arch/loongarch/kernel/traps.c ++++ b/arch/loongarch/kernel/traps.c +@@ -555,6 +555,9 @@ asmlinkage void noinstr do_ale(struct pt + #else + unsigned int *pc; + ++ if (regs->csr_prmd & CSR_PRMD_PIE) ++ local_irq_enable(); ++ + perf_sw_event(PERF_COUNT_SW_ALIGNMENT_FAULTS, 1, regs, regs->csr_badvaddr); + + /* +@@ -579,6 +582,8 @@ sigbus: + die_if_kernel("Kernel ale access", regs); + force_sig_fault(SIGBUS, BUS_ADRALN, (void __user *)regs->csr_badvaddr); + out: ++ if (regs->csr_prmd & CSR_PRMD_PIE) ++ local_irq_disable(); + #endif + irqentry_exit(regs, state); + } diff --git a/queue-6.11/loongarch-get-correct-cores_per_package-for-smt-systems.patch b/queue-6.11/loongarch-get-correct-cores_per_package-for-smt-systems.patch new file mode 100644 index 00000000000..0dc10080bb7 --- /dev/null +++ b/queue-6.11/loongarch-get-correct-cores_per_package-for-smt-systems.patch @@ -0,0 +1,58 @@ +From b7296f9d5bf99330063d4bbecc43c9b33fed0137 Mon Sep 17 00:00:00 2001 +From: Huacai Chen +Date: Mon, 21 Oct 2024 22:11:18 +0800 +Subject: LoongArch: Get correct cores_per_package for SMT systems + +From: Huacai Chen + +commit b7296f9d5bf99330063d4bbecc43c9b33fed0137 upstream. + +In loongson_sysconf, The "core" of cores_per_node and cores_per_package +stands for a logical core, which means in a SMT system it stands for a +thread indeed. This information is gotten from SMBIOS Type4 Structure, +so in order to get a correct cores_per_package for both SMT and non-SMT +systems in parse_cpu_table() we should use SMBIOS_THREAD_PACKAGE_OFFSET +instead of SMBIOS_CORE_PACKAGE_OFFSET. + +Cc: stable@vger.kernel.org +Reported-by: Chao Li +Tested-by: Chao Li +Signed-off-by: Huacai Chen +Signed-off-by: Greg Kroah-Hartman +--- + arch/loongarch/include/asm/bootinfo.h | 4 ++++ + arch/loongarch/kernel/setup.c | 3 ++- + 2 files changed, 6 insertions(+), 1 deletion(-) + +--- a/arch/loongarch/include/asm/bootinfo.h ++++ b/arch/loongarch/include/asm/bootinfo.h +@@ -26,6 +26,10 @@ struct loongson_board_info { + + #define NR_WORDS DIV_ROUND_UP(NR_CPUS, BITS_PER_LONG) + ++/* ++ * The "core" of cores_per_node and cores_per_package stands for a ++ * logical core, which means in a SMT system it stands for a thread. ++ */ + struct loongson_system_configuration { + int nr_cpus; + int nr_nodes; +--- a/arch/loongarch/kernel/setup.c ++++ b/arch/loongarch/kernel/setup.c +@@ -55,6 +55,7 @@ + #define SMBIOS_FREQHIGH_OFFSET 0x17 + #define SMBIOS_FREQLOW_MASK 0xFF + #define SMBIOS_CORE_PACKAGE_OFFSET 0x23 ++#define SMBIOS_THREAD_PACKAGE_OFFSET 0x25 + #define LOONGSON_EFI_ENABLE (1 << 3) + + unsigned long fw_arg0, fw_arg1, fw_arg2; +@@ -125,7 +126,7 @@ static void __init parse_cpu_table(const + cpu_clock_freq = freq_temp * 1000000; + + loongson_sysconf.cpuname = (void *)dmi_string_parse(dm, dmi_data[16]); +- loongson_sysconf.cores_per_package = *(dmi_data + SMBIOS_CORE_PACKAGE_OFFSET); ++ loongson_sysconf.cores_per_package = *(dmi_data + SMBIOS_THREAD_PACKAGE_OFFSET); + + pr_info("CpuClock = %llu\n", cpu_clock_freq); + } diff --git a/queue-6.11/loongarch-make-kasan-usable-for-variable-cpu_vabits.patch b/queue-6.11/loongarch-make-kasan-usable-for-variable-cpu_vabits.patch new file mode 100644 index 00000000000..ef86cfd6874 --- /dev/null +++ b/queue-6.11/loongarch-make-kasan-usable-for-variable-cpu_vabits.patch @@ -0,0 +1,36 @@ +From 3c252263be801f937f56b4bcd8e8e2b5307c1ce5 Mon Sep 17 00:00:00 2001 +From: Huacai Chen +Date: Wed, 23 Oct 2024 22:15:30 +0800 +Subject: LoongArch: Make KASAN usable for variable cpu_vabits + +From: Huacai Chen + +commit 3c252263be801f937f56b4bcd8e8e2b5307c1ce5 upstream. + +Currently, KASAN on LoongArch assume the CPU VA bits is 48, which is +true for Loongson-3 series, but not for Loongson-2 series (only 40 or +lower), this patch fix that issue and make KASAN usable for variable +cpu_vabits. + +Solution is very simple: Just define XRANGE_SHADOW_SHIFT which means +valid address length from VA_BITS to min(cpu_vabits, VA_BITS). + +Cc: stable@vger.kernel.org +Signed-off-by: Kanglong Wang +Signed-off-by: Huacai Chen +Signed-off-by: Greg Kroah-Hartman +--- + arch/loongarch/include/asm/kasan.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/loongarch/include/asm/kasan.h ++++ b/arch/loongarch/include/asm/kasan.h +@@ -16,7 +16,7 @@ + #define XRANGE_SHIFT (48) + + /* Valid address length */ +-#define XRANGE_SHADOW_SHIFT (PGDIR_SHIFT + PAGE_SHIFT - 3) ++#define XRANGE_SHADOW_SHIFT min(cpu_vabits, VA_BITS) + /* Used for taking out the valid address */ + #define XRANGE_SHADOW_MASK GENMASK_ULL(XRANGE_SHADOW_SHIFT - 1, 0) + /* One segment whole address space size */ diff --git a/queue-6.11/md-raid10-fix-null-ptr-dereference-in-raid10_size.patch b/queue-6.11/md-raid10-fix-null-ptr-dereference-in-raid10_size.patch new file mode 100644 index 00000000000..4694147b4e4 --- /dev/null +++ b/queue-6.11/md-raid10-fix-null-ptr-dereference-in-raid10_size.patch @@ -0,0 +1,47 @@ +From 825711e00117fc686ab89ac36a9a7b252dc349c6 Mon Sep 17 00:00:00 2001 +From: Yu Kuai +Date: Wed, 9 Oct 2024 09:49:14 +0800 +Subject: md/raid10: fix null ptr dereference in raid10_size() + +From: Yu Kuai + +commit 825711e00117fc686ab89ac36a9a7b252dc349c6 upstream. + +In raid10_run() if raid10_set_queue_limits() succeed, the return value +is set to zero, and if following procedures failed raid10_run() will +return zero while mddev->private is still NULL, causing null ptr +dereference in raid10_size(). + +Fix the problem by only overwrite the return value if +raid10_set_queue_limits() failed. + +Fixes: 3d8466ba68d4 ("md/raid10: use the atomic queue limit update APIs") +Cc: stable@vger.kernel.org +Reported-and-tested-by: ValdikSS +Closes: https://lore.kernel.org/all/0dd96820-fe52-4841-bc58-dbf14d6bfcc8@valdikss.org.ru/ +Signed-off-by: Yu Kuai +Reviewed-by: Christoph Hellwig +Link: https://lore.kernel.org/r/20241009014914.1682037-1-yukuai1@huaweicloud.com +Signed-off-by: Song Liu +Signed-off-by: Greg Kroah-Hartman +--- + drivers/md/raid10.c | 7 +++++-- + 1 file changed, 5 insertions(+), 2 deletions(-) + +--- a/drivers/md/raid10.c ++++ b/drivers/md/raid10.c +@@ -4055,9 +4055,12 @@ static int raid10_run(struct mddev *mdde + } + + if (!mddev_is_dm(conf->mddev)) { +- ret = raid10_set_queue_limits(mddev); +- if (ret) ++ int err = raid10_set_queue_limits(mddev); ++ ++ if (err) { ++ ret = err; + goto out_free_conf; ++ } + } + + /* need to check that every block has at least one working mirror */ diff --git a/queue-6.11/nilfs2-fix-kernel-bug-due-to-missing-clearing-of-buffer-delay-flag.patch b/queue-6.11/nilfs2-fix-kernel-bug-due-to-missing-clearing-of-buffer-delay-flag.patch new file mode 100644 index 00000000000..f52a6752a71 --- /dev/null +++ b/queue-6.11/nilfs2-fix-kernel-bug-due-to-missing-clearing-of-buffer-delay-flag.patch @@ -0,0 +1,55 @@ +From 6ed469df0bfbef3e4b44fca954a781919db9f7ab Mon Sep 17 00:00:00 2001 +From: Ryusuke Konishi +Date: Wed, 16 Oct 2024 06:32:07 +0900 +Subject: nilfs2: fix kernel bug due to missing clearing of buffer delay flag + +From: Ryusuke Konishi + +commit 6ed469df0bfbef3e4b44fca954a781919db9f7ab upstream. + +Syzbot reported that after nilfs2 reads a corrupted file system image +and degrades to read-only, the BUG_ON check for the buffer delay flag +in submit_bh_wbc() may fail, causing a kernel bug. + +This is because the buffer delay flag is not cleared when clearing the +buffer state flags to discard a page/folio or a buffer head. So, fix +this. + +This became necessary when the use of nilfs2's own page clear routine +was expanded. This state inconsistency does not occur if the buffer +is written normally by log writing. + +Signed-off-by: Ryusuke Konishi +Link: https://lore.kernel.org/r/20241015213300.7114-1-konishi.ryusuke@gmail.com +Fixes: 8c26c4e2694a ("nilfs2: fix issue with flush kernel thread after remount in RO mode because of driver's internal error or metadata corruption") +Reported-by: syzbot+985ada84bf055a575c07@syzkaller.appspotmail.com +Closes: https://syzkaller.appspot.com/bug?extid=985ada84bf055a575c07 +Cc: stable@vger.kernel.org +Signed-off-by: Christian Brauner +Signed-off-by: Greg Kroah-Hartman +--- + fs/nilfs2/page.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/fs/nilfs2/page.c ++++ b/fs/nilfs2/page.c +@@ -77,7 +77,8 @@ void nilfs_forget_buffer(struct buffer_h + const unsigned long clear_bits = + (BIT(BH_Uptodate) | BIT(BH_Dirty) | BIT(BH_Mapped) | + BIT(BH_Async_Write) | BIT(BH_NILFS_Volatile) | +- BIT(BH_NILFS_Checked) | BIT(BH_NILFS_Redirected)); ++ BIT(BH_NILFS_Checked) | BIT(BH_NILFS_Redirected) | ++ BIT(BH_Delay)); + + lock_buffer(bh); + set_mask_bits(&bh->b_state, clear_bits, 0); +@@ -414,7 +415,8 @@ void nilfs_clear_folio_dirty(struct foli + const unsigned long clear_bits = + (BIT(BH_Uptodate) | BIT(BH_Dirty) | BIT(BH_Mapped) | + BIT(BH_Async_Write) | BIT(BH_NILFS_Volatile) | +- BIT(BH_NILFS_Checked) | BIT(BH_NILFS_Redirected)); ++ BIT(BH_NILFS_Checked) | BIT(BH_NILFS_Redirected) | ++ BIT(BH_Delay)); + + bh = head; + do { diff --git a/queue-6.11/openat2-explicitly-return-e2big-for-usize-page_size.patch b/queue-6.11/openat2-explicitly-return-e2big-for-usize-page_size.patch new file mode 100644 index 00000000000..5a444c360d7 --- /dev/null +++ b/queue-6.11/openat2-explicitly-return-e2big-for-usize-page_size.patch @@ -0,0 +1,35 @@ +From f92f0a1b05698340836229d791b3ffecc71b265a Mon Sep 17 00:00:00 2001 +From: Aleksa Sarai +Date: Thu, 10 Oct 2024 07:40:36 +1100 +Subject: openat2: explicitly return -E2BIG for (usize > PAGE_SIZE) + +From: Aleksa Sarai + +commit f92f0a1b05698340836229d791b3ffecc71b265a upstream. + +While we do currently return -EFAULT in this case, it seems prudent to +follow the behaviour of other syscalls like clone3. It seems quite +unlikely that anyone depends on this error code being EFAULT, but we can +always revert this if it turns out to be an issue. + +Cc: stable@vger.kernel.org # v5.6+ +Fixes: fddb5d430ad9 ("open: introduce openat2(2) syscall") +Signed-off-by: Aleksa Sarai +Link: https://lore.kernel.org/r/20241010-extensible-structs-check_fields-v3-3-d2833dfe6edd@cyphar.com +Signed-off-by: Christian Brauner +Signed-off-by: Greg Kroah-Hartman +--- + fs/open.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/fs/open.c ++++ b/fs/open.c +@@ -1458,6 +1458,8 @@ SYSCALL_DEFINE4(openat2, int, dfd, const + + if (unlikely(usize < OPEN_HOW_SIZE_VER0)) + return -EINVAL; ++ if (unlikely(usize > PAGE_SIZE)) ++ return -E2BIG; + + err = copy_struct_from_user(&tmp, sizeof(tmp), how, usize); + if (err) diff --git a/queue-6.11/series b/queue-6.11/series index 687fff0e42c..6b3f7c7787c 100644 --- a/queue-6.11/series +++ b/queue-6.11/series @@ -199,3 +199,34 @@ cifs-fix-warning-when-destroy-cifs_io_request_pool.patch pci-pwrctl-add-wcn6855-support.patch pci-pwrctl-abandon-qcom-wcn-probe-on-pre-pwrseq-devi.patch cpufreq-cppc-fix-perf_to_khz-khz_to_perf-conversion-.patch +btrfs-qgroup-set-a-more-sane-default-value-for-subtree-drop-threshold.patch +btrfs-clear-force-compress-on-remount-when-compress-mount-option-is-given.patch +btrfs-fix-passing-0-to-err_ptr-in-btrfs_search_dir_index_item.patch +btrfs-reject-ro-rw-reconfiguration-if-there-are-hard-ro-requirements.patch +btrfs-zoned-fix-zone-unusable-accounting-for-freed-reserved-extent.patch +btrfs-fix-read-corruption-due-to-race-with-extent-map-merging.patch +drm-amd-guard-against-bad-data-for-atif-acpi-method.patch +acpi-resource-add-lg-16t90sp-to-irq1_level_low_skip_override.patch +acpi-prm-find-efi_memory_runtime-block-for-prm-handler-and-context.patch +acpi-button-add-dmi-quirk-for-samsung-galaxy-book2-to-fix-initial-lid-detection-issue.patch +nilfs2-fix-kernel-bug-due-to-missing-clearing-of-buffer-delay-flag.patch +fs-don-t-try-and-remove-empty-rbtree-node.patch +xfs-don-t-fail-repairs-on-metadata-files-with-no-attr-fork.patch +openat2-explicitly-return-e2big-for-usize-page_size.patch +kvm-nsvm-ignore-ncr3-when-loading-pdptes-from-memory.patch +kvm-arm64-unregister-redistributor-for-failed-vcpu-creation.patch +kvm-arm64-fix-shift-out-of-bounds-bug.patch +kvm-arm64-don-t-eagerly-teardown-the-vgic-on-init-error.patch +firewire-core-fix-invalid-port-index-for-parent-device.patch +x86-lam-disable-address_masking-in-most-cases.patch +x86-sev-ensure-that-rmp-table-fixups-are-reserved.patch +alsa-hda-tas2781-select-crc32-instead-of-crc32_sarwate.patch +alsa-hda-realtek-add-subwoofer-quirk-for-acer-predator-g9-593.patch +loongarch-get-correct-cores_per_package-for-smt-systems.patch +loongarch-enable-irq-if-do_ale-triggered-in-irq-enabled-context.patch +loongarch-make-kasan-usable-for-variable-cpu_vabits.patch +xfrm-fix-one-more-kernel-infoleak-in-algo-dumping.patch +hv_netvsc-fix-vf-namespace-also-in-synthetic-nic-netdev_register-event.patch +md-raid10-fix-null-ptr-dereference-in-raid10_size.patch +drm-bridge-fix-assignment-of-the-of_node-of-the-parent-to-aux-bridge.patch +drm-amd-display-disable-psr-su-on-parade-08-01-tcon-too.patch diff --git a/queue-6.11/x86-lam-disable-address_masking-in-most-cases.patch b/queue-6.11/x86-lam-disable-address_masking-in-most-cases.patch new file mode 100644 index 00000000000..682ce435aaf --- /dev/null +++ b/queue-6.11/x86-lam-disable-address_masking-in-most-cases.patch @@ -0,0 +1,46 @@ +From 3267cb6d3a174ff83d6287dcd5b0047bbd912452 Mon Sep 17 00:00:00 2001 +From: Pawan Gupta +Date: Tue, 23 Jan 2024 19:55:21 -0800 +Subject: x86/lam: Disable ADDRESS_MASKING in most cases + +From: Pawan Gupta + +commit 3267cb6d3a174ff83d6287dcd5b0047bbd912452 upstream. + +Linear Address Masking (LAM) has a weakness related to transient +execution as described in the SLAM paper[1]. Unless Linear Address +Space Separation (LASS) is enabled this weakness may be exploitable. + +Until kernel adds support for LASS[2], only allow LAM for COMPILE_TEST, +or when speculation mitigations have been disabled at compile time, +otherwise keep LAM disabled. + +There are no processors in market that support LAM yet, so currently +nobody is affected by this issue. + +[1] SLAM: https://download.vusec.net/papers/slam_sp24.pdf +[2] LASS: https://lore.kernel.org/lkml/20230609183632.48706-1-alexander.shishkin@linux.intel.com/ + +[ dhansen: update SPECULATION_MITIGATIONS -> CPU_MITIGATIONS ] + +Signed-off-by: Pawan Gupta +Signed-off-by: Dave Hansen +Reviewed-by: Sohil Mehta +Acked-by: Kirill A. Shutemov +Cc:stable@vger.kernel.org +Link: https://lore.kernel.org/all/5373262886f2783f054256babdf5a98545dc986b.1706068222.git.pawan.kumar.gupta%40linux.intel.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/Kconfig | 1 + + 1 file changed, 1 insertion(+) + +--- a/arch/x86/Kconfig ++++ b/arch/x86/Kconfig +@@ -2260,6 +2260,7 @@ config RANDOMIZE_MEMORY_PHYSICAL_PADDING + config ADDRESS_MASKING + bool "Linear Address Masking support" + depends on X86_64 ++ depends on COMPILE_TEST || !CPU_MITIGATIONS # wait for LASS + help + Linear Address Masking (LAM) modifies the checking that is applied + to 64-bit linear addresses, allowing software to use of the diff --git a/queue-6.11/x86-sev-ensure-that-rmp-table-fixups-are-reserved.patch b/queue-6.11/x86-sev-ensure-that-rmp-table-fixups-are-reserved.patch new file mode 100644 index 00000000000..2960453e3b1 --- /dev/null +++ b/queue-6.11/x86-sev-ensure-that-rmp-table-fixups-are-reserved.patch @@ -0,0 +1,124 @@ +From 88a921aa3c6b006160d6a46a231b8b32227e8196 Mon Sep 17 00:00:00 2001 +From: Ashish Kalra +Date: Thu, 15 Aug 2024 22:16:30 +0000 +Subject: x86/sev: Ensure that RMP table fixups are reserved + +From: Ashish Kalra + +commit 88a921aa3c6b006160d6a46a231b8b32227e8196 upstream. + +The BIOS reserves RMP table memory via e820 reservations. This can still lead +to RMP page faults during kexec if the host tries to access memory within the +same 2MB region. + +Commit + + 400fea4b9651 ("x86/sev: Add callback to apply RMP table fixups for kexec" + +adjusts the e820 reservations for the RMP table so that the entire 2MB range +at the start/end of the RMP table is marked reserved. + +The e820 reservations are then passed to firmware via SNP_INIT where they get +marked HV-Fixed. + +The RMP table fixups are done after the e820 ranges have been added to +memblock, allowing the fixup ranges to still be allocated and used by the +system. + +The problem is that this memory range is now marked reserved in the e820 +tables and during SNP initialization these reserved ranges are marked as +HV-Fixed. This means that the pages cannot be used by an SNP guest, only by +the hypervisor. + +However, the memory management subsystem does not make this distinction and +can allocate one of those pages to an SNP guest. This will ultimately result +in RMPUPDATE failures associated with the guest, causing it to fail to start +or terminate when accessing the HV-Fixed page. + +The issue is captured below with memblock=debug: + + [ 0.000000] SEV-SNP: *** DEBUG: snp_probe_rmptable_info:352 - rmp_base=0x280d4800000, rmp_end=0x28357efffff + ... + [ 0.000000] BIOS-provided physical RAM map: + ... + [ 0.000000] BIOS-e820: [mem 0x00000280d4800000-0x0000028357efffff] reserved + [ 0.000000] BIOS-e820: [mem 0x0000028357f00000-0x0000028357ffffff] usable + ... + ... + [ 0.183593] memblock add: [0x0000028357f00000-0x0000028357ffffff] e820__memblock_setup+0x74/0xb0 + ... + [ 0.203179] MEMBLOCK configuration: + [ 0.207057] memory size = 0x0000027d0d194000 reserved size = 0x0000000009ed2c00 + [ 0.215299] memory.cnt = 0xb + ... + [ 0.311192] memory[0x9] [0x0000028357f00000-0x0000028357ffffff], 0x0000000000100000 bytes flags: 0x0 + ... + ... + [ 0.419110] SEV-SNP: Reserving start/end of RMP table on a 2MB boundary [0x0000028357e00000] + [ 0.428514] e820: update [mem 0x28357e00000-0x28357ffffff] usable ==> reserved + [ 0.428517] e820: update [mem 0x28357e00000-0x28357ffffff] usable ==> reserved + [ 0.428520] e820: update [mem 0x28357e00000-0x28357ffffff] usable ==> reserved + ... + ... + [ 5.604051] MEMBLOCK configuration: + [ 5.607922] memory size = 0x0000027d0d194000 reserved size = 0x0000000011faae02 + [ 5.616163] memory.cnt = 0xe + ... + [ 5.754525] memory[0xc] [0x0000028357f00000-0x0000028357ffffff], 0x0000000000100000 bytes on node 0 flags: 0x0 + ... + ... + [ 10.080295] Early memory node ranges[ 10.168065] + ... + node 0: [mem 0x0000028357f00000-0x0000028357ffffff] + ... + ... + [ 8149.348948] SEV-SNP: RMPUPDATE failed for PFN 28357f7c, pg_level: 1, ret: 2 + +As shown above, the memblock allocations show 1MB after the end of the RMP as +available for allocation, which is what the RMP table fixups have reserved. +This memory range subsequently gets allocated as SNP guest memory, resulting +in an RMPUPDATE failure. + +This can potentially be fixed by not reserving the memory range in the e820 +table, but that causes kexec failures when using the KEXEC_FILE_LOAD syscall. + +The solution is to use memblock_reserve() to mark the memory reserved for the +system, ensuring that it cannot be allocated to an SNP guest. + +Since HV-Fixed memory is still readable/writable by the host, this only ends +up being a problem if the memory in this range requires a page state change, +which generally will only happen when allocating memory in this range to be +used for running SNP guests, which is now possible with the SNP hypervisor +support in kernel 6.11. + +Backporter note: + +Fixes tag points to a 6.9 change but as the last paragraph above explains, +this whole thing can happen after 6.11 received SNP HV support, therefore +backporting to 6.9 is not really necessary. + + [ bp: Massage commit message. ] + +Fixes: 400fea4b9651 ("x86/sev: Add callback to apply RMP table fixups for kexec") +Suggested-by: Thomas Lendacky +Signed-off-by: Ashish Kalra +Signed-off-by: Borislav Petkov (AMD) +Reviewed-by: Tom Lendacky +Cc: # 6.11, see Backporter note above. +Link: https://lore.kernel.org/r/20240815221630.131133-1-Ashish.Kalra@amd.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/virt/svm/sev.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/arch/x86/virt/svm/sev.c ++++ b/arch/x86/virt/svm/sev.c +@@ -173,6 +173,8 @@ static void __init __snp_fixup_e820_tabl + e820__range_update(pa, PMD_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED); + e820__range_update_table(e820_table_kexec, pa, PMD_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED); + e820__range_update_table(e820_table_firmware, pa, PMD_SIZE, E820_TYPE_RAM, E820_TYPE_RESERVED); ++ if (!memblock_is_region_reserved(pa, PMD_SIZE)) ++ memblock_reserve(pa, PMD_SIZE); + } + } + diff --git a/queue-6.11/xfrm-fix-one-more-kernel-infoleak-in-algo-dumping.patch b/queue-6.11/xfrm-fix-one-more-kernel-infoleak-in-algo-dumping.patch new file mode 100644 index 00000000000..d4f2484b67c --- /dev/null +++ b/queue-6.11/xfrm-fix-one-more-kernel-infoleak-in-algo-dumping.patch @@ -0,0 +1,101 @@ +From 6889cd2a93e1e3606b3f6e958aa0924e836de4d2 Mon Sep 17 00:00:00 2001 +From: Petr Vaganov +Date: Tue, 8 Oct 2024 14:02:58 +0500 +Subject: xfrm: fix one more kernel-infoleak in algo dumping + +From: Petr Vaganov + +commit 6889cd2a93e1e3606b3f6e958aa0924e836de4d2 upstream. + +During fuzz testing, the following issue was discovered: + +BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x598/0x2a30 + _copy_to_iter+0x598/0x2a30 + __skb_datagram_iter+0x168/0x1060 + skb_copy_datagram_iter+0x5b/0x220 + netlink_recvmsg+0x362/0x1700 + sock_recvmsg+0x2dc/0x390 + __sys_recvfrom+0x381/0x6d0 + __x64_sys_recvfrom+0x130/0x200 + x64_sys_call+0x32c8/0x3cc0 + do_syscall_64+0xd8/0x1c0 + entry_SYSCALL_64_after_hwframe+0x79/0x81 + +Uninit was stored to memory at: + copy_to_user_state_extra+0xcc1/0x1e00 + dump_one_state+0x28c/0x5f0 + xfrm_state_walk+0x548/0x11e0 + xfrm_dump_sa+0x1e0/0x840 + netlink_dump+0x943/0x1c40 + __netlink_dump_start+0x746/0xdb0 + xfrm_user_rcv_msg+0x429/0xc00 + netlink_rcv_skb+0x613/0x780 + xfrm_netlink_rcv+0x77/0xc0 + netlink_unicast+0xe90/0x1280 + netlink_sendmsg+0x126d/0x1490 + __sock_sendmsg+0x332/0x3d0 + ____sys_sendmsg+0x863/0xc30 + ___sys_sendmsg+0x285/0x3e0 + __x64_sys_sendmsg+0x2d6/0x560 + x64_sys_call+0x1316/0x3cc0 + do_syscall_64+0xd8/0x1c0 + entry_SYSCALL_64_after_hwframe+0x79/0x81 + +Uninit was created at: + __kmalloc+0x571/0xd30 + attach_auth+0x106/0x3e0 + xfrm_add_sa+0x2aa0/0x4230 + xfrm_user_rcv_msg+0x832/0xc00 + netlink_rcv_skb+0x613/0x780 + xfrm_netlink_rcv+0x77/0xc0 + netlink_unicast+0xe90/0x1280 + netlink_sendmsg+0x126d/0x1490 + __sock_sendmsg+0x332/0x3d0 + ____sys_sendmsg+0x863/0xc30 + ___sys_sendmsg+0x285/0x3e0 + __x64_sys_sendmsg+0x2d6/0x560 + x64_sys_call+0x1316/0x3cc0 + do_syscall_64+0xd8/0x1c0 + entry_SYSCALL_64_after_hwframe+0x79/0x81 + +Bytes 328-379 of 732 are uninitialized +Memory access of size 732 starts at ffff88800e18e000 +Data copied to user address 00007ff30f48aff0 + +CPU: 2 PID: 18167 Comm: syz-executor.0 Not tainted 6.8.11 #1 +Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 + +Fixes copying of xfrm algorithms where some random +data of the structure fields can end up in userspace. +Padding in structures may be filled with random (possibly sensitve) +data and should never be given directly to user-space. + +A similar issue was resolved in the commit +8222d5910dae ("xfrm: Zero padding when dumping algos and encap") + +Found by Linux Verification Center (linuxtesting.org) with Syzkaller. + +Fixes: c7a5899eb26e ("xfrm: redact SA secret with lockdown confidentiality") +Cc: stable@vger.kernel.org +Co-developed-by: Boris Tonofa +Signed-off-by: Boris Tonofa +Signed-off-by: Petr Vaganov +Signed-off-by: Steffen Klassert +Signed-off-by: Greg Kroah-Hartman +--- + net/xfrm/xfrm_user.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/net/xfrm/xfrm_user.c ++++ b/net/xfrm/xfrm_user.c +@@ -1102,7 +1102,9 @@ static int copy_to_user_auth(struct xfrm + if (!nla) + return -EMSGSIZE; + ap = nla_data(nla); +- memcpy(ap, auth, sizeof(struct xfrm_algo_auth)); ++ strscpy_pad(ap->alg_name, auth->alg_name, sizeof(ap->alg_name)); ++ ap->alg_key_len = auth->alg_key_len; ++ ap->alg_trunc_len = auth->alg_trunc_len; + if (redact_secret && auth->alg_key_len) + memset(ap->alg_key, 0, (auth->alg_key_len + 7) / 8); + else diff --git a/queue-6.11/xfs-don-t-fail-repairs-on-metadata-files-with-no-attr-fork.patch b/queue-6.11/xfs-don-t-fail-repairs-on-metadata-files-with-no-attr-fork.patch new file mode 100644 index 00000000000..851986813e5 --- /dev/null +++ b/queue-6.11/xfs-don-t-fail-repairs-on-metadata-files-with-no-attr-fork.patch @@ -0,0 +1,39 @@ +From af8512c5277d17aae09be5305daa9118d2fa8881 Mon Sep 17 00:00:00 2001 +From: "Darrick J. Wong" +Date: Thu, 17 Oct 2024 11:58:10 -0700 +Subject: xfs: don't fail repairs on metadata files with no attr fork + +From: Darrick J. Wong + +commit af8512c5277d17aae09be5305daa9118d2fa8881 upstream. + +Fix a minor bug where we fail repairs on metadata files that do not have +attr forks because xrep_metadata_inode_subtype doesn't filter ENOENT. + +Cc: stable@vger.kernel.org # v6.8 +Fixes: 5a8e07e799721b ("xfs: repair the inode core and forks of a metadata inode") +Signed-off-by: Darrick J. Wong +Reviewed-by: Christoph Hellwig +Signed-off-by: Carlos Maiolino +Signed-off-by: Greg Kroah-Hartman +--- + fs/xfs/scrub/repair.c | 8 +++++--- + 1 file changed, 5 insertions(+), 3 deletions(-) + +--- a/fs/xfs/scrub/repair.c ++++ b/fs/xfs/scrub/repair.c +@@ -1084,9 +1084,11 @@ xrep_metadata_inode_forks( + return error; + + /* Make sure the attr fork looks ok before we delete it. */ +- error = xrep_metadata_inode_subtype(sc, XFS_SCRUB_TYPE_BMBTA); +- if (error) +- return error; ++ if (xfs_inode_hasattr(sc->ip)) { ++ error = xrep_metadata_inode_subtype(sc, XFS_SCRUB_TYPE_BMBTA); ++ if (error) ++ return error; ++ } + + /* Clear the reflink flag since metadata never shares. */ + if (xfs_is_reflink_inode(sc->ip)) { -- 2.47.2