From: Greg Kroah-Hartman Date: Sat, 2 Apr 2022 13:10:53 +0000 (+0200) Subject: 5.15-stable patches X-Git-Tag: v5.17.2~175 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=b5c972687096f17e202dc6b6f816194e80aad39c;p=thirdparty%2Fkernel%2Fstable-queue.git 5.15-stable patches added patches: acpi-properties-consistently-return-enoent-if-there-are-no-more-references.patch arm-dts-at91-sama5d2-fix-pmerrloc-resource-size.patch arm-dts-at91-sama7g5-remove-unused-properties-in-i2c-nodes.patch arm-dts-exynos-add-missing-hdmi-supplies-on-smdk5250.patch arm-dts-exynos-add-missing-hdmi-supplies-on-smdk5420.patch arm-dts-exynos-fix-uart3-pins-configuration-in-exynos5250.patch arm64-do-not-defer-reserve_crashkernel-for-platforms-with-no-dma-memory-zones.patch arm64-dts-qcom-sm8250-fix-msi-irq-for-pcie1-and-pcie2.patch arm64-dts-ti-k3-am64-fix-gic-v3-compatible-regs.patch arm64-dts-ti-k3-am65-fix-gic-v3-compatible-regs.patch arm64-dts-ti-k3-j7200-fix-gic-v3-compatible-regs.patch arm64-dts-ti-k3-j721e-fix-gic-v3-compatible-regs.patch arm64-signal-nofpsimd-do-not-allocate-fp-simd-context-when-not-available.patch asoc-sof-intel-fix-null-ptr-dereference-when-enomem.patch bcache-fixup-multiple-threads-crash.patch block-don-t-merge-across-cgroup-boundaries-if-blkcg-is-enabled.patch block-limit-request-dispatch-loop-duration.patch brcmfmac-firmware-allocate-space-for-default-boardrev-in-nvram.patch brcmfmac-pcie-declare-missing-firmware-files-in-pcie.c.patch brcmfmac-pcie-fix-crashes-due-to-early-irqs.patch brcmfmac-pcie-release-firmwares-in-the-brcmf_pcie_setup-error-path.patch brcmfmac-pcie-replace-brcmf_pcie_copy_mem_todev-with-memcpy_toio.patch btrfs-extend-locking-to-all-space_info-members-accesses.patch btrfs-verify-the-tranisd-of-the-to-be-written-dirty-extent-buffer.patch btrfs-zoned-mark-relocation-as-writing.patch can-isotp-sanitize-can-id-checks-in-isotp_bind.patch carl9170-fix-missing-bit-wise-or-operator-for-tx_params.patch coredump-also-dump-first-pages-of-non-executable-elf-libraries.patch crypto-rsa-pkcs1pad-correctly-get-hash-from-source-scatterlist.patch crypto-rsa-pkcs1pad-fix-buffer-overread-in-pkcs1pad_verify_complete.patch crypto-rsa-pkcs1pad-only-allow-with-rsa.patch crypto-rsa-pkcs1pad-restore-signature-length-check.patch dec-limit-pmax-memory-probing-to-r3k-systems.patch dm-fix-double-accounting-of-flush-with-data.patch dm-fix-use-after-free-in-dm_cleanup_zoned_dev.patch dm-integrity-set-journal-entry-unused-when-shrinking-device.patch dm-interlock-pending-dm_io-and-dm_wait_for_bios_completion.patch dm-stats-fix-too-short-end-duration_ns-when-using-precise_timestamps.patch drbd-fix-potential-silent-data-corruption.patch drivers-hamradio-6pack-fix-uaf-bug-caused-by-mod_timer.patch drm-edid-check-basic-audio-support-on-cea-extension-block.patch drm-fb-helper-mark-screen-buffers-in-system-memory-with-fbinfo_virtfb.patch drm-i915-gem-add-missing-boundary-check-in-vm_access.patch drm-i915-opregion-check-port-number-bounds-for-swsci-display-power-state.patch drm-nouveau-backlight-fix-lvds-backlight-detection-on-some-laptops.patch drm-nouveau-backlight-just-set-all-backlight-types-as-raw.patch drm-simpledrm-add-panel-orientation-property-on-non-upright-mounted-lcd-panels.patch drm-syncobj-flatten-dma_fence_chains-on-transfer.patch exec-force-single-empty-string-when-argv-is-empty.patch ext4-fix-ext4_fc_stats-trace-point.patch ext4-fix-fs-corruption-when-tring-to-remove-a-non-empty-directory-with-io-error.patch ext4-make-mb_optimize_scan-performance-mount-option-work-with-extents.patch fbdev-hot-unplug-firmware-fb-devices-on-forced-removal.patch landlock-use-square-brackets-around-landlock-ruleset.patch lib-raid6-test-fix-multiple-definition-linking-error.patch mailbox-tegra-hsp-flush-whole-channel.patch media-davinci-vpif-fix-unbalanced-runtime-pm-enable.patch media-davinci-vpif-fix-unbalanced-runtime-pm-get.patch media-gpio-ir-tx-fix-transmit-with-long-spaces-on-orange-pi-pc.patch media-venus-hfi_cmds-list-hdr10-property-as-unsupported-for-v1-and-v3.patch media-venus-venc-fix-h264-8x8-transform-control.patch mgag200-fix-memmapsl-configuration-in-gctl6-register.patch mm-hwpoison-unmap-poisoned-page-before-invalidation.patch mm-kmemleak-reset-tag-when-compare-object-pointer.patch mm-madvise-return-correct-bytes-advised-with-process_madvise.patch mm-madvise-skip-unmapped-vma-holes-passed-to-process_madvise.patch pci-fu740-force-2.5gt-s-for-initial-device-probe.patch pci-imx6-allow-to-probe-when-dw_pcie_wait_for_link-fails.patch pci-pciehp-clear-cmd_busy-bit-in-polling-mode.patch pci-xgene-revert-pci-xgene-fix-ib-window-setup.patch pm-domains-fix-sleep-in-atomic-bug-caused-by-genpd_debug_remove.patch powerpc-kvm-fix-kvm_use_magic_page.patch pstore-don-t-use-semaphores-in-always-atomic-context-code.patch revert-acpi-pass-the-same-capabilities-to-the-_osc-regardless-of-the-query-flag.patch revert-mm-madvise-skip-unmapped-vma-holes-passed-to-process_madvise.patch rfkill-make-new-event-layout-opt-in.patch samples-landlock-fix-path_list-memory-leak.patch thermal-int340x-increase-bitmap-size.patch tracing-have-trace-event-string-test-handle-zero-length-strings.patch video-fbdev-atari-atari-2-bpp-ste-palette-bugfix.patch video-fbdev-sm712fb-fix-crash-in-smtcfb_read.patch xtensa-define-update_mmu_tlb-function.patch xtensa-fix-stop_machine_cpuslocked-call-in-patch_text.patch xtensa-fix-xtensa_wsr-always-writing-0.patch --- diff --git a/queue-5.15/acpi-properties-consistently-return-enoent-if-there-are-no-more-references.patch b/queue-5.15/acpi-properties-consistently-return-enoent-if-there-are-no-more-references.patch new file mode 100644 index 00000000000..ad404ee7ff7 --- /dev/null +++ b/queue-5.15/acpi-properties-consistently-return-enoent-if-there-are-no-more-references.patch @@ -0,0 +1,36 @@ +From babc92da5928f81af951663fc436997352e02d3a Mon Sep 17 00:00:00 2001 +From: Sakari Ailus +Date: Fri, 14 Jan 2022 13:24:49 +0200 +Subject: ACPI: properties: Consistently return -ENOENT if there are no more references + +From: Sakari Ailus + +commit babc92da5928f81af951663fc436997352e02d3a upstream. + +__acpi_node_get_property_reference() is documented to return -ENOENT if +the caller requests a property reference at an index that does not exist, +not -EINVAL which it actually does. + +Fix this by returning -ENOENT consistenly, independently of whether the +property value is a plain reference or a package. + +Fixes: c343bc2ce2c6 ("ACPI: properties: Align return codes of __acpi_node_get_property_reference()") +Cc: 4.14+ # 4.14+ +Signed-off-by: Sakari Ailus +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + drivers/acpi/property.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/acpi/property.c ++++ b/drivers/acpi/property.c +@@ -685,7 +685,7 @@ int __acpi_node_get_property_reference(c + */ + if (obj->type == ACPI_TYPE_LOCAL_REFERENCE) { + if (index) +- return -EINVAL; ++ return -ENOENT; + + ret = acpi_bus_get_device(obj->reference.handle, &device); + if (ret) diff --git a/queue-5.15/arm-dts-at91-sama5d2-fix-pmerrloc-resource-size.patch b/queue-5.15/arm-dts-at91-sama5d2-fix-pmerrloc-resource-size.patch new file mode 100644 index 00000000000..c664c26c138 --- /dev/null +++ b/queue-5.15/arm-dts-at91-sama5d2-fix-pmerrloc-resource-size.patch @@ -0,0 +1,36 @@ +From 0fb578a529ac7aca326a9fa475b4a6f58a756fda Mon Sep 17 00:00:00 2001 +From: Tudor Ambarus +Date: Tue, 11 Jan 2022 15:23:01 +0200 +Subject: ARM: dts: at91: sama5d2: Fix PMERRLOC resource size + +From: Tudor Ambarus + +commit 0fb578a529ac7aca326a9fa475b4a6f58a756fda upstream. + +PMERRLOC resource size was set to 0x100, which resulted in HSMC_ERRLOCx +register being truncated to offset x = 21, causing error correction to +fail if more than 22 bit errors and if 24 or 32 bit error correction +was supported. + +Fixes: d9c41bf30cf8 ("ARM: dts: at91: Declare EBI/NAND controllers") +Signed-off-by: Tudor Ambarus +Cc: # 4.13.x +Acked-by: Alexander Dahl +Signed-off-by: Nicolas Ferre +Link: https://lore.kernel.org/r/20220111132301.906712-1-tudor.ambarus@microchip.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm/boot/dts/sama5d2.dtsi | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/arm/boot/dts/sama5d2.dtsi ++++ b/arch/arm/boot/dts/sama5d2.dtsi +@@ -413,7 +413,7 @@ + pmecc: ecc-engine@f8014070 { + compatible = "atmel,sama5d2-pmecc"; + reg = <0xf8014070 0x490>, +- <0xf8014500 0x100>; ++ <0xf8014500 0x200>; + }; + }; + diff --git a/queue-5.15/arm-dts-at91-sama7g5-remove-unused-properties-in-i2c-nodes.patch b/queue-5.15/arm-dts-at91-sama7g5-remove-unused-properties-in-i2c-nodes.patch new file mode 100644 index 00000000000..1d9112bd7d0 --- /dev/null +++ b/queue-5.15/arm-dts-at91-sama7g5-remove-unused-properties-in-i2c-nodes.patch @@ -0,0 +1,53 @@ +From cbb92a7717d2e1c512b7e81c6b22c7298b58a881 Mon Sep 17 00:00:00 2001 +From: Tudor Ambarus +Date: Wed, 2 Mar 2022 18:18:54 +0200 +Subject: ARM: dts: at91: sama7g5: Remove unused properties in i2c nodes + +From: Tudor Ambarus + +commit cbb92a7717d2e1c512b7e81c6b22c7298b58a881 upstream. + +The "atmel,use-dma-rx", "atmel,use-dma-rx" dt properties are not used by +the i2c-at91 driver, nor they are defined in the bindings file, thus remove +them. + +Cc: stable@vger.kernel.org +Fixes: 7540629e2fc7 ("ARM: dts: at91: add sama7g5 SoC DT and sama7g5-ek") +Signed-off-by: Tudor Ambarus +Reviewed-by: Eugen Hristev +Signed-off-by: Nicolas Ferre +Link: https://lore.kernel.org/r/20220302161854.32177-1-tudor.ambarus@microchip.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm/boot/dts/sama7g5.dtsi | 6 ------ + 1 file changed, 6 deletions(-) + +--- a/arch/arm/boot/dts/sama7g5.dtsi ++++ b/arch/arm/boot/dts/sama7g5.dtsi +@@ -319,8 +319,6 @@ + dmas = <&dma0 AT91_XDMAC_DT_PERID(7)>, + <&dma0 AT91_XDMAC_DT_PERID(8)>; + dma-names = "rx", "tx"; +- atmel,use-dma-rx; +- atmel,use-dma-tx; + status = "disabled"; + }; + }; +@@ -485,8 +483,6 @@ + dmas = <&dma0 AT91_XDMAC_DT_PERID(21)>, + <&dma0 AT91_XDMAC_DT_PERID(22)>; + dma-names = "rx", "tx"; +- atmel,use-dma-rx; +- atmel,use-dma-tx; + status = "disabled"; + }; + }; +@@ -511,8 +507,6 @@ + dmas = <&dma0 AT91_XDMAC_DT_PERID(23)>, + <&dma0 AT91_XDMAC_DT_PERID(24)>; + dma-names = "rx", "tx"; +- atmel,use-dma-rx; +- atmel,use-dma-tx; + status = "disabled"; + }; + }; diff --git a/queue-5.15/arm-dts-exynos-add-missing-hdmi-supplies-on-smdk5250.patch b/queue-5.15/arm-dts-exynos-add-missing-hdmi-supplies-on-smdk5250.patch new file mode 100644 index 00000000000..5fd8b30a9bd --- /dev/null +++ b/queue-5.15/arm-dts-exynos-add-missing-hdmi-supplies-on-smdk5250.patch @@ -0,0 +1,34 @@ +From 60a9914cb2061ba612a3f14f6ad329912b486360 Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Tue, 8 Feb 2022 18:18:14 +0100 +Subject: ARM: dts: exynos: add missing HDMI supplies on SMDK5250 + +From: Krzysztof Kozlowski + +commit 60a9914cb2061ba612a3f14f6ad329912b486360 upstream. + +Add required VDD supplies to HDMI block on SMDK5250. Without them, the +HDMI driver won't probe. Because of lack of schematics, use same +supplies as on Arndale 5250 board (voltage matches). + +Cc: # v3.15+ +Signed-off-by: Krzysztof Kozlowski +Reviewed-by: Alim Akhtar +Link: https://lore.kernel.org/r/20220208171823.226211-2-krzysztof.kozlowski@canonical.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm/boot/dts/exynos5250-smdk5250.dts | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts ++++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts +@@ -118,6 +118,9 @@ + status = "okay"; + ddc = <&i2c_2>; + hpd-gpios = <&gpx3 7 GPIO_ACTIVE_HIGH>; ++ vdd-supply = <&ldo8_reg>; ++ vdd_osc-supply = <&ldo10_reg>; ++ vdd_pll-supply = <&ldo8_reg>; + }; + + &i2c_0 { diff --git a/queue-5.15/arm-dts-exynos-add-missing-hdmi-supplies-on-smdk5420.patch b/queue-5.15/arm-dts-exynos-add-missing-hdmi-supplies-on-smdk5420.patch new file mode 100644 index 00000000000..e19f0851a74 --- /dev/null +++ b/queue-5.15/arm-dts-exynos-add-missing-hdmi-supplies-on-smdk5420.patch @@ -0,0 +1,34 @@ +From 453a24ded415f7fce0499c6b0a2c7b28f84911f2 Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Tue, 8 Feb 2022 18:18:15 +0100 +Subject: ARM: dts: exynos: add missing HDMI supplies on SMDK5420 + +From: Krzysztof Kozlowski + +commit 453a24ded415f7fce0499c6b0a2c7b28f84911f2 upstream. + +Add required VDD supplies to HDMI block on SMDK5420. Without them, the +HDMI driver won't probe. Because of lack of schematics, use same +supplies as on Arndale Octa and Odroid XU3 boards (voltage matches). + +Cc: # v3.15+ +Signed-off-by: Krzysztof Kozlowski +Reviewed-by: Alim Akhtar +Link: https://lore.kernel.org/r/20220208171823.226211-3-krzysztof.kozlowski@canonical.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm/boot/dts/exynos5420-smdk5420.dts | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts ++++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts +@@ -124,6 +124,9 @@ + hpd-gpios = <&gpx3 7 GPIO_ACTIVE_HIGH>; + pinctrl-names = "default"; + pinctrl-0 = <&hdmi_hpd_irq>; ++ vdd-supply = <&ldo6_reg>; ++ vdd_osc-supply = <&ldo7_reg>; ++ vdd_pll-supply = <&ldo6_reg>; + }; + + &hsi2c_4 { diff --git a/queue-5.15/arm-dts-exynos-fix-uart3-pins-configuration-in-exynos5250.patch b/queue-5.15/arm-dts-exynos-fix-uart3-pins-configuration-in-exynos5250.patch new file mode 100644 index 00000000000..e224f38a7c0 --- /dev/null +++ b/queue-5.15/arm-dts-exynos-fix-uart3-pins-configuration-in-exynos5250.patch @@ -0,0 +1,34 @@ +From 372d7027fed43c8570018e124cf78b89523a1f8e Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Thu, 30 Dec 2021 20:53:23 +0100 +Subject: ARM: dts: exynos: fix UART3 pins configuration in Exynos5250 + +From: Krzysztof Kozlowski + +commit 372d7027fed43c8570018e124cf78b89523a1f8e upstream. + +The gpa1-4 pin was put twice in UART3 pin configuration of Exynos5250, +instead of proper pin gpa1-5. + +Fixes: f8bfe2b050f3 ("ARM: dts: add pin state information in client nodes for Exynos5 platforms") +Cc: +Signed-off-by: Krzysztof Kozlowski +Tested-by: Marek Szyprowski +Reviewed-by: Alim Akhtar +Link: https://lore.kernel.org/r/20211230195325.328220-1-krzysztof.kozlowski@canonical.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm/boot/dts/exynos5250-pinctrl.dtsi | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/arm/boot/dts/exynos5250-pinctrl.dtsi ++++ b/arch/arm/boot/dts/exynos5250-pinctrl.dtsi +@@ -260,7 +260,7 @@ + }; + + uart3_data: uart3-data { +- samsung,pins = "gpa1-4", "gpa1-4"; ++ samsung,pins = "gpa1-4", "gpa1-5"; + samsung,pin-function = ; + samsung,pin-pud = ; + samsung,pin-drv = ; diff --git a/queue-5.15/arm64-do-not-defer-reserve_crashkernel-for-platforms-with-no-dma-memory-zones.patch b/queue-5.15/arm64-do-not-defer-reserve_crashkernel-for-platforms-with-no-dma-memory-zones.patch new file mode 100644 index 00000000000..85bd76929b3 --- /dev/null +++ b/queue-5.15/arm64-do-not-defer-reserve_crashkernel-for-platforms-with-no-dma-memory-zones.patch @@ -0,0 +1,164 @@ +From 031495635b4668f94e964e037ca93d0d38bfde58 Mon Sep 17 00:00:00 2001 +From: Vijay Balakrishna +Date: Wed, 2 Mar 2022 09:38:09 -0800 +Subject: arm64: Do not defer reserve_crashkernel() for platforms with no DMA memory zones + +From: Vijay Balakrishna + +commit 031495635b4668f94e964e037ca93d0d38bfde58 upstream. + +The following patches resulted in deferring crash kernel reservation to +mem_init(), mainly aimed at platforms with DMA memory zones (no IOMMU), +in particular Raspberry Pi 4. + +commit 1a8e1cef7603 ("arm64: use both ZONE_DMA and ZONE_DMA32") +commit 8424ecdde7df ("arm64: mm: Set ZONE_DMA size based on devicetree's dma-ranges") +commit 0a30c53573b0 ("arm64: mm: Move reserve_crashkernel() into mem_init()") +commit 2687275a5843 ("arm64: Force NO_BLOCK_MAPPINGS if crashkernel reservation is required") + +Above changes introduced boot slowdown due to linear map creation for +all the memory banks with NO_BLOCK_MAPPINGS, see discussion[1]. The proposed +changes restore crash kernel reservation to earlier behavior thus avoids +slow boot, particularly for platforms with IOMMU (no DMA memory zones). + +Tested changes to confirm no ~150ms boot slowdown on our SoC with IOMMU +and 8GB memory. Also tested with ZONE_DMA and/or ZONE_DMA32 configs to confirm +no regression to deferring scheme of crash kernel memory reservation. +In both cases successfully collected kernel crash dump. + +[1] https://lore.kernel.org/all/9436d033-579b-55fa-9b00-6f4b661c2dd7@linux.microsoft.com/ + +Signed-off-by: Vijay Balakrishna +Cc: stable@vger.kernel.org +Reviewed-by: Pasha Tatashin +Link: https://lore.kernel.org/r/1646242689-20744-1-git-send-email-vijayb@linux.microsoft.com +[will: Add #ifdef CONFIG_KEXEC_CORE guards to fix 'crashk_res' references in allnoconfig build] +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/mm/init.c | 36 ++++++++++++++++++++++++++++++++---- + arch/arm64/mm/mmu.c | 32 +++++++++++++++++++++++++++++++- + 2 files changed, 63 insertions(+), 5 deletions(-) + +--- a/arch/arm64/mm/init.c ++++ b/arch/arm64/mm/init.c +@@ -61,8 +61,34 @@ EXPORT_SYMBOL(memstart_addr); + * unless restricted on specific platforms (e.g. 30-bit on Raspberry Pi 4). + * In such case, ZONE_DMA32 covers the rest of the 32-bit addressable memory, + * otherwise it is empty. ++ * ++ * Memory reservation for crash kernel either done early or deferred ++ * depending on DMA memory zones configs (ZONE_DMA) -- ++ * ++ * In absence of ZONE_DMA configs arm64_dma_phys_limit initialized ++ * here instead of max_zone_phys(). This lets early reservation of ++ * crash kernel memory which has a dependency on arm64_dma_phys_limit. ++ * Reserving memory early for crash kernel allows linear creation of block ++ * mappings (greater than page-granularity) for all the memory bank rangs. ++ * In this scheme a comparatively quicker boot is observed. ++ * ++ * If ZONE_DMA configs are defined, crash kernel memory reservation ++ * is delayed until DMA zone memory range size initilazation performed in ++ * zone_sizes_init(). The defer is necessary to steer clear of DMA zone ++ * memory range to avoid overlap allocation. So crash kernel memory boundaries ++ * are not known when mapping all bank memory ranges, which otherwise means ++ * not possible to exclude crash kernel range from creating block mappings ++ * so page-granularity mappings are created for the entire memory range. ++ * Hence a slightly slower boot is observed. ++ * ++ * Note: Page-granularity mapppings are necessary for crash kernel memory ++ * range for shrinking its size via /sys/kernel/kexec_crash_size interface. + */ +-phys_addr_t arm64_dma_phys_limit __ro_after_init; ++#if IS_ENABLED(CONFIG_ZONE_DMA) || IS_ENABLED(CONFIG_ZONE_DMA32) ++phys_addr_t __ro_after_init arm64_dma_phys_limit; ++#else ++const phys_addr_t arm64_dma_phys_limit = PHYS_MASK + 1; ++#endif + + #ifdef CONFIG_KEXEC_CORE + /* +@@ -153,8 +179,6 @@ static void __init zone_sizes_init(unsig + if (!arm64_dma_phys_limit) + arm64_dma_phys_limit = dma32_phys_limit; + #endif +- if (!arm64_dma_phys_limit) +- arm64_dma_phys_limit = PHYS_MASK + 1; + max_zone_pfns[ZONE_NORMAL] = max; + + free_area_init(max_zone_pfns); +@@ -352,6 +376,9 @@ void __init arm64_memblock_init(void) + + early_init_fdt_scan_reserved_mem(); + ++ if (!IS_ENABLED(CONFIG_ZONE_DMA) && !IS_ENABLED(CONFIG_ZONE_DMA32)) ++ reserve_crashkernel(); ++ + high_memory = __va(memblock_end_of_DRAM() - 1) + 1; + } + +@@ -398,7 +425,8 @@ void __init bootmem_init(void) + * request_standard_resources() depends on crashkernel's memory being + * reserved, so do it here. + */ +- reserve_crashkernel(); ++ if (IS_ENABLED(CONFIG_ZONE_DMA) || IS_ENABLED(CONFIG_ZONE_DMA32)) ++ reserve_crashkernel(); + + memblock_dump_all(); + } +--- a/arch/arm64/mm/mmu.c ++++ b/arch/arm64/mm/mmu.c +@@ -516,7 +516,7 @@ static void __init map_mem(pgd_t *pgdp) + */ + BUILD_BUG_ON(pgd_index(direct_map_end - 1) == pgd_index(direct_map_end)); + +- if (can_set_direct_map() || crash_mem_map || IS_ENABLED(CONFIG_KFENCE)) ++ if (can_set_direct_map() || IS_ENABLED(CONFIG_KFENCE)) + flags |= NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS; + + /* +@@ -527,6 +527,17 @@ static void __init map_mem(pgd_t *pgdp) + */ + memblock_mark_nomap(kernel_start, kernel_end - kernel_start); + ++#ifdef CONFIG_KEXEC_CORE ++ if (crash_mem_map) { ++ if (IS_ENABLED(CONFIG_ZONE_DMA) || ++ IS_ENABLED(CONFIG_ZONE_DMA32)) ++ flags |= NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS; ++ else if (crashk_res.end) ++ memblock_mark_nomap(crashk_res.start, ++ resource_size(&crashk_res)); ++ } ++#endif ++ + /* map all the memory banks */ + for_each_mem_range(i, &start, &end) { + if (start >= end) +@@ -553,6 +564,25 @@ static void __init map_mem(pgd_t *pgdp) + __map_memblock(pgdp, kernel_start, kernel_end, + PAGE_KERNEL, NO_CONT_MAPPINGS); + memblock_clear_nomap(kernel_start, kernel_end - kernel_start); ++ ++ /* ++ * Use page-level mappings here so that we can shrink the region ++ * in page granularity and put back unused memory to buddy system ++ * through /sys/kernel/kexec_crash_size interface. ++ */ ++#ifdef CONFIG_KEXEC_CORE ++ if (crash_mem_map && ++ !IS_ENABLED(CONFIG_ZONE_DMA) && !IS_ENABLED(CONFIG_ZONE_DMA32)) { ++ if (crashk_res.end) { ++ __map_memblock(pgdp, crashk_res.start, ++ crashk_res.end + 1, ++ PAGE_KERNEL, ++ NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS); ++ memblock_clear_nomap(crashk_res.start, ++ resource_size(&crashk_res)); ++ } ++ } ++#endif + } + + void mark_rodata_ro(void) diff --git a/queue-5.15/arm64-dts-qcom-sm8250-fix-msi-irq-for-pcie1-and-pcie2.patch b/queue-5.15/arm64-dts-qcom-sm8250-fix-msi-irq-for-pcie1-and-pcie2.patch new file mode 100644 index 00000000000..427ad541550 --- /dev/null +++ b/queue-5.15/arm64-dts-qcom-sm8250-fix-msi-irq-for-pcie1-and-pcie2.patch @@ -0,0 +1,43 @@ +From 1b7101e8124b450f2d6a35591e9cbb478c143ace Mon Sep 17 00:00:00 2001 +From: Manivannan Sadhasivam +Date: Wed, 12 Jan 2022 09:25:56 +0530 +Subject: arm64: dts: qcom: sm8250: Fix MSI IRQ for PCIe1 and PCIe2 + +From: Manivannan Sadhasivam + +commit 1b7101e8124b450f2d6a35591e9cbb478c143ace upstream. + +Fix the MSI IRQ used for PCIe instances 1 and 2. + +Cc: stable@vger.kernel.org +Fixes: e53bdfc00977 ("arm64: dts: qcom: sm8250: Add PCIe support") +Reported-by: Jordan Crouse +Signed-off-by: Manivannan Sadhasivam +Reviewed-by: Dmitry Baryshkov +Signed-off-by: Bjorn Andersson +Link: https://lore.kernel.org/r/20220112035556.5108-1-manivannan.sadhasivam@linaro.org +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/boot/dts/qcom/sm8250.dtsi | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi ++++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi +@@ -1495,7 +1495,7 @@ + ranges = <0x01000000 0x0 0x40200000 0x0 0x40200000 0x0 0x100000>, + <0x02000000 0x0 0x40300000 0x0 0x40300000 0x0 0x1fd00000>; + +- interrupts = ; ++ interrupts = ; + interrupt-names = "msi"; + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 0x7>; +@@ -1601,7 +1601,7 @@ + ranges = <0x01000000 0x0 0x64200000 0x0 0x64200000 0x0 0x100000>, + <0x02000000 0x0 0x64300000 0x0 0x64300000 0x0 0x3d00000>; + +- interrupts = ; ++ interrupts = ; + interrupt-names = "msi"; + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 0x7>; diff --git a/queue-5.15/arm64-dts-ti-k3-am64-fix-gic-v3-compatible-regs.patch b/queue-5.15/arm64-dts-ti-k3-am64-fix-gic-v3-compatible-regs.patch new file mode 100644 index 00000000000..ed13e3beb42 --- /dev/null +++ b/queue-5.15/arm64-dts-ti-k3-am64-fix-gic-v3-compatible-regs.patch @@ -0,0 +1,59 @@ +From de60edf1be3d42d4a1b303b41c7c53b2f865726e Mon Sep 17 00:00:00 2001 +From: Nishanth Menon +Date: Tue, 15 Feb 2022 14:10:07 -0600 +Subject: arm64: dts: ti: k3-am64: Fix gic-v3 compatible regs + +From: Nishanth Menon + +commit de60edf1be3d42d4a1b303b41c7c53b2f865726e upstream. + +Though GIC ARE option is disabled for no GIC-v2 compatibility, +Cortex-A53 is free to implement the CPU interface as long as it +communicates with the GIC using the stream protocol. This requires +that the SoC integration mark out the PERIPHBASE[1] as reserved area +within the SoC. See longer discussion in [2] for further information. + +Update the GIC register map to indicate offsets from PERIPHBASE based +on [3]. Without doing this, systems like kvm will not function with +gic-v2 emulation. + +[1] https://developer.arm.com/documentation/ddi0500/e/system-control/aarch64-register-descriptions/configuration-base-address-register--el1 +[2] https://lore.kernel.org/all/87k0e0tirw.wl-maz@kernel.org/ +[3] https://developer.arm.com/documentation/ddi0500/e/generic-interrupt-controller-cpu-interface/gic-programmers-model/memory-map + +Cc: stable@vger.kernel.org +Fixes: 8abae9389bdb ("arm64: dts: ti: Add support for AM642 SoC") +Reported-by: Marc Zyngier +Signed-off-by: Nishanth Menon +Acked-by: Marc Zyngier +Link: https://lore.kernel.org/r/20220215201008.15235-5-nm@ti.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 5 ++++- + arch/arm64/boot/dts/ti/k3-am64.dtsi | 1 + + 2 files changed, 5 insertions(+), 1 deletion(-) + +--- a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi ++++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi +@@ -59,7 +59,10 @@ + #interrupt-cells = <3>; + interrupt-controller; + reg = <0x00 0x01800000 0x00 0x10000>, /* GICD */ +- <0x00 0x01840000 0x00 0xC0000>; /* GICR */ ++ <0x00 0x01840000 0x00 0xC0000>, /* GICR */ ++ <0x01 0x00000000 0x00 0x2000>, /* GICC */ ++ <0x01 0x00010000 0x00 0x1000>, /* GICH */ ++ <0x01 0x00020000 0x00 0x2000>; /* GICV */ + /* + * vcpumntirq: + * virtual CPU interface maintenance interrupt +--- a/arch/arm64/boot/dts/ti/k3-am64.dtsi ++++ b/arch/arm64/boot/dts/ti/k3-am64.dtsi +@@ -85,6 +85,7 @@ + <0x00 0x68000000 0x00 0x68000000 0x00 0x08000000>, /* PCIe DAT0 */ + <0x00 0x70000000 0x00 0x70000000 0x00 0x00200000>, /* OC SRAM */ + <0x00 0x78000000 0x00 0x78000000 0x00 0x00800000>, /* Main R5FSS */ ++ <0x01 0x00000000 0x01 0x00000000 0x00 0x00310000>, /* A53 PERIPHBASE */ + <0x06 0x00000000 0x06 0x00000000 0x01 0x00000000>, /* PCIe DAT1 */ + <0x05 0x00000000 0x05 0x00000000 0x01 0x00000000>, /* FSS0 DAT3 */ + diff --git a/queue-5.15/arm64-dts-ti-k3-am65-fix-gic-v3-compatible-regs.patch b/queue-5.15/arm64-dts-ti-k3-am65-fix-gic-v3-compatible-regs.patch new file mode 100644 index 00000000000..a11b09f7e3c --- /dev/null +++ b/queue-5.15/arm64-dts-ti-k3-am65-fix-gic-v3-compatible-regs.patch @@ -0,0 +1,59 @@ +From 8cae268b70f387ff9e697ccd62fb2384079124e7 Mon Sep 17 00:00:00 2001 +From: Nishanth Menon +Date: Tue, 15 Feb 2022 14:10:04 -0600 +Subject: arm64: dts: ti: k3-am65: Fix gic-v3 compatible regs + +From: Nishanth Menon + +commit 8cae268b70f387ff9e697ccd62fb2384079124e7 upstream. + +Though GIC ARE option is disabled for no GIC-v2 compatibility, +Cortex-A53 is free to implement the CPU interface as long as it +communicates with the GIC using the stream protocol. This requires +that the SoC integration mark out the PERIPHBASE[1] as reserved area +within the SoC. See longer discussion in [2] for further information. + +Update the GIC register map to indicate offsets from PERIPHBASE based +on [3]. Without doing this, systems like kvm will not function with +gic-v2 emulation. + +[1] https://developer.arm.com/documentation/ddi0500/e/system-control/aarch64-register-descriptions/configuration-base-address-register--el1 +[2] https://lore.kernel.org/all/87k0e0tirw.wl-maz@kernel.org/ +[3] https://developer.arm.com/documentation/ddi0500/e/generic-interrupt-controller-cpu-interface/gic-programmers-model/memory-map + +Cc: stable@vger.kernel.org # 5.10+ +Fixes: ea47eed33a3f ("arm64: dts: ti: Add Support for AM654 SoC") +Reported-by: Marc Zyngier +Signed-off-by: Nishanth Menon +Acked-by: Marc Zyngier +Link: https://lore.kernel.org/r/20220215201008.15235-2-nm@ti.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 5 ++++- + arch/arm64/boot/dts/ti/k3-am65.dtsi | 1 + + 2 files changed, 5 insertions(+), 1 deletion(-) + +--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi ++++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi +@@ -35,7 +35,10 @@ + #interrupt-cells = <3>; + interrupt-controller; + reg = <0x00 0x01800000 0x00 0x10000>, /* GICD */ +- <0x00 0x01880000 0x00 0x90000>; /* GICR */ ++ <0x00 0x01880000 0x00 0x90000>, /* GICR */ ++ <0x00 0x6f000000 0x00 0x2000>, /* GICC */ ++ <0x00 0x6f010000 0x00 0x1000>, /* GICH */ ++ <0x00 0x6f020000 0x00 0x2000>; /* GICV */ + /* + * vcpumntirq: + * virtual CPU interface maintenance interrupt +--- a/arch/arm64/boot/dts/ti/k3-am65.dtsi ++++ b/arch/arm64/boot/dts/ti/k3-am65.dtsi +@@ -84,6 +84,7 @@ + <0x00 0x46000000 0x00 0x46000000 0x00 0x00200000>, + <0x00 0x47000000 0x00 0x47000000 0x00 0x00068400>, + <0x00 0x50000000 0x00 0x50000000 0x00 0x8000000>, ++ <0x00 0x6f000000 0x00 0x6f000000 0x00 0x00310000>, /* A53 PERIPHBASE */ + <0x00 0x70000000 0x00 0x70000000 0x00 0x200000>, + <0x05 0x00000000 0x05 0x00000000 0x01 0x0000000>, + <0x07 0x00000000 0x07 0x00000000 0x01 0x0000000>; diff --git a/queue-5.15/arm64-dts-ti-k3-j7200-fix-gic-v3-compatible-regs.patch b/queue-5.15/arm64-dts-ti-k3-j7200-fix-gic-v3-compatible-regs.patch new file mode 100644 index 00000000000..8564ad23639 --- /dev/null +++ b/queue-5.15/arm64-dts-ti-k3-j7200-fix-gic-v3-compatible-regs.patch @@ -0,0 +1,59 @@ +From 1a307cc299430dd7139d351a3b8941f493dfa885 Mon Sep 17 00:00:00 2001 +From: Nishanth Menon +Date: Tue, 15 Feb 2022 14:10:06 -0600 +Subject: arm64: dts: ti: k3-j7200: Fix gic-v3 compatible regs + +From: Nishanth Menon + +commit 1a307cc299430dd7139d351a3b8941f493dfa885 upstream. + +Though GIC ARE option is disabled for no GIC-v2 compatibility, +Cortex-A72 is free to implement the CPU interface as long as it +communicates with the GIC using the stream protocol. This requires +that the SoC integration mark out the PERIPHBASE[1] as reserved area +within the SoC. See longer discussion in [2] for further information. + +Update the GIC register map to indicate offsets from PERIPHBASE based +on [3]. Without doing this, systems like kvm will not function with +gic-v2 emulation. + +[1] https://developer.arm.com/documentation/100095/0002/system-control/aarch64-register-descriptions/configuration-base-address-register--el1 +[2] https://lore.kernel.org/all/87k0e0tirw.wl-maz@kernel.org/ +[3] https://developer.arm.com/documentation/100095/0002/way1382452674438 + +Cc: stable@vger.kernel.org +Fixes: d361ed88455f ("arm64: dts: ti: Add support for J7200 SoC") +Reported-by: Marc Zyngier +Signed-off-by: Nishanth Menon +Acked-by: Marc Zyngier +Link: https://lore.kernel.org/r/20220215201008.15235-4-nm@ti.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 5 ++++- + arch/arm64/boot/dts/ti/k3-j7200.dtsi | 1 + + 2 files changed, 5 insertions(+), 1 deletion(-) + +--- a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi ++++ b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi +@@ -54,7 +54,10 @@ + #interrupt-cells = <3>; + interrupt-controller; + reg = <0x00 0x01800000 0x00 0x10000>, /* GICD */ +- <0x00 0x01900000 0x00 0x100000>; /* GICR */ ++ <0x00 0x01900000 0x00 0x100000>, /* GICR */ ++ <0x00 0x6f000000 0x00 0x2000>, /* GICC */ ++ <0x00 0x6f010000 0x00 0x1000>, /* GICH */ ++ <0x00 0x6f020000 0x00 0x2000>; /* GICV */ + + /* vcpumntirq: virtual CPU interface maintenance interrupt */ + interrupts = ; +--- a/arch/arm64/boot/dts/ti/k3-j7200.dtsi ++++ b/arch/arm64/boot/dts/ti/k3-j7200.dtsi +@@ -127,6 +127,7 @@ + <0x00 0x00a40000 0x00 0x00a40000 0x00 0x00000800>, /* timesync router */ + <0x00 0x01000000 0x00 0x01000000 0x00 0x0d000000>, /* Most peripherals */ + <0x00 0x30000000 0x00 0x30000000 0x00 0x0c400000>, /* MAIN NAVSS */ ++ <0x00 0x6f000000 0x00 0x6f000000 0x00 0x00310000>, /* A72 PERIPHBASE */ + <0x00 0x70000000 0x00 0x70000000 0x00 0x00800000>, /* MSMC RAM */ + <0x00 0x18000000 0x00 0x18000000 0x00 0x08000000>, /* PCIe1 DAT0 */ + <0x41 0x00000000 0x41 0x00000000 0x01 0x00000000>, /* PCIe1 DAT1 */ diff --git a/queue-5.15/arm64-dts-ti-k3-j721e-fix-gic-v3-compatible-regs.patch b/queue-5.15/arm64-dts-ti-k3-j721e-fix-gic-v3-compatible-regs.patch new file mode 100644 index 00000000000..36543ec0a4d --- /dev/null +++ b/queue-5.15/arm64-dts-ti-k3-j721e-fix-gic-v3-compatible-regs.patch @@ -0,0 +1,59 @@ +From a06ed27f3bc63ab9e10007dc0118d910908eb045 Mon Sep 17 00:00:00 2001 +From: Nishanth Menon +Date: Tue, 15 Feb 2022 14:10:05 -0600 +Subject: arm64: dts: ti: k3-j721e: Fix gic-v3 compatible regs + +From: Nishanth Menon + +commit a06ed27f3bc63ab9e10007dc0118d910908eb045 upstream. + +Though GIC ARE option is disabled for no GIC-v2 compatibility, +Cortex-A72 is free to implement the CPU interface as long as it +communicates with the GIC using the stream protocol. This requires +that the SoC integration mark out the PERIPHBASE[1] as reserved area +within the SoC. See longer discussion in [2] for further information. + +Update the GIC register map to indicate offsets from PERIPHBASE based +on [3]. Without doing this, systems like kvm will not function with +gic-v2 emulation. + +[1] https://developer.arm.com/documentation/100095/0002/system-control/aarch64-register-descriptions/configuration-base-address-register--el1 +[2] https://lore.kernel.org/all/87k0e0tirw.wl-maz@kernel.org/ +[3] https://developer.arm.com/documentation/100095/0002/way1382452674438 + +Cc: stable@vger.kernel.org # 5.10+ +Fixes: 2d87061e70de ("arm64: dts: ti: Add Support for J721E SoC") +Reported-by: Marc Zyngier +Signed-off-by: Nishanth Menon +Acked-by: Marc Zyngier +Link: https://lore.kernel.org/r/20220215201008.15235-3-nm@ti.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 5 ++++- + arch/arm64/boot/dts/ti/k3-j721e.dtsi | 1 + + 2 files changed, 5 insertions(+), 1 deletion(-) + +--- a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi ++++ b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi +@@ -76,7 +76,10 @@ + #interrupt-cells = <3>; + interrupt-controller; + reg = <0x00 0x01800000 0x00 0x10000>, /* GICD */ +- <0x00 0x01900000 0x00 0x100000>; /* GICR */ ++ <0x00 0x01900000 0x00 0x100000>, /* GICR */ ++ <0x00 0x6f000000 0x00 0x2000>, /* GICC */ ++ <0x00 0x6f010000 0x00 0x1000>, /* GICH */ ++ <0x00 0x6f020000 0x00 0x2000>; /* GICV */ + + /* vcpumntirq: virtual CPU interface maintenance interrupt */ + interrupts = ; +--- a/arch/arm64/boot/dts/ti/k3-j721e.dtsi ++++ b/arch/arm64/boot/dts/ti/k3-j721e.dtsi +@@ -136,6 +136,7 @@ + <0x00 0x0e000000 0x00 0x0e000000 0x00 0x01800000>, /* PCIe Core*/ + <0x00 0x10000000 0x00 0x10000000 0x00 0x10000000>, /* PCIe DAT */ + <0x00 0x64800000 0x00 0x64800000 0x00 0x00800000>, /* C71 */ ++ <0x00 0x6f000000 0x00 0x6f000000 0x00 0x00310000>, /* A72 PERIPHBASE */ + <0x44 0x00000000 0x44 0x00000000 0x00 0x08000000>, /* PCIe2 DAT */ + <0x44 0x10000000 0x44 0x10000000 0x00 0x08000000>, /* PCIe3 DAT */ + <0x4d 0x80800000 0x4d 0x80800000 0x00 0x00800000>, /* C66_0 */ diff --git a/queue-5.15/arm64-signal-nofpsimd-do-not-allocate-fp-simd-context-when-not-available.patch b/queue-5.15/arm64-signal-nofpsimd-do-not-allocate-fp-simd-context-when-not-available.patch new file mode 100644 index 00000000000..ed1823c828e --- /dev/null +++ b/queue-5.15/arm64-signal-nofpsimd-do-not-allocate-fp-simd-context-when-not-available.patch @@ -0,0 +1,50 @@ +From 0a32c88ddb9af30e8a16d41d7b9b824c27d29459 Mon Sep 17 00:00:00 2001 +From: David Engraf +Date: Fri, 25 Feb 2022 11:40:08 +0100 +Subject: arm64: signal: nofpsimd: Do not allocate fp/simd context when not available + +From: David Engraf + +commit 0a32c88ddb9af30e8a16d41d7b9b824c27d29459 upstream. + +Commit 6d502b6ba1b2 ("arm64: signal: nofpsimd: Handle fp/simd context for +signal frames") introduced saving the fp/simd context for signal handling +only when support is available. But setup_sigframe_layout() always +reserves memory for fp/simd context. The additional memory is not touched +because preserve_fpsimd_context() is not called and thus the magic is +invalid. + +This may lead to an error when parse_user_sigframe() checks the fp/simd +area and does not find a valid magic number. + +Signed-off-by: David Engraf +Reviwed-by: Mark Brown +Fixes: 6d502b6ba1b267b3 ("arm64: signal: nofpsimd: Handle fp/simd context for signal frames") +Cc: # 5.6.x +Reviewed-by: Catalin Marinas +Link: https://lore.kernel.org/r/20220225104008.820289-1-david.engraf@sysgo.com +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/kernel/signal.c | 10 ++++++---- + 1 file changed, 6 insertions(+), 4 deletions(-) + +--- a/arch/arm64/kernel/signal.c ++++ b/arch/arm64/kernel/signal.c +@@ -577,10 +577,12 @@ static int setup_sigframe_layout(struct + { + int err; + +- err = sigframe_alloc(user, &user->fpsimd_offset, +- sizeof(struct fpsimd_context)); +- if (err) +- return err; ++ if (system_supports_fpsimd()) { ++ err = sigframe_alloc(user, &user->fpsimd_offset, ++ sizeof(struct fpsimd_context)); ++ if (err) ++ return err; ++ } + + /* fault information, if valid */ + if (add_all || current->thread.fault_code) { diff --git a/queue-5.15/asoc-sof-intel-fix-null-ptr-dereference-when-enomem.patch b/queue-5.15/asoc-sof-intel-fix-null-ptr-dereference-when-enomem.patch new file mode 100644 index 00000000000..e59cb224f43 --- /dev/null +++ b/queue-5.15/asoc-sof-intel-fix-null-ptr-dereference-when-enomem.patch @@ -0,0 +1,106 @@ +From b7fb0ae09009d076964afe4c1a2bde1ee2bd88a9 Mon Sep 17 00:00:00 2001 +From: Ammar Faizi +Date: Fri, 25 Feb 2022 01:58:36 +0700 +Subject: ASoC: SOF: Intel: Fix NULL ptr dereference when ENOMEM + +From: Ammar Faizi + +commit b7fb0ae09009d076964afe4c1a2bde1ee2bd88a9 upstream. + +Do not call snd_dma_free_pages() when snd_dma_alloc_pages() returns +-ENOMEM because it leads to a NULL pointer dereference bug. + +The dmesg says: + + [ T1387] sof-audio-pci-intel-tgl 0000:00:1f.3: error: memory alloc failed: -12 + [ T1387] BUG: kernel NULL pointer dereference, address: 0000000000000000 + [ T1387] #PF: supervisor read access in kernel mode + [ T1387] #PF: error_code(0x0000) - not-present page + [ T1387] PGD 0 P4D 0 + [ T1387] Oops: 0000 [#1] PREEMPT SMP NOPTI + [ T1387] CPU: 6 PID: 1387 Comm: alsa-sink-HDA A Tainted: G W 5.17.0-rc4-superb-owl-00055-g80d47f5de5e3 + [ T1387] Hardware name: HP HP Laptop 14s-dq2xxx/87FD, BIOS F.15 09/15/2021 + [ T1387] RIP: 0010:dma_free_noncontiguous+0x37/0x80 + [ T1387] Code: [... snip ...] + [ T1387] RSP: 0000:ffffc90002b87770 EFLAGS: 00010246 + [ T1387] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 + [ T1387] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888101db30d0 + [ T1387] RBP: 00000000fffffff4 R08: 0000000000000000 R09: 0000000000000000 + [ T1387] R10: 0000000000000000 R11: ffffc90002b874d0 R12: 0000000000000001 + [ T1387] R13: 0000000000058000 R14: ffff888105260c68 R15: ffff888105260828 + [ T1387] FS: 00007f42e2ffd640(0000) GS:ffff888466b80000(0000) knlGS:0000000000000000 + [ T1387] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 + [ T1387] CR2: 0000000000000000 CR3: 000000014acf0003 CR4: 0000000000770ee0 + [ T1387] PKRU: 55555554 + [ T1387] Call Trace: + [ T1387] + [ T1387] cl_stream_prepare+0x10a/0x120 [snd_sof_intel_hda_common 146addf995b9279ae7f509621078cccbe4f875e1] + [... snip ...] + [ T1387] + +Cc: Daniel Baluta +Cc: Jaroslav Kysela +Cc: Kai Vehmanen +Cc: Keyon Jie +Cc: Liam Girdwood +Cc: Mark Brown +Cc: Rander Wang +Cc: Ranjani Sridharan +Cc: Takashi Iwai +Cc: sound-open-firmware@alsa-project.org +Cc: alsa-devel@alsa-project.org +Cc: linux-kernel@vger.kernel.org +Cc: stable@vger.kernel.org # v5.2+ +Fixes: d16046ffa6de040bf580a64d5f4d0aa18258a854 ("ASoC: SOF: Intel: Add Intel specific HDA firmware loader") +Link: https://lore.kernel.org/lkml/20220224145124.15985-1-ammarfaizi2@gnuweeb.org/ # v1 +Link: https://lore.kernel.org/lkml/20220224180850.34592-1-ammarfaizi2@gnuweeb.org/ # v2 +Link: https://lore.kernel.org/lkml/20220224182818.40301-1-ammarfaizi2@gnuweeb.org/ # v3 +Reviewed-by: Peter Ujfalusi +Reviewed-by: Pierre-Louis Bossart +Signed-off-by: Ammar Faizi +Link: https://lore.kernel.org/r/20220224185836.44907-1-ammarfaizi2@gnuweeb.org +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman +--- + sound/soc/sof/intel/hda-loader.c | 11 ++++++----- + 1 file changed, 6 insertions(+), 5 deletions(-) + +--- a/sound/soc/sof/intel/hda-loader.c ++++ b/sound/soc/sof/intel/hda-loader.c +@@ -48,7 +48,7 @@ static struct hdac_ext_stream *cl_stream + ret = snd_dma_alloc_pages(SNDRV_DMA_TYPE_DEV_SG, &pci->dev, size, dmab); + if (ret < 0) { + dev_err(sdev->dev, "error: memory alloc failed: %d\n", ret); +- goto error; ++ goto out_put; + } + + hstream->period_bytes = 0;/* initialize period_bytes */ +@@ -59,22 +59,23 @@ static struct hdac_ext_stream *cl_stream + ret = hda_dsp_iccmax_stream_hw_params(sdev, dsp_stream, dmab, NULL); + if (ret < 0) { + dev_err(sdev->dev, "error: iccmax stream prepare failed: %d\n", ret); +- goto error; ++ goto out_free; + } + } else { + ret = hda_dsp_stream_hw_params(sdev, dsp_stream, dmab, NULL); + if (ret < 0) { + dev_err(sdev->dev, "error: hdac prepare failed: %d\n", ret); +- goto error; ++ goto out_free; + } + hda_dsp_stream_spib_config(sdev, dsp_stream, HDA_DSP_SPIB_ENABLE, size); + } + + return dsp_stream; + +-error: +- hda_dsp_stream_put(sdev, direction, hstream->stream_tag); ++out_free: + snd_dma_free_pages(dmab); ++out_put: ++ hda_dsp_stream_put(sdev, direction, hstream->stream_tag); + return ERR_PTR(ret); + } + diff --git a/queue-5.15/bcache-fixup-multiple-threads-crash.patch b/queue-5.15/bcache-fixup-multiple-threads-crash.patch new file mode 100644 index 00000000000..a226a5e0924 --- /dev/null +++ b/queue-5.15/bcache-fixup-multiple-threads-crash.patch @@ -0,0 +1,67 @@ +From 887554ab96588de2917b6c8c73e552da082e5368 Mon Sep 17 00:00:00 2001 +From: Mingzhe Zou +Date: Fri, 11 Feb 2022 14:39:15 +0800 +Subject: bcache: fixup multiple threads crash + +From: Mingzhe Zou + +commit 887554ab96588de2917b6c8c73e552da082e5368 upstream. + +When multiple threads to check btree nodes in parallel, the main +thread wait for all threads to stop or CACHE_SET_IO_DISABLE flag: + +wait_event_interruptible(check_state->wait, + atomic_read(&check_state->started) == 0 || + test_bit(CACHE_SET_IO_DISABLE, &c->flags)); + +However, the bch_btree_node_read and bch_btree_node_read_done +maybe call bch_cache_set_error, then the CACHE_SET_IO_DISABLE +will be set. If the flag already set, the main thread return +error. At the same time, maybe some threads still running and +read NULL pointer, the kernel will crash. + +This patch change the event wait condition, the main thread must +wait for all threads to stop. + +Fixes: 8e7102273f597 ("bcache: make bch_btree_check() to be multithreaded") +Signed-off-by: Mingzhe Zou +Cc: stable@vger.kernel.org # v5.7+ +Signed-off-by: Coly Li +Signed-off-by: Greg Kroah-Hartman +--- + drivers/md/bcache/btree.c | 6 ++++-- + drivers/md/bcache/writeback.c | 6 ++++-- + 2 files changed, 8 insertions(+), 4 deletions(-) + +--- a/drivers/md/bcache/btree.c ++++ b/drivers/md/bcache/btree.c +@@ -2060,9 +2060,11 @@ int bch_btree_check(struct cache_set *c) + } + } + ++ /* ++ * Must wait for all threads to stop. ++ */ + wait_event_interruptible(check_state->wait, +- atomic_read(&check_state->started) == 0 || +- test_bit(CACHE_SET_IO_DISABLE, &c->flags)); ++ atomic_read(&check_state->started) == 0); + + for (i = 0; i < check_state->total_threads; i++) { + if (check_state->infos[i].result) { +--- a/drivers/md/bcache/writeback.c ++++ b/drivers/md/bcache/writeback.c +@@ -998,9 +998,11 @@ void bch_sectors_dirty_init(struct bcach + } + } + ++ /* ++ * Must wait for all threads to stop. ++ */ + wait_event_interruptible(state->wait, +- atomic_read(&state->started) == 0 || +- test_bit(CACHE_SET_IO_DISABLE, &c->flags)); ++ atomic_read(&state->started) == 0); + + out: + kfree(state); diff --git a/queue-5.15/block-don-t-merge-across-cgroup-boundaries-if-blkcg-is-enabled.patch b/queue-5.15/block-don-t-merge-across-cgroup-boundaries-if-blkcg-is-enabled.patch new file mode 100644 index 00000000000..19b3b996ddd --- /dev/null +++ b/queue-5.15/block-don-t-merge-across-cgroup-boundaries-if-blkcg-is-enabled.patch @@ -0,0 +1,112 @@ +From 6b2b04590b51aa4cf395fcd185ce439cab5961dc Mon Sep 17 00:00:00 2001 +From: Tejun Heo +Date: Mon, 14 Mar 2022 14:30:11 -1000 +Subject: block: don't merge across cgroup boundaries if blkcg is enabled + +From: Tejun Heo + +commit 6b2b04590b51aa4cf395fcd185ce439cab5961dc upstream. + +blk-iocost and iolatency are cgroup aware rq-qos policies but they didn't +disable merges across different cgroups. This obviously can lead to +accounting and control errors but more importantly to priority inversions - +e.g. an IO which belongs to a higher priority cgroup or IO class may end up +getting throttled incorrectly because it gets merged to an IO issued from a +low priority cgroup. + +Fix it by adding blk_cgroup_mergeable() which is called from merge paths and +rejects cross-cgroup and cross-issue_as_root merges. + +Signed-off-by: Tejun Heo +Fixes: d70675121546 ("block: introduce blk-iolatency io controller") +Cc: stable@vger.kernel.org # v4.19+ +Cc: Josef Bacik +Link: https://lore.kernel.org/r/Yi/eE/6zFNyWJ+qd@slm.duckdns.org +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + block/blk-merge.c | 11 +++++++++++ + include/linux/blk-cgroup.h | 17 +++++++++++++++++ + 2 files changed, 28 insertions(+) + +--- a/block/blk-merge.c ++++ b/block/blk-merge.c +@@ -7,6 +7,7 @@ + #include + #include + #include ++#include + + #include + +@@ -561,6 +562,9 @@ static inline unsigned int blk_rq_get_ma + static inline int ll_new_hw_segment(struct request *req, struct bio *bio, + unsigned int nr_phys_segs) + { ++ if (!blk_cgroup_mergeable(req, bio)) ++ goto no_merge; ++ + if (blk_integrity_merge_bio(req->q, req, bio) == false) + goto no_merge; + +@@ -657,6 +661,9 @@ static int ll_merge_requests_fn(struct r + if (total_phys_segments > blk_rq_get_max_segments(req)) + return 0; + ++ if (!blk_cgroup_mergeable(req, next->bio)) ++ return 0; ++ + if (blk_integrity_merge_rq(q, req, next) == false) + return 0; + +@@ -863,6 +870,10 @@ bool blk_rq_merge_ok(struct request *rq, + if (rq->rq_disk != bio->bi_bdev->bd_disk) + return false; + ++ /* don't merge across cgroup boundaries */ ++ if (!blk_cgroup_mergeable(rq, bio)) ++ return false; ++ + /* only merge integrity protected bio into ditto rq */ + if (blk_integrity_merge_bio(rq->q, rq, bio) == false) + return false; +--- a/include/linux/blk-cgroup.h ++++ b/include/linux/blk-cgroup.h +@@ -24,6 +24,7 @@ + #include + #include + #include ++#include + + /* percpu_counter batch for blkg_[rw]stats, per-cpu drift doesn't matter */ + #define BLKG_STAT_CPU_BATCH (INT_MAX / 2) +@@ -604,6 +605,21 @@ static inline void blkcg_clear_delay(str + atomic_dec(&blkg->blkcg->css.cgroup->congestion_count); + } + ++/** ++ * blk_cgroup_mergeable - Determine whether to allow or disallow merges ++ * @rq: request to merge into ++ * @bio: bio to merge ++ * ++ * @bio and @rq should belong to the same cgroup and their issue_as_root should ++ * match. The latter is necessary as we don't want to throttle e.g. a metadata ++ * update because it happens to be next to a regular IO. ++ */ ++static inline bool blk_cgroup_mergeable(struct request *rq, struct bio *bio) ++{ ++ return rq->bio->bi_blkg == bio->bi_blkg && ++ bio_issue_as_root_blkg(rq->bio) == bio_issue_as_root_blkg(bio); ++} ++ + void blk_cgroup_bio_start(struct bio *bio); + void blkcg_add_delay(struct blkcg_gq *blkg, u64 now, u64 delta); + void blkcg_schedule_throttle(struct request_queue *q, bool use_memdelay); +@@ -659,6 +675,7 @@ static inline void blkg_put(struct blkcg + static inline bool blkcg_punt_bio_submit(struct bio *bio) { return false; } + static inline void blkcg_bio_issue_init(struct bio *bio) { } + static inline void blk_cgroup_bio_start(struct bio *bio) { } ++static inline bool blk_cgroup_mergeable(struct request *rq, struct bio *bio) { return true; } + + #define blk_queue_for_each_rl(rl, q) \ + for ((rl) = &(q)->root_rl; (rl); (rl) = NULL) diff --git a/queue-5.15/block-limit-request-dispatch-loop-duration.patch b/queue-5.15/block-limit-request-dispatch-loop-duration.patch new file mode 100644 index 00000000000..1482c709482 --- /dev/null +++ b/queue-5.15/block-limit-request-dispatch-loop-duration.patch @@ -0,0 +1,85 @@ +From 572299f03afd676dd4e20669cdaf5ed0fe1379d4 Mon Sep 17 00:00:00 2001 +From: Shin'ichiro Kawasaki +Date: Fri, 18 Mar 2022 11:26:41 +0900 +Subject: block: limit request dispatch loop duration + +From: Shin'ichiro Kawasaki + +commit 572299f03afd676dd4e20669cdaf5ed0fe1379d4 upstream. + +When IO requests are made continuously and the target block device +handles requests faster than request arrival, the request dispatch loop +keeps on repeating to dispatch the arriving requests very long time, +more than a minute. Since the loop runs as a workqueue worker task, the +very long loop duration triggers workqueue watchdog timeout and BUG [1]. + +To avoid the very long loop duration, break the loop periodically. When +opportunity to dispatch requests still exists, check need_resched(). If +need_resched() returns true, the dispatch loop already consumed its time +slice, then reschedule the dispatch work and break the loop. With heavy +IO load, need_resched() does not return true for 20~30 seconds. To cover +such case, check time spent in the dispatch loop with jiffies. If more +than 1 second is spent, reschedule the dispatch work and break the loop. + +[1] + +[ 609.691437] BUG: workqueue lockup - pool cpus=10 node=1 flags=0x0 nice=-20 stuck for 35s! +[ 609.701820] Showing busy workqueues and worker pools: +[ 609.707915] workqueue events: flags=0x0 +[ 609.712615] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256 refcnt=2 +[ 609.712626] pending: drm_fb_helper_damage_work [drm_kms_helper] +[ 609.712687] workqueue events_freezable: flags=0x4 +[ 609.732943] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256 refcnt=2 +[ 609.732952] pending: pci_pme_list_scan +[ 609.732968] workqueue events_power_efficient: flags=0x80 +[ 609.751947] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256 refcnt=2 +[ 609.751955] pending: neigh_managed_work +[ 609.752018] workqueue kblockd: flags=0x18 +[ 609.769480] pwq 21: cpus=10 node=1 flags=0x0 nice=-20 active=3/256 refcnt=4 +[ 609.769488] in-flight: 1020:blk_mq_run_work_fn +[ 609.769498] pending: blk_mq_timeout_work, blk_mq_run_work_fn +[ 609.769744] pool 21: cpus=10 node=1 flags=0x0 nice=-20 hung=35s workers=2 idle: 67 +[ 639.899730] BUG: workqueue lockup - pool cpus=10 node=1 flags=0x0 nice=-20 stuck for 66s! +[ 639.909513] Showing busy workqueues and worker pools: +[ 639.915404] workqueue events: flags=0x0 +[ 639.920197] pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/256 refcnt=2 +[ 639.920215] pending: drm_fb_helper_damage_work [drm_kms_helper] +[ 639.920365] workqueue kblockd: flags=0x18 +[ 639.939932] pwq 21: cpus=10 node=1 flags=0x0 nice=-20 active=3/256 refcnt=4 +[ 639.939942] in-flight: 1020:blk_mq_run_work_fn +[ 639.939955] pending: blk_mq_timeout_work, blk_mq_run_work_fn +[ 639.940212] pool 21: cpus=10 node=1 flags=0x0 nice=-20 hung=66s workers=2 idle: 67 + +Fixes: 6e6fcbc27e778 ("blk-mq: support batching dispatch in case of io") +Signed-off-by: Shin'ichiro Kawasaki +Cc: stable@vger.kernel.org # v5.10+ +Link: https://lore.kernel.org/linux-block/20220310091649.zypaem5lkyfadymg@shindev/ +Link: https://lore.kernel.org/r/20220318022641.133484-1-shinichiro.kawasaki@wdc.com +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + block/blk-mq-sched.c | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +--- a/block/blk-mq-sched.c ++++ b/block/blk-mq-sched.c +@@ -208,11 +208,18 @@ static int __blk_mq_do_dispatch_sched(st + + static int blk_mq_do_dispatch_sched(struct blk_mq_hw_ctx *hctx) + { ++ unsigned long end = jiffies + HZ; + int ret; + + do { + ret = __blk_mq_do_dispatch_sched(hctx); +- } while (ret == 1); ++ if (ret != 1) ++ break; ++ if (need_resched() || time_is_before_jiffies(end)) { ++ blk_mq_delay_run_hw_queue(hctx, 0); ++ break; ++ } ++ } while (1); + + return ret; + } diff --git a/queue-5.15/brcmfmac-firmware-allocate-space-for-default-boardrev-in-nvram.patch b/queue-5.15/brcmfmac-firmware-allocate-space-for-default-boardrev-in-nvram.patch new file mode 100644 index 00000000000..b2327479d86 --- /dev/null +++ b/queue-5.15/brcmfmac-firmware-allocate-space-for-default-boardrev-in-nvram.patch @@ -0,0 +1,36 @@ +From d19d8e3ba256f81ea4a27209dbbd1f0a00ef1903 Mon Sep 17 00:00:00 2001 +From: Hector Martin +Date: Tue, 1 Feb 2022 01:07:06 +0900 +Subject: brcmfmac: firmware: Allocate space for default boardrev in nvram + +From: Hector Martin + +commit d19d8e3ba256f81ea4a27209dbbd1f0a00ef1903 upstream. + +If boardrev is missing from the NVRAM we add a default one, but this +might need more space in the output buffer than was allocated. Ensure +we have enough padding for this in the buffer. + +Fixes: 46f2b38a91b0 ("brcmfmac: insert default boardrev in nvram data if missing") +Reviewed-by: Arend van Spriel +Cc: stable@vger.kernel.org +Signed-off-by: Hector Martin +Reviewed-by: Andy Shevchenko +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/20220131160713.245637-3-marcan@marcan.st +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c ++++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c +@@ -207,6 +207,8 @@ static int brcmf_init_nvram_parser(struc + size = BRCMF_FW_MAX_NVRAM_SIZE; + else + size = data_len; ++ /* Add space for properties we may add */ ++ size += strlen(BRCMF_FW_DEFAULT_BOARDREV) + 1; + /* Alloc for extra 0 byte + roundup by 4 + length field */ + size += 1 + 3 + sizeof(u32); + nvp->nvram = kzalloc(size, GFP_KERNEL); diff --git a/queue-5.15/brcmfmac-pcie-declare-missing-firmware-files-in-pcie.c.patch b/queue-5.15/brcmfmac-pcie-declare-missing-firmware-files-in-pcie.c.patch new file mode 100644 index 00000000000..59e2e3769af --- /dev/null +++ b/queue-5.15/brcmfmac-pcie-declare-missing-firmware-files-in-pcie.c.patch @@ -0,0 +1,51 @@ +From 6d766d8cb505ec1fae63da8faef4fc5712c3d794 Mon Sep 17 00:00:00 2001 +From: Hector Martin +Date: Tue, 1 Feb 2022 01:07:08 +0900 +Subject: brcmfmac: pcie: Declare missing firmware files in pcie.c + +From: Hector Martin + +commit 6d766d8cb505ec1fae63da8faef4fc5712c3d794 upstream. + +Move one of the declarations from sdio.c to pcie.c, since it makes no +sense in the former (SDIO support is optional), and add missing ones. + +Fixes: 75729e110e68 ("brcmfmac: expose firmware config files through modinfo") +Reviewed-by: Linus Walleij +Reviewed-by: Arend van Spriel +Cc: stable@vger.kernel.org +Signed-off-by: Hector Martin +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/20220131160713.245637-5-marcan@marcan.st +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 7 +++++++ + drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 1 - + 2 files changed, 7 insertions(+), 1 deletion(-) + +--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c ++++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c +@@ -59,6 +59,13 @@ BRCMF_FW_DEF(4366B, "brcmfmac4366b-pcie" + BRCMF_FW_DEF(4366C, "brcmfmac4366c-pcie"); + BRCMF_FW_DEF(4371, "brcmfmac4371-pcie"); + ++/* firmware config files */ ++MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH "brcmfmac*-pcie.txt"); ++MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH "brcmfmac*-pcie.*.txt"); ++ ++/* per-board firmware binaries */ ++MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH "brcmfmac*-pcie.*.bin"); ++ + static const struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = { + BRCMF_FW_ENTRY(BRCM_CC_43602_CHIP_ID, 0xFFFFFFFF, 43602), + BRCMF_FW_ENTRY(BRCM_CC_43465_CHIP_ID, 0xFFFFFFF0, 4366C), +--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c ++++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c +@@ -629,7 +629,6 @@ BRCMF_FW_CLM_DEF(43752, "brcmfmac43752-s + + /* firmware config files */ + MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH "brcmfmac*-sdio.*.txt"); +-MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH "brcmfmac*-pcie.*.txt"); + + /* per-board firmware binaries */ + MODULE_FIRMWARE(BRCMF_FW_DEFAULT_PATH "brcmfmac*-sdio.*.bin"); diff --git a/queue-5.15/brcmfmac-pcie-fix-crashes-due-to-early-irqs.patch b/queue-5.15/brcmfmac-pcie-fix-crashes-due-to-early-irqs.patch new file mode 100644 index 00000000000..852b44cb5e7 --- /dev/null +++ b/queue-5.15/brcmfmac-pcie-fix-crashes-due-to-early-irqs.patch @@ -0,0 +1,66 @@ +From b50255c83b914defd61a57fbc81d452334b63f4c Mon Sep 17 00:00:00 2001 +From: Hector Martin +Date: Tue, 1 Feb 2022 01:07:10 +0900 +Subject: brcmfmac: pcie: Fix crashes due to early IRQs + +From: Hector Martin + +commit b50255c83b914defd61a57fbc81d452334b63f4c upstream. + +The driver was enabling IRQs before the message processing was +initialized. This could cause IRQs to come in too early and crash the +driver. Instead, move the IRQ enable and hostready to a bus preinit +function, at which point everything is properly initialized. + +Fixes: 9e37f045d5e7 ("brcmfmac: Adding PCIe bus layer support.") +Reviewed-by: Linus Walleij +Reviewed-by: Arend van Spriel +Cc: stable@vger.kernel.org +Signed-off-by: Hector Martin +Reviewed-by: Andy Shevchenko +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/20220131160713.245637-7-marcan@marcan.st +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 16 +++++++++++++--- + 1 file changed, 13 insertions(+), 3 deletions(-) + +--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c ++++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c +@@ -1315,6 +1315,18 @@ static void brcmf_pcie_down(struct devic + { + } + ++static int brcmf_pcie_preinit(struct device *dev) ++{ ++ struct brcmf_bus *bus_if = dev_get_drvdata(dev); ++ struct brcmf_pciedev *buspub = bus_if->bus_priv.pcie; ++ ++ brcmf_dbg(PCIE, "Enter\n"); ++ ++ brcmf_pcie_intr_enable(buspub->devinfo); ++ brcmf_pcie_hostready(buspub->devinfo); ++ ++ return 0; ++} + + static int brcmf_pcie_tx(struct device *dev, struct sk_buff *skb) + { +@@ -1423,6 +1435,7 @@ static int brcmf_pcie_reset(struct devic + } + + static const struct brcmf_bus_ops brcmf_pcie_bus_ops = { ++ .preinit = brcmf_pcie_preinit, + .txdata = brcmf_pcie_tx, + .stop = brcmf_pcie_down, + .txctl = brcmf_pcie_tx_ctlpkt, +@@ -1795,9 +1808,6 @@ static void brcmf_pcie_setup(struct devi + + init_waitqueue_head(&devinfo->mbdata_resp_wait); + +- brcmf_pcie_intr_enable(devinfo); +- brcmf_pcie_hostready(devinfo); +- + ret = brcmf_attach(&devinfo->pdev->dev); + if (ret) + goto fail; diff --git a/queue-5.15/brcmfmac-pcie-release-firmwares-in-the-brcmf_pcie_setup-error-path.patch b/queue-5.15/brcmfmac-pcie-release-firmwares-in-the-brcmf_pcie_setup-error-path.patch new file mode 100644 index 00000000000..ca8ad03adb1 --- /dev/null +++ b/queue-5.15/brcmfmac-pcie-release-firmwares-in-the-brcmf_pcie_setup-error-path.patch @@ -0,0 +1,36 @@ +From 5e90f0f3ead014867dade7a22f93958119f5efab Mon Sep 17 00:00:00 2001 +From: Hector Martin +Date: Tue, 1 Feb 2022 01:07:05 +0900 +Subject: brcmfmac: pcie: Release firmwares in the brcmf_pcie_setup error path + +From: Hector Martin + +commit 5e90f0f3ead014867dade7a22f93958119f5efab upstream. + +This avoids leaking memory if brcmf_chip_get_raminfo fails. Note that +the CLM blob is released in the device remove path. + +Fixes: 82f93cf46d60 ("brcmfmac: get chip's default RAM info during PCIe setup") +Reviewed-by: Linus Walleij +Reviewed-by: Arend van Spriel +Cc: stable@vger.kernel.org +Signed-off-by: Hector Martin +Reviewed-by: Andy Shevchenko +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/20220131160713.245637-2-marcan@marcan.st +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c ++++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c +@@ -1777,6 +1777,8 @@ static void brcmf_pcie_setup(struct devi + ret = brcmf_chip_get_raminfo(devinfo->ci); + if (ret) { + brcmf_err(bus, "Failed to get RAM info\n"); ++ release_firmware(fw); ++ brcmf_fw_nvram_free(nvram); + goto fail; + } + diff --git a/queue-5.15/brcmfmac-pcie-replace-brcmf_pcie_copy_mem_todev-with-memcpy_toio.patch b/queue-5.15/brcmfmac-pcie-replace-brcmf_pcie_copy_mem_todev-with-memcpy_toio.patch new file mode 100644 index 00000000000..3270895131d --- /dev/null +++ b/queue-5.15/brcmfmac-pcie-replace-brcmf_pcie_copy_mem_todev-with-memcpy_toio.patch @@ -0,0 +1,108 @@ +From 9466987f246758eb7e9071ae58005253f631271e Mon Sep 17 00:00:00 2001 +From: Hector Martin +Date: Tue, 1 Feb 2022 01:07:09 +0900 +Subject: brcmfmac: pcie: Replace brcmf_pcie_copy_mem_todev with memcpy_toio + +From: Hector Martin + +commit 9466987f246758eb7e9071ae58005253f631271e upstream. + +The alignment check was wrong (e.g. & 4 instead of & 3), and the logic +was also inefficient if the length was not a multiple of 4, since it +would needlessly fall back to copying the entire buffer bytewise. + +We already have a perfectly good memcpy_toio function, so just call that +instead of rolling our own copy logic here. brcmf_pcie_init_ringbuffers +was already using it anyway. + +Fixes: 9e37f045d5e7 ("brcmfmac: Adding PCIe bus layer support.") +Reviewed-by: Linus Walleij +Reviewed-by: Arend van Spriel +Reviewed-by: Andy Shevchenko +Cc: stable@vger.kernel.org +Signed-off-by: Hector Martin +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/20220131160713.245637-6-marcan@marcan.st +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 48 +--------------- + 1 file changed, 4 insertions(+), 44 deletions(-) + +--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c ++++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c +@@ -12,6 +12,7 @@ + #include + #include + #include ++#include + #include + + #include +@@ -455,47 +456,6 @@ brcmf_pcie_write_ram32(struct brcmf_pcie + + + static void +-brcmf_pcie_copy_mem_todev(struct brcmf_pciedev_info *devinfo, u32 mem_offset, +- void *srcaddr, u32 len) +-{ +- void __iomem *address = devinfo->tcm + mem_offset; +- __le32 *src32; +- __le16 *src16; +- u8 *src8; +- +- if (((ulong)address & 4) || ((ulong)srcaddr & 4) || (len & 4)) { +- if (((ulong)address & 2) || ((ulong)srcaddr & 2) || (len & 2)) { +- src8 = (u8 *)srcaddr; +- while (len) { +- iowrite8(*src8, address); +- address++; +- src8++; +- len--; +- } +- } else { +- len = len / 2; +- src16 = (__le16 *)srcaddr; +- while (len) { +- iowrite16(le16_to_cpu(*src16), address); +- address += 2; +- src16++; +- len--; +- } +- } +- } else { +- len = len / 4; +- src32 = (__le32 *)srcaddr; +- while (len) { +- iowrite32(le32_to_cpu(*src32), address); +- address += 4; +- src32++; +- len--; +- } +- } +-} +- +- +-static void + brcmf_pcie_copy_dev_tomem(struct brcmf_pciedev_info *devinfo, u32 mem_offset, + void *dstaddr, u32 len) + { +@@ -1570,8 +1530,8 @@ static int brcmf_pcie_download_fw_nvram( + return err; + + brcmf_dbg(PCIE, "Download FW %s\n", devinfo->fw_name); +- brcmf_pcie_copy_mem_todev(devinfo, devinfo->ci->rambase, +- (void *)fw->data, fw->size); ++ memcpy_toio(devinfo->tcm + devinfo->ci->rambase, ++ (void *)fw->data, fw->size); + + resetintr = get_unaligned_le32(fw->data); + release_firmware(fw); +@@ -1585,7 +1545,7 @@ static int brcmf_pcie_download_fw_nvram( + brcmf_dbg(PCIE, "Download NVRAM %s\n", devinfo->nvram_name); + address = devinfo->ci->rambase + devinfo->ci->ramsize - + nvram_len; +- brcmf_pcie_copy_mem_todev(devinfo, address, nvram, nvram_len); ++ memcpy_toio(devinfo->tcm + address, nvram, nvram_len); + brcmf_fw_nvram_free(nvram); + } else { + brcmf_dbg(PCIE, "No matching NVRAM file found %s\n", diff --git a/queue-5.15/btrfs-extend-locking-to-all-space_info-members-accesses.patch b/queue-5.15/btrfs-extend-locking-to-all-space_info-members-accesses.patch new file mode 100644 index 00000000000..8efe5aa970e --- /dev/null +++ b/queue-5.15/btrfs-extend-locking-to-all-space_info-members-accesses.patch @@ -0,0 +1,49 @@ +From 06bae876634ebf837ba70ea3de532b288326103d Mon Sep 17 00:00:00 2001 +From: Niels Dossche +Date: Fri, 25 Feb 2022 22:20:28 +0100 +Subject: btrfs: extend locking to all space_info members accesses + +From: Niels Dossche + +commit 06bae876634ebf837ba70ea3de532b288326103d upstream. + +bytes_pinned is always accessed under space_info->lock, except in +btrfs_preempt_reclaim_metadata_space, however the other members are +accessed under that lock. The reserved member of the rsv's are also +partially accessed under a lock and partially not. Move all these +accesses into the same lock to ensure consistency. + +This could potentially race and lead to a flush instead of a commit but +it's not a big problem as it's only for preemptive flush. + +CC: stable@vger.kernel.org # 5.15+ +Reviewed-by: Johannes Thumshirn +Reviewed-by: Josef Bacik +Signed-off-by: Niels Dossche +Signed-off-by: Niels Dossche +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/space-info.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/fs/btrfs/space-info.c ++++ b/fs/btrfs/space-info.c +@@ -1054,7 +1054,6 @@ static void btrfs_preempt_reclaim_metada + trans_rsv->reserved; + if (block_rsv_size < space_info->bytes_may_use) + delalloc_size = space_info->bytes_may_use - block_rsv_size; +- spin_unlock(&space_info->lock); + + /* + * We don't want to include the global_rsv in our calculation, +@@ -1085,6 +1084,8 @@ static void btrfs_preempt_reclaim_metada + flush = FLUSH_DELAYED_REFS_NR; + } + ++ spin_unlock(&space_info->lock); ++ + /* + * We don't want to reclaim everything, just a portion, so scale + * down the to_reclaim by 1/4. If it takes us down to 0, diff --git a/queue-5.15/btrfs-verify-the-tranisd-of-the-to-be-written-dirty-extent-buffer.patch b/queue-5.15/btrfs-verify-the-tranisd-of-the-to-be-written-dirty-extent-buffer.patch new file mode 100644 index 00000000000..0b35d02ccf7 --- /dev/null +++ b/queue-5.15/btrfs-verify-the-tranisd-of-the-to-be-written-dirty-extent-buffer.patch @@ -0,0 +1,96 @@ +From 3777369ff1518b579560611a0d0c33f930154f64 Mon Sep 17 00:00:00 2001 +From: Qu Wenruo +Date: Wed, 2 Mar 2022 09:10:21 +0800 +Subject: btrfs: verify the tranisd of the to-be-written dirty extent buffer + +From: Qu Wenruo + +commit 3777369ff1518b579560611a0d0c33f930154f64 upstream. + +[BUG] +There is a bug report that a bitflip in the transid part of an extent +buffer makes btrfs to reject certain tree blocks: + + BTRFS error (device dm-0): parent transid verify failed on 1382301696 wanted 262166 found 22 + +[CAUSE] +Note the failed transid check, hex(262166) = 0x40016, while +hex(22) = 0x16. + +It's an obvious bitflip. + +Furthermore, the reporter also confirmed the bitflip is from the +hardware, so it's a real hardware caused bitflip, and such problem can +not be detected by the existing tree-checker framework. + +As tree-checker can only verify the content inside one tree block, while +generation of a tree block can only be verified against its parent. + +So such problem remain undetected. + +[FIX] +Although tree-checker can not verify it at write-time, we still have a +quick (but not the most accurate) way to catch such obvious corruption. + +Function csum_one_extent_buffer() is called before we submit metadata +write. + +Thus it means, all the extent buffer passed in should be dirty tree +blocks, and should be newer than last committed transaction. + +Using that we can catch the above bitflip. + +Although it's not a perfect solution, as if the corrupted generation is +higher than the correct value, we have no way to catch it at all. + +Reported-by: Christoph Anton Mitterer +Link: https://lore.kernel.org/linux-btrfs/2dfcbc130c55cc6fd067b93752e90bd2b079baca.camel@scientia.org/ +CC: stable@vger.kernel.org # 5.15+ +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 | 26 ++++++++++++++++++++------ + 1 file changed, 20 insertions(+), 6 deletions(-) + +--- a/fs/btrfs/disk-io.c ++++ b/fs/btrfs/disk-io.c +@@ -441,17 +441,31 @@ static int csum_one_extent_buffer(struct + else + ret = btrfs_check_leaf_full(eb); + +- if (ret < 0) { +- btrfs_print_tree(eb, 0); ++ if (ret < 0) ++ goto error; ++ ++ /* ++ * Also check the generation, the eb reached here must be newer than ++ * last committed. Or something seriously wrong happened. ++ */ ++ if (unlikely(btrfs_header_generation(eb) <= fs_info->last_trans_committed)) { ++ ret = -EUCLEAN; + btrfs_err(fs_info, +- "block=%llu write time tree block corruption detected", +- eb->start); +- WARN_ON(IS_ENABLED(CONFIG_BTRFS_DEBUG)); +- return ret; ++ "block=%llu bad generation, have %llu expect > %llu", ++ eb->start, btrfs_header_generation(eb), ++ fs_info->last_trans_committed); ++ goto error; + } + write_extent_buffer(eb, result, 0, fs_info->csum_size); + + return 0; ++ ++error: ++ btrfs_print_tree(eb, 0); ++ btrfs_err(fs_info, "block=%llu write time tree block corruption detected", ++ eb->start); ++ WARN_ON(IS_ENABLED(CONFIG_BTRFS_DEBUG)); ++ return ret; + } + + /* Checksum all dirty extent buffers in one bio_vec */ diff --git a/queue-5.15/btrfs-zoned-mark-relocation-as-writing.patch b/queue-5.15/btrfs-zoned-mark-relocation-as-writing.patch new file mode 100644 index 00000000000..552e8427f0e --- /dev/null +++ b/queue-5.15/btrfs-zoned-mark-relocation-as-writing.patch @@ -0,0 +1,92 @@ +From ca5e4ea0beaec8bc674121838bf8614c089effb9 Mon Sep 17 00:00:00 2001 +From: Naohiro Aota +Date: Fri, 18 Feb 2022 13:14:19 +0900 +Subject: btrfs: zoned: mark relocation as writing + +From: Naohiro Aota + +commit ca5e4ea0beaec8bc674121838bf8614c089effb9 upstream. + +There is a hung_task issue with running generic/068 on an SMR +device. The hang occurs while a process is trying to thaw the +filesystem. The process is trying to take sb->s_umount to thaw the +FS. The lock is held by fsstress, which calls btrfs_sync_fs() and is +waiting for an ordered extent to finish. However, as the FS is frozen, +the ordered extents never finish. + +Having an ordered extent while the FS is frozen is the root cause of +the hang. The ordered extent is initiated from btrfs_relocate_chunk() +which is called from btrfs_reclaim_bgs_work(). + +This commit adds sb_*_write() around btrfs_relocate_chunk() call +site. For the usual "btrfs balance" command, we already call it with +mnt_want_file() in btrfs_ioctl_balance(). + +Fixes: 18bb8bbf13c1 ("btrfs: zoned: automatically reclaim zones") +CC: stable@vger.kernel.org # 5.13+ +Link: https://github.com/naota/linux/issues/56 +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 | 8 +++++++- + fs/btrfs/volumes.c | 3 +++ + 2 files changed, 10 insertions(+), 1 deletion(-) + +--- a/fs/btrfs/block-group.c ++++ b/fs/btrfs/block-group.c +@@ -1504,8 +1504,12 @@ void btrfs_reclaim_bgs_work(struct work_ + if (!test_bit(BTRFS_FS_OPEN, &fs_info->flags)) + return; + +- if (!btrfs_exclop_start(fs_info, BTRFS_EXCLOP_BALANCE)) ++ sb_start_write(fs_info->sb); ++ ++ if (!btrfs_exclop_start(fs_info, BTRFS_EXCLOP_BALANCE)) { ++ sb_end_write(fs_info->sb); + return; ++ } + + /* + * Long running balances can keep us blocked here for eternity, so +@@ -1513,6 +1517,7 @@ void btrfs_reclaim_bgs_work(struct work_ + */ + if (!mutex_trylock(&fs_info->reclaim_bgs_lock)) { + btrfs_exclop_finish(fs_info); ++ sb_end_write(fs_info->sb); + return; + } + +@@ -1581,6 +1586,7 @@ next: + spin_unlock(&fs_info->unused_bgs_lock); + mutex_unlock(&fs_info->reclaim_bgs_lock); + btrfs_exclop_finish(fs_info); ++ sb_end_write(fs_info->sb); + } + + void btrfs_reclaim_bgs(struct btrfs_fs_info *fs_info) +--- a/fs/btrfs/volumes.c ++++ b/fs/btrfs/volumes.c +@@ -8185,10 +8185,12 @@ static int relocating_repair_kthread(voi + target = cache->start; + btrfs_put_block_group(cache); + ++ sb_start_write(fs_info->sb); + if (!btrfs_exclop_start(fs_info, BTRFS_EXCLOP_BALANCE)) { + btrfs_info(fs_info, + "zoned: skip relocating block group %llu to repair: EBUSY", + target); ++ sb_end_write(fs_info->sb); + return -EBUSY; + } + +@@ -8216,6 +8218,7 @@ out: + btrfs_put_block_group(cache); + mutex_unlock(&fs_info->reclaim_bgs_lock); + btrfs_exclop_finish(fs_info); ++ sb_end_write(fs_info->sb); + + return ret; + } diff --git a/queue-5.15/can-isotp-sanitize-can-id-checks-in-isotp_bind.patch b/queue-5.15/can-isotp-sanitize-can-id-checks-in-isotp_bind.patch new file mode 100644 index 00000000000..5671f07b474 --- /dev/null +++ b/queue-5.15/can-isotp-sanitize-can-id-checks-in-isotp_bind.patch @@ -0,0 +1,104 @@ +From 3ea566422cbde9610c2734980d1286ab681bb40e Mon Sep 17 00:00:00 2001 +From: Oliver Hartkopp +Date: Wed, 16 Mar 2022 17:42:56 +0100 +Subject: can: isotp: sanitize CAN ID checks in isotp_bind() + +From: Oliver Hartkopp + +commit 3ea566422cbde9610c2734980d1286ab681bb40e upstream. + +Syzbot created an environment that lead to a state machine status that +can not be reached with a compliant CAN ID address configuration. +The provided address information consisted of CAN ID 0x6000001 and 0xC28001 +which both boil down to 11 bit CAN IDs 0x001 in sending and receiving. + +Sanitize the SFF/EFF CAN ID values before performing the address checks. + +Fixes: e057dd3fc20f ("can: add ISO 15765-2:2016 transport protocol") +Link: https://lore.kernel.org/all/20220316164258.54155-1-socketcan@hartkopp.net +Reported-by: syzbot+2339c27f5c66c652843e@syzkaller.appspotmail.com +Signed-off-by: Oliver Hartkopp +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Greg Kroah-Hartman +--- + net/can/isotp.c | 38 ++++++++++++++++++++------------------ + 1 file changed, 20 insertions(+), 18 deletions(-) + +--- a/net/can/isotp.c ++++ b/net/can/isotp.c +@@ -1104,6 +1104,7 @@ static int isotp_bind(struct socket *soc + struct net *net = sock_net(sk); + int ifindex; + struct net_device *dev; ++ canid_t tx_id, rx_id; + int err = 0; + int notify_enetdown = 0; + int do_rx_reg = 1; +@@ -1111,8 +1112,18 @@ static int isotp_bind(struct socket *soc + if (len < ISOTP_MIN_NAMELEN) + return -EINVAL; + +- if (addr->can_addr.tp.tx_id & (CAN_ERR_FLAG | CAN_RTR_FLAG)) +- return -EADDRNOTAVAIL; ++ /* sanitize tx/rx CAN identifiers */ ++ tx_id = addr->can_addr.tp.tx_id; ++ if (tx_id & CAN_EFF_FLAG) ++ tx_id &= (CAN_EFF_FLAG | CAN_EFF_MASK); ++ else ++ tx_id &= CAN_SFF_MASK; ++ ++ rx_id = addr->can_addr.tp.rx_id; ++ if (rx_id & CAN_EFF_FLAG) ++ rx_id &= (CAN_EFF_FLAG | CAN_EFF_MASK); ++ else ++ rx_id &= CAN_SFF_MASK; + + if (!addr->can_ifindex) + return -ENODEV; +@@ -1124,21 +1135,13 @@ static int isotp_bind(struct socket *soc + do_rx_reg = 0; + + /* do not validate rx address for functional addressing */ +- if (do_rx_reg) { +- if (addr->can_addr.tp.rx_id == addr->can_addr.tp.tx_id) { +- err = -EADDRNOTAVAIL; +- goto out; +- } +- +- if (addr->can_addr.tp.rx_id & (CAN_ERR_FLAG | CAN_RTR_FLAG)) { +- err = -EADDRNOTAVAIL; +- goto out; +- } ++ if (do_rx_reg && rx_id == tx_id) { ++ err = -EADDRNOTAVAIL; ++ goto out; + } + + if (so->bound && addr->can_ifindex == so->ifindex && +- addr->can_addr.tp.rx_id == so->rxid && +- addr->can_addr.tp.tx_id == so->txid) ++ rx_id == so->rxid && tx_id == so->txid) + goto out; + + dev = dev_get_by_index(net, addr->can_ifindex); +@@ -1162,8 +1165,7 @@ static int isotp_bind(struct socket *soc + ifindex = dev->ifindex; + + if (do_rx_reg) +- can_rx_register(net, dev, addr->can_addr.tp.rx_id, +- SINGLE_MASK(addr->can_addr.tp.rx_id), ++ can_rx_register(net, dev, rx_id, SINGLE_MASK(rx_id), + isotp_rcv, sk, "isotp", sk); + + dev_put(dev); +@@ -1183,8 +1185,8 @@ static int isotp_bind(struct socket *soc + + /* switch to new settings */ + so->ifindex = ifindex; +- so->rxid = addr->can_addr.tp.rx_id; +- so->txid = addr->can_addr.tp.tx_id; ++ so->rxid = rx_id; ++ so->txid = tx_id; + so->bound = 1; + + out: diff --git a/queue-5.15/carl9170-fix-missing-bit-wise-or-operator-for-tx_params.patch b/queue-5.15/carl9170-fix-missing-bit-wise-or-operator-for-tx_params.patch new file mode 100644 index 00000000000..f42a40e489f --- /dev/null +++ b/queue-5.15/carl9170-fix-missing-bit-wise-or-operator-for-tx_params.patch @@ -0,0 +1,39 @@ +From 02a95374b5eebdbd3b6413fd7ddec151d2ea75a1 Mon Sep 17 00:00:00 2001 +From: Colin Ian King +Date: Tue, 25 Jan 2022 00:44:06 +0000 +Subject: carl9170: fix missing bit-wise or operator for tx_params + +From: Colin Ian King + +commit 02a95374b5eebdbd3b6413fd7ddec151d2ea75a1 upstream. + +Currently tx_params is being re-assigned with a new value and the +previous setting IEEE80211_HT_MCS_TX_RX_DIFF is being overwritten. +The assignment operator is incorrect, the original intent was to +bit-wise or the value in. Fix this by replacing the = operator +with |= instead. + +Kudos to Christian Lamparter for suggesting the correct fix. + +Fixes: fe8ee9ad80b2 ("carl9170: mac80211 glue and command interface") +Signed-off-by: Colin Ian King +Cc: +Acked-by: Christian Lamparter +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/20220125004406.344422-1-colin.i.king@gmail.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/wireless/ath/carl9170/main.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/wireless/ath/carl9170/main.c ++++ b/drivers/net/wireless/ath/carl9170/main.c +@@ -1915,7 +1915,7 @@ static int carl9170_parse_eeprom(struct + WARN_ON(!(tx_streams >= 1 && tx_streams <= + IEEE80211_HT_MCS_TX_MAX_STREAMS)); + +- tx_params = (tx_streams - 1) << ++ tx_params |= (tx_streams - 1) << + IEEE80211_HT_MCS_TX_MAX_STREAMS_SHIFT; + + carl9170_band_2GHz.ht_cap.mcs.tx_params |= tx_params; diff --git a/queue-5.15/coredump-also-dump-first-pages-of-non-executable-elf-libraries.patch b/queue-5.15/coredump-also-dump-first-pages-of-non-executable-elf-libraries.patch new file mode 100644 index 00000000000..9478e3c3162 --- /dev/null +++ b/queue-5.15/coredump-also-dump-first-pages-of-non-executable-elf-libraries.patch @@ -0,0 +1,109 @@ +From 84158b7f6a0624b81800b4e7c90f7fb7fdecf66c Mon Sep 17 00:00:00 2001 +From: Jann Horn +Date: Wed, 26 Jan 2022 03:57:39 +0100 +Subject: coredump: Also dump first pages of non-executable ELF libraries + +From: Jann Horn + +commit 84158b7f6a0624b81800b4e7c90f7fb7fdecf66c upstream. + +When I rewrote the VMA dumping logic for coredumps, I changed it to +recognize ELF library mappings based on the file being executable instead +of the mapping having an ELF header. But turns out, distros ship many ELF +libraries as non-executable, so the heuristic goes wrong... + +Restore the old behavior where FILTER(ELF_HEADERS) dumps the first page of +any offset-0 readable mapping that starts with the ELF magic. + +This fix is technically layer-breaking a bit, because it checks for +something ELF-specific in fs/coredump.c; but since we probably want to +share this between standard ELF and FDPIC ELF anyway, I guess it's fine? +And this also keeps the change small for backporting. + +Cc: stable@vger.kernel.org +Fixes: 429a22e776a2 ("coredump: rework elf/elf_fdpic vma_dump_size() into common helper") +Reported-by: Bill Messmer +Signed-off-by: Jann Horn +Signed-off-by: Kees Cook +Link: https://lore.kernel.org/r/20220126025739.2014888-1-jannh@google.com +Signed-off-by: Greg Kroah-Hartman +--- + fs/coredump.c | 39 ++++++++++++++++++++++++++++++++++----- + 1 file changed, 34 insertions(+), 5 deletions(-) + +--- a/fs/coredump.c ++++ b/fs/coredump.c +@@ -41,6 +41,7 @@ + #include + #include + #include ++#include + + #include + #include +@@ -992,6 +993,8 @@ static bool always_dump_vma(struct vm_ar + return false; + } + ++#define DUMP_SIZE_MAYBE_ELFHDR_PLACEHOLDER 1 ++ + /* + * Decide how much of @vma's contents should be included in a core dump. + */ +@@ -1051,9 +1054,20 @@ static unsigned long vma_dump_size(struc + * dump the first page to aid in determining what was mapped here. + */ + if (FILTER(ELF_HEADERS) && +- vma->vm_pgoff == 0 && (vma->vm_flags & VM_READ) && +- (READ_ONCE(file_inode(vma->vm_file)->i_mode) & 0111) != 0) +- return PAGE_SIZE; ++ vma->vm_pgoff == 0 && (vma->vm_flags & VM_READ)) { ++ if ((READ_ONCE(file_inode(vma->vm_file)->i_mode) & 0111) != 0) ++ return PAGE_SIZE; ++ ++ /* ++ * ELF libraries aren't always executable. ++ * We'll want to check whether the mapping starts with the ELF ++ * magic, but not now - we're holding the mmap lock, ++ * so copy_from_user() doesn't work here. ++ * Use a placeholder instead, and fix it up later in ++ * dump_vma_snapshot(). ++ */ ++ return DUMP_SIZE_MAYBE_ELFHDR_PLACEHOLDER; ++ } + + #undef FILTER + +@@ -1128,8 +1142,6 @@ int dump_vma_snapshot(struct coredump_pa + m->end = vma->vm_end; + m->flags = vma->vm_flags; + m->dump_size = vma_dump_size(vma, cprm->mm_flags); +- +- vma_data_size += m->dump_size; + } + + mmap_write_unlock(mm); +@@ -1139,6 +1151,23 @@ int dump_vma_snapshot(struct coredump_pa + return -EFAULT; + } + ++ for (i = 0; i < *vma_count; i++) { ++ struct core_vma_metadata *m = (*vma_meta) + i; ++ ++ if (m->dump_size == DUMP_SIZE_MAYBE_ELFHDR_PLACEHOLDER) { ++ char elfmag[SELFMAG]; ++ ++ if (copy_from_user(elfmag, (void __user *)m->start, SELFMAG) || ++ memcmp(elfmag, ELFMAG, SELFMAG) != 0) { ++ m->dump_size = 0; ++ } else { ++ m->dump_size = PAGE_SIZE; ++ } ++ } ++ ++ vma_data_size += m->dump_size; ++ } ++ + *vma_data_size_ptr = vma_data_size; + return 0; + } diff --git a/queue-5.15/crypto-rsa-pkcs1pad-correctly-get-hash-from-source-scatterlist.patch b/queue-5.15/crypto-rsa-pkcs1pad-correctly-get-hash-from-source-scatterlist.patch new file mode 100644 index 00000000000..b2a0cb130ba --- /dev/null +++ b/queue-5.15/crypto-rsa-pkcs1pad-correctly-get-hash-from-source-scatterlist.patch @@ -0,0 +1,52 @@ +From e316f7179be22912281ce6331d96d7c121fb2b17 Mon Sep 17 00:00:00 2001 +From: Eric Biggers +Date: Tue, 18 Jan 2022 16:13:03 -0800 +Subject: crypto: rsa-pkcs1pad - correctly get hash from source scatterlist + +From: Eric Biggers + +commit e316f7179be22912281ce6331d96d7c121fb2b17 upstream. + +Commit c7381b012872 ("crypto: akcipher - new verify API for public key +algorithms") changed akcipher_alg::verify to take in both the signature +and the actual hash and do the signature verification, rather than just +return the hash expected by the signature as was the case before. To do +this, it implemented a hack where the signature and hash are +concatenated with each other in one scatterlist. + +Obviously, for this to work correctly, akcipher_alg::verify needs to +correctly extract the two items from the scatterlist it is given. +Unfortunately, it doesn't correctly extract the hash in the case where +the signature is longer than the RSA key size, as it assumes that the +signature's length is equal to the RSA key size. This causes a prefix +of the hash, or even the entire hash, to be taken from the *signature*. + +(Note, the case of a signature longer than the RSA key size should not +be allowed in the first place; a separate patch will fix that.) + +It is unclear whether the resulting scheme has any useful security +properties. + +Fix this by correctly extracting the hash from the scatterlist. + +Fixes: c7381b012872 ("crypto: akcipher - new verify API for public key algorithms") +Cc: # v5.2+ +Reviewed-by: Vitaly Chikunov +Signed-off-by: Eric Biggers +Signed-off-by: Herbert Xu +Signed-off-by: Greg Kroah-Hartman +--- + crypto/rsa-pkcs1pad.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/crypto/rsa-pkcs1pad.c ++++ b/crypto/rsa-pkcs1pad.c +@@ -495,7 +495,7 @@ static int pkcs1pad_verify_complete(stru + sg_nents_for_len(req->src, + req->src_len + req->dst_len), + req_ctx->out_buf + ctx->key_size, +- req->dst_len, ctx->key_size); ++ req->dst_len, req->src_len); + /* Do the actual verification step. */ + if (memcmp(req_ctx->out_buf + ctx->key_size, out_buf + pos, + req->dst_len) != 0) diff --git a/queue-5.15/crypto-rsa-pkcs1pad-fix-buffer-overread-in-pkcs1pad_verify_complete.patch b/queue-5.15/crypto-rsa-pkcs1pad-fix-buffer-overread-in-pkcs1pad_verify_complete.patch new file mode 100644 index 00000000000..5bdca586815 --- /dev/null +++ b/queue-5.15/crypto-rsa-pkcs1pad-fix-buffer-overread-in-pkcs1pad_verify_complete.patch @@ -0,0 +1,33 @@ +From a24611ea356c7f3f0ec926da11b9482ac1f414fd Mon Sep 17 00:00:00 2001 +From: Eric Biggers +Date: Tue, 18 Jan 2022 16:13:05 -0800 +Subject: crypto: rsa-pkcs1pad - fix buffer overread in pkcs1pad_verify_complete() + +From: Eric Biggers + +commit a24611ea356c7f3f0ec926da11b9482ac1f414fd upstream. + +Before checking whether the expected digest_info is present, we need to +check that there are enough bytes remaining. + +Fixes: a49de377e051 ("crypto: Add hash param to pkcs1pad") +Cc: # v4.6+ +Cc: Tadeusz Struk +Signed-off-by: Eric Biggers +Signed-off-by: Herbert Xu +Signed-off-by: Greg Kroah-Hartman +--- + crypto/rsa-pkcs1pad.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/crypto/rsa-pkcs1pad.c ++++ b/crypto/rsa-pkcs1pad.c +@@ -476,6 +476,8 @@ static int pkcs1pad_verify_complete(stru + pos++; + + if (digest_info) { ++ if (digest_info->size > dst_len - pos) ++ goto done; + if (crypto_memneq(out_buf + pos, digest_info->data, + digest_info->size)) + goto done; diff --git a/queue-5.15/crypto-rsa-pkcs1pad-only-allow-with-rsa.patch b/queue-5.15/crypto-rsa-pkcs1pad-only-allow-with-rsa.patch new file mode 100644 index 00000000000..c6b9b58b7bb --- /dev/null +++ b/queue-5.15/crypto-rsa-pkcs1pad-only-allow-with-rsa.patch @@ -0,0 +1,36 @@ +From 9b30430ea356f237945e52f8a3a42158877bd5a9 Mon Sep 17 00:00:00 2001 +From: Eric Biggers +Date: Tue, 18 Jan 2022 16:13:02 -0800 +Subject: crypto: rsa-pkcs1pad - only allow with rsa + +From: Eric Biggers + +commit 9b30430ea356f237945e52f8a3a42158877bd5a9 upstream. + +The pkcs1pad template can be instantiated with an arbitrary akcipher +algorithm, which doesn't make sense; it is specifically an RSA padding +scheme. Make it check that the underlying algorithm really is RSA. + +Fixes: 3d5b1ecdea6f ("crypto: rsa - RSA padding algorithm") +Cc: # v4.5+ +Signed-off-by: Eric Biggers +Signed-off-by: Herbert Xu +Signed-off-by: Greg Kroah-Hartman +--- + crypto/rsa-pkcs1pad.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/crypto/rsa-pkcs1pad.c ++++ b/crypto/rsa-pkcs1pad.c +@@ -621,6 +621,11 @@ static int pkcs1pad_create(struct crypto + + rsa_alg = crypto_spawn_akcipher_alg(&ctx->spawn); + ++ if (strcmp(rsa_alg->base.cra_name, "rsa") != 0) { ++ err = -EINVAL; ++ goto err_free_inst; ++ } ++ + err = -ENAMETOOLONG; + hash_name = crypto_attr_alg_name(tb[2]); + if (IS_ERR(hash_name)) { diff --git a/queue-5.15/crypto-rsa-pkcs1pad-restore-signature-length-check.patch b/queue-5.15/crypto-rsa-pkcs1pad-restore-signature-length-check.patch new file mode 100644 index 00000000000..b590426e88a --- /dev/null +++ b/queue-5.15/crypto-rsa-pkcs1pad-restore-signature-length-check.patch @@ -0,0 +1,46 @@ +From d3481accd974541e6a5d6a1fb588924a3519c36e Mon Sep 17 00:00:00 2001 +From: Eric Biggers +Date: Tue, 18 Jan 2022 16:13:04 -0800 +Subject: crypto: rsa-pkcs1pad - restore signature length check + +From: Eric Biggers + +commit d3481accd974541e6a5d6a1fb588924a3519c36e upstream. + +RSA PKCS#1 v1.5 signatures are required to be the same length as the RSA +key size. RFC8017 specifically requires the verifier to check this +(https://datatracker.ietf.org/doc/html/rfc8017#section-8.2.2). + +Commit a49de377e051 ("crypto: Add hash param to pkcs1pad") changed the +kernel to allow longer signatures, but didn't explain this part of the +change; it seems to be unrelated to the rest of the commit. + +Revert this change, since it doesn't appear to be correct. + +We can be pretty sure that no one is relying on overly-long signatures +(which would have to be front-padded with zeroes) being supported, given +that they would have been broken since commit c7381b012872 +("crypto: akcipher - new verify API for public key algorithms"). + +Fixes: a49de377e051 ("crypto: Add hash param to pkcs1pad") +Cc: # v4.6+ +Cc: Tadeusz Struk +Suggested-by: Vitaly Chikunov +Signed-off-by: Eric Biggers +Signed-off-by: Herbert Xu +Signed-off-by: Greg Kroah-Hartman +--- + crypto/rsa-pkcs1pad.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/crypto/rsa-pkcs1pad.c ++++ b/crypto/rsa-pkcs1pad.c +@@ -538,7 +538,7 @@ static int pkcs1pad_verify(struct akciph + + if (WARN_ON(req->dst) || + WARN_ON(!req->dst_len) || +- !ctx->key_size || req->src_len < ctx->key_size) ++ !ctx->key_size || req->src_len != ctx->key_size) + return -EINVAL; + + req_ctx->out_buf = kmalloc(ctx->key_size + req->dst_len, GFP_KERNEL); diff --git a/queue-5.15/dec-limit-pmax-memory-probing-to-r3k-systems.patch b/queue-5.15/dec-limit-pmax-memory-probing-to-r3k-systems.patch new file mode 100644 index 00000000000..bf532a4ee49 --- /dev/null +++ b/queue-5.15/dec-limit-pmax-memory-probing-to-r3k-systems.patch @@ -0,0 +1,70 @@ +From 244eae91a94c6dab82b3232967d10eeb9dfa21c6 Mon Sep 17 00:00:00 2001 +From: "Maciej W. Rozycki" +Date: Fri, 4 Mar 2022 20:16:23 +0000 +Subject: DEC: Limit PMAX memory probing to R3k systems + +From: Maciej W. Rozycki + +commit 244eae91a94c6dab82b3232967d10eeb9dfa21c6 upstream. + +Recent tightening of the opcode table in binutils so as to consistently +disallow the assembly or disassembly of CP0 instructions not supported +by the processor architecture chosen has caused a regression like below: + +arch/mips/dec/prom/locore.S: Assembler messages: +arch/mips/dec/prom/locore.S:29: Error: opcode not supported on this processor: r4600 (mips3) `rfe' + +in a piece of code used to probe for memory with PMAX DECstation models, +which have non-REX firmware. Those computers always have an R2000 CPU +and consequently the exception handler used in memory probing uses the +RFE instruction, which those processors use. + +While adding 64-bit support this code was correctly excluded for 64-bit +configurations, however it should have also been excluded for irrelevant +32-bit configurations. Do this now then, and only enable PMAX memory +probing for R3k systems. + +Reported-by: Jan-Benedict Glaw +Reported-by: Sudip Mukherjee +Signed-off-by: Maciej W. Rozycki +Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") +Cc: stable@vger.kernel.org # v2.6.12+ +Signed-off-by: Thomas Bogendoerfer +Signed-off-by: Greg Kroah-Hartman +--- + arch/mips/dec/prom/Makefile | 2 +- + arch/mips/include/asm/dec/prom.h | 15 +++++---------- + 2 files changed, 6 insertions(+), 11 deletions(-) + +--- a/arch/mips/dec/prom/Makefile ++++ b/arch/mips/dec/prom/Makefile +@@ -6,4 +6,4 @@ + + lib-y += init.o memory.o cmdline.o identify.o console.o + +-lib-$(CONFIG_32BIT) += locore.o ++lib-$(CONFIG_CPU_R3000) += locore.o +--- a/arch/mips/include/asm/dec/prom.h ++++ b/arch/mips/include/asm/dec/prom.h +@@ -43,16 +43,11 @@ + */ + #define REX_PROM_MAGIC 0x30464354 + +-#ifdef CONFIG_64BIT +- +-#define prom_is_rex(magic) 1 /* KN04 and KN05 are REX PROMs. */ +- +-#else /* !CONFIG_64BIT */ +- +-#define prom_is_rex(magic) ((magic) == REX_PROM_MAGIC) +- +-#endif /* !CONFIG_64BIT */ +- ++/* KN04 and KN05 are REX PROMs, so only do the check for R3k systems. */ ++static inline bool prom_is_rex(u32 magic) ++{ ++ return !IS_ENABLED(CONFIG_CPU_R3000) || magic == REX_PROM_MAGIC; ++} + + /* + * 3MIN/MAXINE PROM entry points for DS5000/1xx's, DS5000/xx's and diff --git a/queue-5.15/dm-fix-double-accounting-of-flush-with-data.patch b/queue-5.15/dm-fix-double-accounting-of-flush-with-data.patch new file mode 100644 index 00000000000..14a8feb9368 --- /dev/null +++ b/queue-5.15/dm-fix-double-accounting-of-flush-with-data.patch @@ -0,0 +1,140 @@ +From 8d394bc4adf588ca4a0650745167cb83f86c18c9 Mon Sep 17 00:00:00 2001 +From: Mike Snitzer +Date: Thu, 17 Feb 2022 23:39:57 -0500 +Subject: dm: fix double accounting of flush with data + +From: Mike Snitzer + +commit 8d394bc4adf588ca4a0650745167cb83f86c18c9 upstream. + +DM handles a flush with data by first issuing an empty flush and then +once it completes the REQ_PREFLUSH flag is removed and the payload is +issued. The problem fixed by this commit is that both the empty flush +bio and the data payload will account the full extent of the data +payload. + +Fix this by factoring out dm_io_acct() and having it wrap all IO +accounting to set the size of bio with REQ_PREFLUSH to 0, account the +IO, and then restore the original size. + +Cc: stable@vger.kernel.org +Signed-off-by: Mike Snitzer +Signed-off-by: Greg Kroah-Hartman +--- + drivers/md/dm-stats.c | 6 ++++-- + drivers/md/dm-stats.h | 2 +- + drivers/md/dm.c | 47 +++++++++++++++++++++++++++++++++-------------- + 3 files changed, 38 insertions(+), 17 deletions(-) + +--- a/drivers/md/dm-stats.c ++++ b/drivers/md/dm-stats.c +@@ -644,13 +644,14 @@ static void __dm_stat_bio(struct dm_stat + + void dm_stats_account_io(struct dm_stats *stats, unsigned long bi_rw, + sector_t bi_sector, unsigned bi_sectors, bool end, +- unsigned long duration_jiffies, ++ unsigned long start_time, + struct dm_stats_aux *stats_aux) + { + struct dm_stat *s; + sector_t end_sector; + struct dm_stats_last_position *last; + bool got_precise_time; ++ unsigned long duration_jiffies = 0; + + if (unlikely(!bi_sectors)) + return; +@@ -670,7 +671,8 @@ void dm_stats_account_io(struct dm_stats + )); + WRITE_ONCE(last->last_sector, end_sector); + WRITE_ONCE(last->last_rw, bi_rw); +- } ++ } else ++ duration_jiffies = jiffies - start_time; + + rcu_read_lock(); + +--- a/drivers/md/dm-stats.h ++++ b/drivers/md/dm-stats.h +@@ -31,7 +31,7 @@ int dm_stats_message(struct mapped_devic + + void dm_stats_account_io(struct dm_stats *stats, unsigned long bi_rw, + sector_t bi_sector, unsigned bi_sectors, bool end, +- unsigned long duration_jiffies, ++ unsigned long start_time, + struct dm_stats_aux *aux); + + static inline bool dm_stats_used(struct dm_stats *st) +--- a/drivers/md/dm.c ++++ b/drivers/md/dm.c +@@ -484,29 +484,48 @@ u64 dm_start_time_ns_from_clone(struct b + } + EXPORT_SYMBOL_GPL(dm_start_time_ns_from_clone); + +-static void start_io_acct(struct dm_io *io) ++static bool bio_is_flush_with_data(struct bio *bio) + { +- struct mapped_device *md = io->md; +- struct bio *bio = io->orig_bio; ++ return ((bio->bi_opf & REQ_PREFLUSH) && bio->bi_iter.bi_size); ++} ++ ++static void dm_io_acct(bool end, struct mapped_device *md, struct bio *bio, ++ unsigned long start_time, struct dm_stats_aux *stats_aux) ++{ ++ bool is_flush_with_data; ++ unsigned int bi_size; ++ ++ /* If REQ_PREFLUSH set save any payload but do not account it */ ++ is_flush_with_data = bio_is_flush_with_data(bio); ++ if (is_flush_with_data) { ++ bi_size = bio->bi_iter.bi_size; ++ bio->bi_iter.bi_size = 0; ++ } ++ ++ if (!end) ++ bio_start_io_acct_time(bio, start_time); ++ else ++ bio_end_io_acct(bio, start_time); + +- bio_start_io_acct_time(bio, io->start_time); + if (unlikely(dm_stats_used(&md->stats))) + dm_stats_account_io(&md->stats, bio_data_dir(bio), + bio->bi_iter.bi_sector, bio_sectors(bio), +- false, 0, &io->stats_aux); ++ end, start_time, stats_aux); ++ ++ /* Restore bio's payload so it does get accounted upon requeue */ ++ if (is_flush_with_data) ++ bio->bi_iter.bi_size = bi_size; ++} ++ ++static void start_io_acct(struct dm_io *io) ++{ ++ dm_io_acct(false, io->md, io->orig_bio, io->start_time, &io->stats_aux); + } + + static void end_io_acct(struct mapped_device *md, struct bio *bio, + unsigned long start_time, struct dm_stats_aux *stats_aux) + { +- unsigned long duration = jiffies - start_time; +- +- bio_end_io_acct(bio, start_time); +- +- if (unlikely(dm_stats_used(&md->stats))) +- dm_stats_account_io(&md->stats, bio_data_dir(bio), +- bio->bi_iter.bi_sector, bio_sectors(bio), +- true, duration, stats_aux); ++ dm_io_acct(true, md, bio, start_time, stats_aux); + } + + static struct dm_io *alloc_io(struct mapped_device *md, struct bio *bio) +@@ -835,7 +854,7 @@ void dm_io_dec_pending(struct dm_io *io, + if (io_error == BLK_STS_DM_REQUEUE) + return; + +- if ((bio->bi_opf & REQ_PREFLUSH) && bio->bi_iter.bi_size) { ++ if (bio_is_flush_with_data(bio)) { + /* + * Preflush done for flush with data, reissue + * without REQ_PREFLUSH. diff --git a/queue-5.15/dm-fix-use-after-free-in-dm_cleanup_zoned_dev.patch b/queue-5.15/dm-fix-use-after-free-in-dm_cleanup_zoned_dev.patch new file mode 100644 index 00000000000..1ffe0ed8734 --- /dev/null +++ b/queue-5.15/dm-fix-use-after-free-in-dm_cleanup_zoned_dev.patch @@ -0,0 +1,76 @@ +From 588b7f5df0cb64f281290c7672470c006abe7160 Mon Sep 17 00:00:00 2001 +From: Kirill Tkhai +Date: Tue, 1 Feb 2022 11:39:52 +0300 +Subject: dm: fix use-after-free in dm_cleanup_zoned_dev() + +From: Kirill Tkhai + +commit 588b7f5df0cb64f281290c7672470c006abe7160 upstream. + +dm_cleanup_zoned_dev() uses queue, so it must be called +before blk_cleanup_disk() starts its killing: + +blk_cleanup_disk->blk_cleanup_queue()->kobject_put()->blk_release_queue()-> +->...RCU...->blk_free_queue_rcu()->kmem_cache_free() + +Otherwise, RCU callback may be executed first and +dm_cleanup_zoned_dev() will touch free'd memory: + + BUG: KASAN: use-after-free in dm_cleanup_zoned_dev+0x33/0xd0 + Read of size 8 at addr ffff88805ac6e430 by task dmsetup/681 + + CPU: 4 PID: 681 Comm: dmsetup Not tainted 5.17.0-rc2+ #6 + Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 + Call Trace: + + dump_stack_lvl+0x57/0x7d + print_address_description.constprop.0+0x1f/0x150 + ? dm_cleanup_zoned_dev+0x33/0xd0 + kasan_report.cold+0x7f/0x11b + ? dm_cleanup_zoned_dev+0x33/0xd0 + dm_cleanup_zoned_dev+0x33/0xd0 + __dm_destroy+0x26a/0x400 + ? dm_blk_ioctl+0x230/0x230 + ? up_write+0xd8/0x270 + dev_remove+0x156/0x1d0 + ctl_ioctl+0x269/0x530 + ? table_clear+0x140/0x140 + ? lock_release+0xb2/0x750 + ? remove_all+0x40/0x40 + ? rcu_read_lock_sched_held+0x12/0x70 + ? lock_downgrade+0x3c0/0x3c0 + ? rcu_read_lock_sched_held+0x12/0x70 + dm_ctl_ioctl+0xa/0x10 + __x64_sys_ioctl+0xb9/0xf0 + do_syscall_64+0x3b/0x90 + entry_SYSCALL_64_after_hwframe+0x44/0xae + RIP: 0033:0x7fb6dfa95c27 + +Fixes: bb37d77239af ("dm: introduce zone append emulation") +Cc: stable@vger.kernel.org +Signed-off-by: Kirill Tkhai +Reviewed-by: Damien Le Moal +Signed-off-by: Mike Snitzer +Signed-off-by: Greg Kroah-Hartman +--- + drivers/md/dm.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/md/dm.c ++++ b/drivers/md/dm.c +@@ -1684,6 +1684,7 @@ static void cleanup_mapped_device(struct + md->dax_dev = NULL; + } + ++ dm_cleanup_zoned_dev(md); + if (md->disk) { + spin_lock(&_minor_lock); + md->disk->private_data = NULL; +@@ -1704,7 +1705,6 @@ static void cleanup_mapped_device(struct + mutex_destroy(&md->swap_bios_lock); + + dm_mq_cleanup_mapped_device(md); +- dm_cleanup_zoned_dev(md); + } + + /* diff --git a/queue-5.15/dm-integrity-set-journal-entry-unused-when-shrinking-device.patch b/queue-5.15/dm-integrity-set-journal-entry-unused-when-shrinking-device.patch new file mode 100644 index 00000000000..ab4a01b8803 --- /dev/null +++ b/queue-5.15/dm-integrity-set-journal-entry-unused-when-shrinking-device.patch @@ -0,0 +1,44 @@ +From cc09e8a9dec4f0e8299e80a7a2a8e6f54164a10b Mon Sep 17 00:00:00 2001 +From: Mikulas Patocka +Date: Sat, 26 Mar 2022 10:24:56 -0400 +Subject: dm integrity: set journal entry unused when shrinking device + +From: Mikulas Patocka + +commit cc09e8a9dec4f0e8299e80a7a2a8e6f54164a10b upstream. + +Commit f6f72f32c22c ("dm integrity: don't replay journal data past the +end of the device") skips journal replay if the target sector points +beyond the end of the device. Unfortunatelly, it doesn't set the +journal entry unused, which resulted in this BUG being triggered: +BUG_ON(!journal_entry_is_unused(je)) + +Fix this by calling journal_entry_set_unused() for this case. + +Fixes: f6f72f32c22c ("dm integrity: don't replay journal data past the end of the device") +Cc: stable@vger.kernel.org # v5.7+ +Signed-off-by: Mikulas Patocka +Tested-by: Milan Broz +[snitzer: revised header] +Signed-off-by: Mike Snitzer +Signed-off-by: Greg Kroah-Hartman +--- + drivers/md/dm-integrity.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/drivers/md/dm-integrity.c ++++ b/drivers/md/dm-integrity.c +@@ -2459,9 +2459,11 @@ static void do_journal_write(struct dm_i + dm_integrity_io_error(ic, "invalid sector in journal", -EIO); + sec &= ~(sector_t)(ic->sectors_per_block - 1); + } ++ if (unlikely(sec >= ic->provided_data_sectors)) { ++ journal_entry_set_unused(je); ++ continue; ++ } + } +- if (unlikely(sec >= ic->provided_data_sectors)) +- continue; + get_area_and_offset(ic, sec, &area, &offset); + restore_last_bytes(ic, access_journal_data(ic, i, j), je); + for (k = j + 1; k < ic->journal_section_entries; k++) { diff --git a/queue-5.15/dm-interlock-pending-dm_io-and-dm_wait_for_bios_completion.patch b/queue-5.15/dm-interlock-pending-dm_io-and-dm_wait_for_bios_completion.patch new file mode 100644 index 00000000000..55c266bfa7b --- /dev/null +++ b/queue-5.15/dm-interlock-pending-dm_io-and-dm_wait_for_bios_completion.patch @@ -0,0 +1,139 @@ +From 9f6dc633761006f974701d4c88da71ab68670749 Mon Sep 17 00:00:00 2001 +From: Mike Snitzer +Date: Thu, 17 Feb 2022 23:40:02 -0500 +Subject: dm: interlock pending dm_io and dm_wait_for_bios_completion + +From: Mike Snitzer + +commit 9f6dc633761006f974701d4c88da71ab68670749 upstream. + +Commit d208b89401e0 ("dm: fix mempool NULL pointer race when +completing IO") didn't go far enough. + +When bio_end_io_acct ends the count of in-flight I/Os may reach zero +and the DM device may be suspended. There is a possibility that the +suspend races with dm_stats_account_io. + +Fix this by adding percpu "pending_io" counters to track outstanding +dm_io. Move kicking of suspend queue to dm_io_dec_pending(). Also, +rename md_in_flight_bios() to dm_in_flight_bios() and update it to +iterate all pending_io counters. + +Fixes: d208b89401e0 ("dm: fix mempool NULL pointer race when completing IO") +Cc: stable@vger.kernel.org +Co-developed-by: Mikulas Patocka +Signed-off-by: Mikulas Patocka +Signed-off-by: Mike Snitzer +Signed-off-by: Greg Kroah-Hartman +--- + drivers/md/dm-core.h | 2 ++ + drivers/md/dm.c | 35 +++++++++++++++++++++++------------ + 2 files changed, 25 insertions(+), 12 deletions(-) + +--- a/drivers/md/dm-core.h ++++ b/drivers/md/dm-core.h +@@ -65,6 +65,8 @@ struct mapped_device { + struct gendisk *disk; + struct dax_device *dax_dev; + ++ unsigned long __percpu *pending_io; ++ + /* + * A list of ios that arrived while we were suspended. + */ +--- a/drivers/md/dm.c ++++ b/drivers/md/dm.c +@@ -507,10 +507,6 @@ static void end_io_acct(struct mapped_de + dm_stats_account_io(&md->stats, bio_data_dir(bio), + bio->bi_iter.bi_sector, bio_sectors(bio), + true, duration, stats_aux); +- +- /* nudge anyone waiting on suspend queue */ +- if (unlikely(wq_has_sleeper(&md->wait))) +- wake_up(&md->wait); + } + + static struct dm_io *alloc_io(struct mapped_device *md, struct bio *bio) +@@ -531,6 +527,7 @@ static struct dm_io *alloc_io(struct map + io->magic = DM_IO_MAGIC; + io->status = 0; + atomic_set(&io->io_count, 1); ++ this_cpu_inc(*md->pending_io); + io->orig_bio = bio; + io->md = md; + spin_lock_init(&io->endio_lock); +@@ -828,6 +825,12 @@ void dm_io_dec_pending(struct dm_io *io, + stats_aux = io->stats_aux; + free_io(md, io); + end_io_acct(md, bio, start_time, &stats_aux); ++ smp_wmb(); ++ this_cpu_dec(*md->pending_io); ++ ++ /* nudge anyone waiting on suspend queue */ ++ if (unlikely(wq_has_sleeper(&md->wait))) ++ wake_up(&md->wait); + + if (io_error == BLK_STS_DM_REQUEUE) + return; +@@ -1697,6 +1700,11 @@ static void cleanup_mapped_device(struct + blk_cleanup_disk(md->disk); + } + ++ if (md->pending_io) { ++ free_percpu(md->pending_io); ++ md->pending_io = NULL; ++ } ++ + cleanup_srcu_struct(&md->io_barrier); + + mutex_destroy(&md->suspend_lock); +@@ -1794,6 +1802,10 @@ static struct mapped_device *alloc_dev(i + if (!md->wq) + goto bad; + ++ md->pending_io = alloc_percpu(unsigned long); ++ if (!md->pending_io) ++ goto bad; ++ + dm_stats_init(&md->stats); + + /* Populate the mapping, nobody knows we exist yet */ +@@ -2209,16 +2221,13 @@ void dm_put(struct mapped_device *md) + } + EXPORT_SYMBOL_GPL(dm_put); + +-static bool md_in_flight_bios(struct mapped_device *md) ++static bool dm_in_flight_bios(struct mapped_device *md) + { + int cpu; +- struct block_device *part = dm_disk(md)->part0; +- long sum = 0; ++ unsigned long sum = 0; + +- for_each_possible_cpu(cpu) { +- sum += part_stat_local_read_cpu(part, in_flight[0], cpu); +- sum += part_stat_local_read_cpu(part, in_flight[1], cpu); +- } ++ for_each_possible_cpu(cpu) ++ sum += *per_cpu_ptr(md->pending_io, cpu); + + return sum != 0; + } +@@ -2231,7 +2240,7 @@ static int dm_wait_for_bios_completion(s + while (true) { + prepare_to_wait(&md->wait, &wait, task_state); + +- if (!md_in_flight_bios(md)) ++ if (!dm_in_flight_bios(md)) + break; + + if (signal_pending_state(task_state, current)) { +@@ -2243,6 +2252,8 @@ static int dm_wait_for_bios_completion(s + } + finish_wait(&md->wait, &wait); + ++ smp_rmb(); ++ + return r; + } + diff --git a/queue-5.15/dm-stats-fix-too-short-end-duration_ns-when-using-precise_timestamps.patch b/queue-5.15/dm-stats-fix-too-short-end-duration_ns-when-using-precise_timestamps.patch new file mode 100644 index 00000000000..963a4eec6ba --- /dev/null +++ b/queue-5.15/dm-stats-fix-too-short-end-duration_ns-when-using-precise_timestamps.patch @@ -0,0 +1,134 @@ +From 0cdb90f0f306384ecbc60dfd6dc48cdbc1f2d0d8 Mon Sep 17 00:00:00 2001 +From: Mike Snitzer +Date: Thu, 17 Feb 2022 23:39:59 -0500 +Subject: dm stats: fix too short end duration_ns when using precise_timestamps + +From: Mike Snitzer + +commit 0cdb90f0f306384ecbc60dfd6dc48cdbc1f2d0d8 upstream. + +dm_stats_account_io()'s STAT_PRECISE_TIMESTAMPS support doesn't handle +the fact that with commit b879f915bc48 ("dm: properly fix redundant +bio-based IO accounting") io->start_time _may_ be in the past (meaning +the start_io_acct() was deferred until later). + +Add a new dm_stats_recalc_precise_timestamps() helper that will +set/clear a new 'precise_timestamps' flag in the dm_stats struct based +on whether any configured stats enable STAT_PRECISE_TIMESTAMPS. +And update DM core's alloc_io() to use dm_stats_record_start() to set +stats_aux.duration_ns if stats->precise_timestamps is true. + +Also, remove unused 'last_sector' and 'last_rw' members from the +dm_stats struct. + +Fixes: b879f915bc48 ("dm: properly fix redundant bio-based IO accounting") +Cc: stable@vger.kernel.org +Co-developed-by: Mikulas Patocka +Signed-off-by: Mikulas Patocka +Signed-off-by: Mike Snitzer +Signed-off-by: Greg Kroah-Hartman +--- + drivers/md/dm-stats.c | 28 +++++++++++++++++++++++++--- + drivers/md/dm-stats.h | 9 +++++++-- + drivers/md/dm.c | 2 ++ + 3 files changed, 34 insertions(+), 5 deletions(-) + +--- a/drivers/md/dm-stats.c ++++ b/drivers/md/dm-stats.c +@@ -195,6 +195,7 @@ void dm_stats_init(struct dm_stats *stat + + mutex_init(&stats->mutex); + INIT_LIST_HEAD(&stats->list); ++ stats->precise_timestamps = false; + stats->last = alloc_percpu(struct dm_stats_last_position); + for_each_possible_cpu(cpu) { + last = per_cpu_ptr(stats->last, cpu); +@@ -231,6 +232,22 @@ void dm_stats_cleanup(struct dm_stats *s + mutex_destroy(&stats->mutex); + } + ++static void dm_stats_recalc_precise_timestamps(struct dm_stats *stats) ++{ ++ struct list_head *l; ++ struct dm_stat *tmp_s; ++ bool precise_timestamps = false; ++ ++ list_for_each(l, &stats->list) { ++ tmp_s = container_of(l, struct dm_stat, list_entry); ++ if (tmp_s->stat_flags & STAT_PRECISE_TIMESTAMPS) { ++ precise_timestamps = true; ++ break; ++ } ++ } ++ stats->precise_timestamps = precise_timestamps; ++} ++ + static int dm_stats_create(struct dm_stats *stats, sector_t start, sector_t end, + sector_t step, unsigned stat_flags, + unsigned n_histogram_entries, +@@ -376,6 +393,9 @@ static int dm_stats_create(struct dm_sta + } + ret_id = s->id; + list_add_tail_rcu(&s->list_entry, l); ++ ++ dm_stats_recalc_precise_timestamps(stats); ++ + mutex_unlock(&stats->mutex); + + resume_callback(md); +@@ -418,6 +438,9 @@ static int dm_stats_delete(struct dm_sta + } + + list_del_rcu(&s->list_entry); ++ ++ dm_stats_recalc_precise_timestamps(stats); ++ + mutex_unlock(&stats->mutex); + + /* +@@ -654,9 +677,8 @@ void dm_stats_account_io(struct dm_stats + got_precise_time = false; + list_for_each_entry_rcu(s, &stats->list, list_entry) { + if (s->stat_flags & STAT_PRECISE_TIMESTAMPS && !got_precise_time) { +- if (!end) +- stats_aux->duration_ns = ktime_to_ns(ktime_get()); +- else ++ /* start (!end) duration_ns is set by DM core's alloc_io() */ ++ if (end) + stats_aux->duration_ns = ktime_to_ns(ktime_get()) - stats_aux->duration_ns; + got_precise_time = true; + } +--- a/drivers/md/dm-stats.h ++++ b/drivers/md/dm-stats.h +@@ -13,8 +13,7 @@ struct dm_stats { + struct mutex mutex; + struct list_head list; /* list of struct dm_stat */ + struct dm_stats_last_position __percpu *last; +- sector_t last_sector; +- unsigned last_rw; ++ bool precise_timestamps; + }; + + struct dm_stats_aux { +@@ -40,4 +39,10 @@ static inline bool dm_stats_used(struct + return !list_empty(&st->list); + } + ++static inline void dm_stats_record_start(struct dm_stats *stats, struct dm_stats_aux *aux) ++{ ++ if (unlikely(stats->precise_timestamps)) ++ aux->duration_ns = ktime_to_ns(ktime_get()); ++} ++ + #endif +--- a/drivers/md/dm.c ++++ b/drivers/md/dm.c +@@ -537,6 +537,8 @@ static struct dm_io *alloc_io(struct map + + io->start_time = jiffies; + ++ dm_stats_record_start(&md->stats, &io->stats_aux); ++ + return io; + } + diff --git a/queue-5.15/drbd-fix-potential-silent-data-corruption.patch b/queue-5.15/drbd-fix-potential-silent-data-corruption.patch new file mode 100644 index 00000000000..99cb0998d4e --- /dev/null +++ b/queue-5.15/drbd-fix-potential-silent-data-corruption.patch @@ -0,0 +1,67 @@ +From f4329d1f848ac35757d9cc5487669d19dfc5979c Mon Sep 17 00:00:00 2001 +From: Lars Ellenberg +Date: Wed, 30 Mar 2022 20:55:51 +0200 +Subject: drbd: fix potential silent data corruption +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Lars Ellenberg + +commit f4329d1f848ac35757d9cc5487669d19dfc5979c upstream. + +Scenario: +--------- + +bio chain generated by blk_queue_split(). +Some split bio fails and propagates its error status to the "parent" bio. +But then the (last part of the) parent bio itself completes without error. + +We would clobber the already recorded error status with BLK_STS_OK, +causing silent data corruption. + +Reproducer: +----------- + +How to trigger this in the real world within seconds: + +DRBD on top of degraded parity raid, +small stripe_cache_size, large read_ahead setting. +Drop page cache (sysctl vm.drop_caches=1, fadvise "DONTNEED", +umount and mount again, "reboot"). + +Cause significant read ahead. + +Large read ahead request is split by blk_queue_split(). +Parts of the read ahead that are already in the stripe cache, +or find an available stripe cache to use, can be serviced. +Parts of the read ahead that would need "too much work", +would need to wait for a "stripe_head" to become available, +are rejected immediately. + +For larger read ahead requests that are split in many pieces, it is very +likely that some "splits" will be serviced, but then the stripe cache is +exhausted/busy, and the remaining ones will be rejected. + +Signed-off-by: Lars Ellenberg +Signed-off-by: Christoph Böhmwalder +Cc: # 4.13.x +Link: https://lore.kernel.org/r/20220330185551.3553196-1-christoph.boehmwalder@linbit.com +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + drivers/block/drbd/drbd_req.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/block/drbd/drbd_req.c ++++ b/drivers/block/drbd/drbd_req.c +@@ -180,7 +180,8 @@ void start_new_tl_epoch(struct drbd_conn + void complete_master_bio(struct drbd_device *device, + struct bio_and_error *m) + { +- m->bio->bi_status = errno_to_blk_status(m->error); ++ if (unlikely(m->error)) ++ m->bio->bi_status = errno_to_blk_status(m->error); + bio_endio(m->bio); + dec_ap_bio(device); + } diff --git a/queue-5.15/drivers-hamradio-6pack-fix-uaf-bug-caused-by-mod_timer.patch b/queue-5.15/drivers-hamradio-6pack-fix-uaf-bug-caused-by-mod_timer.patch new file mode 100644 index 00000000000..02c4d92fd24 --- /dev/null +++ b/queue-5.15/drivers-hamradio-6pack-fix-uaf-bug-caused-by-mod_timer.patch @@ -0,0 +1,87 @@ +From efe4186e6a1b54bf38b9e05450d43b0da1fd7739 Mon Sep 17 00:00:00 2001 +From: Duoming Zhou +Date: Thu, 17 Feb 2022 09:43:03 +0800 +Subject: drivers: hamradio: 6pack: fix UAF bug caused by mod_timer() + +From: Duoming Zhou + +commit efe4186e6a1b54bf38b9e05450d43b0da1fd7739 upstream. + +When a 6pack device is detaching, the sixpack_close() will act to cleanup +necessary resources. Although del_timer_sync() in sixpack_close() +won't return if there is an active timer, one could use mod_timer() in +sp_xmit_on_air() to wake up timer again by calling userspace syscall such +as ax25_sendmsg(), ax25_connect() and ax25_ioctl(). + +This unexpected waked handler, sp_xmit_on_air(), realizes nothing about +the undergoing cleanup and may still call pty_write() to use driver layer +resources that have already been released. + +One of the possible race conditions is shown below: + + (USE) | (FREE) +ax25_sendmsg() | + ax25_queue_xmit() | + ... | + sp_xmit() | + sp_encaps() | sixpack_close() + sp_xmit_on_air() | del_timer_sync(&sp->tx_t) + mod_timer(&sp->tx_t,...) | ... + | unregister_netdev() + | ... + (wait a while) | tty_release() + | tty_release_struct() + | release_tty() + sp_xmit_on_air() | tty_kref_put(tty_struct) //FREE + pty_write(tty_struct) //USE | ... + +The corresponding fail log is shown below: +=============================================================== +BUG: KASAN: use-after-free in __run_timers.part.0+0x170/0x470 +Write of size 8 at addr ffff88800a652ab8 by task swapper/2/0 +... +Call Trace: + ... + queue_work_on+0x3f/0x50 + pty_write+0xcd/0xe0pty_write+0xcd/0xe0 + sp_xmit_on_air+0xb2/0x1f0 + call_timer_fn+0x28/0x150 + __run_timers.part.0+0x3c2/0x470 + run_timer_softirq+0x3b/0x80 + __do_softirq+0xf1/0x380 + ... + +This patch reorders the del_timer_sync() after the unregister_netdev() +to avoid UAF bugs. Because the unregister_netdev() is well synchronized, +it flushs out any pending queues, waits the refcount of net_device +decreases to zero and removes net_device from kernel. There is not any +running routines after executing unregister_netdev(). Therefore, we could +not arouse timer from userspace again. + +Signed-off-by: Duoming Zhou +Reviewed-by: Lin Ma +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/hamradio/6pack.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/net/hamradio/6pack.c ++++ b/drivers/net/hamradio/6pack.c +@@ -669,14 +669,14 @@ static void sixpack_close(struct tty_str + */ + netif_stop_queue(sp->dev); + ++ unregister_netdev(sp->dev); ++ + del_timer_sync(&sp->tx_t); + del_timer_sync(&sp->resync_t); + + /* Free all 6pack frame buffers. */ + kfree(sp->rbuff); + kfree(sp->xbuff); +- +- unregister_netdev(sp->dev); + } + + /* Perform I/O control on an active 6pack channel. */ diff --git a/queue-5.15/drm-edid-check-basic-audio-support-on-cea-extension-block.patch b/queue-5.15/drm-edid-check-basic-audio-support-on-cea-extension-block.patch new file mode 100644 index 00000000000..687d67ca333 --- /dev/null +++ b/queue-5.15/drm-edid-check-basic-audio-support-on-cea-extension-block.patch @@ -0,0 +1,42 @@ +From 5662abf6e21338be6d085d6375d3732ac6147fd2 Mon Sep 17 00:00:00 2001 +From: Cooper Chiou +Date: Thu, 24 Mar 2022 14:12:18 +0800 +Subject: drm/edid: check basic audio support on CEA extension block + +From: Cooper Chiou + +commit 5662abf6e21338be6d085d6375d3732ac6147fd2 upstream. + +Tag code stored in bit7:5 for CTA block byte[3] is not the same as +CEA extension block definition. Only check CEA block has +basic audio support. + +v3: update commit message. + +Cc: stable@vger.kernel.org +Cc: Jani Nikula +Cc: Shawn C Lee +Cc: intel-gfx +Signed-off-by: Cooper Chiou +Signed-off-by: Lee Shawn C +Fixes: e28ad544f462 ("drm/edid: parse CEA blocks embedded in DisplayID") +Reviewed-by: Jani Nikula +Signed-off-by: Jani Nikula +Link: https://patchwork.freedesktop.org/patch/msgid/20220324061218.32739-1-shawn.c.lee@intel.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/drm_edid.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/gpu/drm/drm_edid.c ++++ b/drivers/gpu/drm/drm_edid.c +@@ -4776,7 +4776,8 @@ bool drm_detect_monitor_audio(struct edi + if (!edid_ext) + goto end; + +- has_audio = ((edid_ext[3] & EDID_BASIC_AUDIO) != 0); ++ has_audio = (edid_ext[0] == CEA_EXT && ++ (edid_ext[3] & EDID_BASIC_AUDIO) != 0); + + if (has_audio) { + DRM_DEBUG_KMS("Monitor has basic audio support\n"); diff --git a/queue-5.15/drm-fb-helper-mark-screen-buffers-in-system-memory-with-fbinfo_virtfb.patch b/queue-5.15/drm-fb-helper-mark-screen-buffers-in-system-memory-with-fbinfo_virtfb.patch new file mode 100644 index 00000000000..653e35a0219 --- /dev/null +++ b/queue-5.15/drm-fb-helper-mark-screen-buffers-in-system-memory-with-fbinfo_virtfb.patch @@ -0,0 +1,67 @@ +From cd9f7f7ac5932129fe81b4c7559cfcb226ec7c5c Mon Sep 17 00:00:00 2001 +From: Thomas Zimmermann +Date: Tue, 1 Feb 2022 12:53:05 +0100 +Subject: drm/fb-helper: Mark screen buffers in system memory with FBINFO_VIRTFB + +From: Thomas Zimmermann + +commit cd9f7f7ac5932129fe81b4c7559cfcb226ec7c5c upstream. + +Mark screen buffers in system memory with FBINFO_VIRTFB. Otherwise, fbdev +deferred I/O marks mmap'ed areas of system memory with VM_IO. (There's an +inverse relationship between the two flags.) + +For shadow buffers, also set the FBINFO_READS_FAST hint. + +v3: + * change FB_ to FBINFO_ in commit description +v2: + * updated commit description (Daniel) + * added Fixes tag + +Signed-off-by: Thomas Zimmermann +Fixes: d536540f304c ("drm/fb-helper: Add generic fbdev emulation .fb_probe function") +Reviewed-by: Daniel Vetter +Cc: dri-devel@lists.freedesktop.org +Cc: # v4.19+ +Link: https://patchwork.freedesktop.org/patch/msgid/20220201115305.9333-1-tzimmermann@suse.de +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/drm_fb_helper.c | 9 ++++++--- + 1 file changed, 6 insertions(+), 3 deletions(-) + +--- a/drivers/gpu/drm/drm_fb_helper.c ++++ b/drivers/gpu/drm/drm_fb_helper.c +@@ -2346,6 +2346,7 @@ static int drm_fb_helper_generic_probe(s + fbi->fbops = &drm_fbdev_fb_ops; + fbi->screen_size = fb->height * fb->pitches[0]; + fbi->fix.smem_len = fbi->screen_size; ++ fbi->flags = FBINFO_DEFAULT; + + drm_fb_helper_fill_info(fbi, fb_helper, sizes); + +@@ -2353,19 +2354,21 @@ static int drm_fb_helper_generic_probe(s + fbi->screen_buffer = vzalloc(fbi->screen_size); + if (!fbi->screen_buffer) + return -ENOMEM; ++ fbi->flags |= FBINFO_VIRTFB | FBINFO_READS_FAST; + + fbi->fbdefio = &drm_fbdev_defio; +- + fb_deferred_io_init(fbi); + } else { + /* buffer is mapped for HW framebuffer */ + ret = drm_client_buffer_vmap(fb_helper->buffer, &map); + if (ret) + return ret; +- if (map.is_iomem) ++ if (map.is_iomem) { + fbi->screen_base = map.vaddr_iomem; +- else ++ } else { + fbi->screen_buffer = map.vaddr; ++ fbi->flags |= FBINFO_VIRTFB; ++ } + + /* + * Shamelessly leak the physical address to user-space. As diff --git a/queue-5.15/drm-i915-gem-add-missing-boundary-check-in-vm_access.patch b/queue-5.15/drm-i915-gem-add-missing-boundary-check-in-vm_access.patch new file mode 100644 index 00000000000..f8235bdd6a8 --- /dev/null +++ b/queue-5.15/drm-i915-gem-add-missing-boundary-check-in-vm_access.patch @@ -0,0 +1,82 @@ +From 3886a86e7e6cc6ce2ce93c440fecd8f42aed0ce7 Mon Sep 17 00:00:00 2001 +From: Mastan Katragadda +Date: Thu, 3 Mar 2022 11:34:28 +0530 +Subject: drm/i915/gem: add missing boundary check in vm_access + +From: Mastan Katragadda + +commit 3886a86e7e6cc6ce2ce93c440fecd8f42aed0ce7 upstream. + +A missing bounds check in vm_access() can lead to an out-of-bounds read +or write in the adjacent memory area, since the len attribute is not +validated before the memcpy later in the function, potentially hitting: + +[ 183.637831] BUG: unable to handle page fault for address: ffffc90000c86000 +[ 183.637934] #PF: supervisor read access in kernel mode +[ 183.637997] #PF: error_code(0x0000) - not-present page +[ 183.638059] PGD 100000067 P4D 100000067 PUD 100258067 PMD 106341067 PTE 0 +[ 183.638144] Oops: 0000 [#2] PREEMPT SMP NOPTI +[ 183.638201] CPU: 3 PID: 1790 Comm: poc Tainted: G D 5.17.0-rc6-ci-drm-11296+ #1 +[ 183.638298] Hardware name: Intel Corporation CoffeeLake Client Platform/CoffeeLake H DDR4 RVP, BIOS CNLSFWR1.R00.X208.B00.1905301319 05/30/2019 +[ 183.638430] RIP: 0010:memcpy_erms+0x6/0x10 +[ 183.640213] RSP: 0018:ffffc90001763d48 EFLAGS: 00010246 +[ 183.641117] RAX: ffff888109c14000 RBX: ffff888111bece40 RCX: 0000000000000ffc +[ 183.642029] RDX: 0000000000001000 RSI: ffffc90000c86000 RDI: ffff888109c14004 +[ 183.642946] RBP: 0000000000000ffc R08: 800000000000016b R09: 0000000000000000 +[ 183.643848] R10: ffffc90000c85000 R11: 0000000000000048 R12: 0000000000001000 +[ 183.644742] R13: ffff888111bed190 R14: ffff888109c14000 R15: 0000000000001000 +[ 183.645653] FS: 00007fe5ef807540(0000) GS:ffff88845b380000(0000) knlGS:0000000000000000 +[ 183.646570] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 183.647481] CR2: ffffc90000c86000 CR3: 000000010ff02006 CR4: 00000000003706e0 +[ 183.648384] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +[ 183.649271] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 +[ 183.650142] Call Trace: +[ 183.650988] +[ 183.651793] vm_access+0x1f0/0x2a0 [i915] +[ 183.652726] __access_remote_vm+0x224/0x380 +[ 183.653561] mem_rw.isra.0+0xf9/0x190 +[ 183.654402] vfs_read+0x9d/0x1b0 +[ 183.655238] ksys_read+0x63/0xe0 +[ 183.656065] do_syscall_64+0x38/0xc0 +[ 183.656882] entry_SYSCALL_64_after_hwframe+0x44/0xae +[ 183.657663] RIP: 0033:0x7fe5ef725142 +[ 183.659351] RSP: 002b:00007ffe1e81c7e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 +[ 183.660227] RAX: ffffffffffffffda RBX: 0000557055dfb780 RCX: 00007fe5ef725142 +[ 183.661104] RDX: 0000000000001000 RSI: 00007ffe1e81d880 RDI: 0000000000000005 +[ 183.661972] RBP: 00007ffe1e81e890 R08: 0000000000000030 R09: 0000000000000046 +[ 183.662832] R10: 0000557055dfc2e0 R11: 0000000000000246 R12: 0000557055dfb1c0 +[ 183.663691] R13: 00007ffe1e81e980 R14: 0000000000000000 R15: 0000000000000000 + +Changes since v1: + - Updated if condition with range_overflows_t [Chris Wilson] + +Fixes: 9f909e215fea ("drm/i915: Implement vm_ops->access for gdb access into mmaps") +Signed-off-by: Mastan Katragadda +Suggested-by: Adam Zabrocki +Reported-by: Jackson Cody +Cc: Chris Wilson +Cc: Jon Bloomfield +Cc: Sudeep Dutt +Cc: # v5.8+ +Reviewed-by: Matthew Auld +[mauld: tidy up the commit message and add Cc: stable] +Signed-off-by: Matthew Auld +Link: https://patchwork.freedesktop.org/patch/msgid/20220303060428.1668844-1-mastanx.katragadda@intel.com +(cherry picked from commit 661412e301e2ca86799aa4f400d1cf0bd38c57c6) +Signed-off-by: Joonas Lahtinen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c ++++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c +@@ -438,7 +438,7 @@ vm_access(struct vm_area_struct *area, u + return -EACCES; + + addr -= area->vm_start; +- if (addr >= obj->base.size) ++ if (range_overflows_t(u64, addr, len, obj->base.size)) + return -EINVAL; + + i915_gem_ww_ctx_init(&ww, true); diff --git a/queue-5.15/drm-i915-opregion-check-port-number-bounds-for-swsci-display-power-state.patch b/queue-5.15/drm-i915-opregion-check-port-number-bounds-for-swsci-display-power-state.patch new file mode 100644 index 00000000000..cd8d501a194 --- /dev/null +++ b/queue-5.15/drm-i915-opregion-check-port-number-bounds-for-swsci-display-power-state.patch @@ -0,0 +1,60 @@ +From 24a644ebbfd3b13cda702f98907f9dd123e34bf9 Mon Sep 17 00:00:00 2001 +From: Jani Nikula +Date: Thu, 10 Feb 2022 12:36:42 +0200 +Subject: drm/i915/opregion: check port number bounds for SWSCI display power state +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Jani Nikula + +commit 24a644ebbfd3b13cda702f98907f9dd123e34bf9 upstream. + +The mapping from enum port to whatever port numbering scheme is used by +the SWSCI Display Power State Notification is odd, and the memory of it +has faded. In any case, the parameter only has space for ports numbered +[0..4], and UBSAN reports bit shift beyond it when the platform has port +F or more. + +Since the SWSCI functionality is supposed to be obsolete for new +platforms (i.e. ones that might have port F or more), just bail out +early if the mapped and mangled port number is beyond what the Display +Power State Notification can support. + +Fixes: 9c4b0a683193 ("drm/i915: add opregion function to notify bios of encoder enable/disable") +Cc: # v3.13+ +Cc: Ville Syrjälä +Cc: Lucas De Marchi +Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4800 +Signed-off-by: Jani Nikula +Reviewed-by: Ville Syrjälä +Link: https://patchwork.freedesktop.org/patch/msgid/cc363f42d6b5a5932b6d218fefcc8bdfb15dbbe5.1644489329.git.jani.nikula@intel.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/i915/display/intel_opregion.c | 15 +++++++++++++++ + 1 file changed, 15 insertions(+) + +--- a/drivers/gpu/drm/i915/display/intel_opregion.c ++++ b/drivers/gpu/drm/i915/display/intel_opregion.c +@@ -376,6 +376,21 @@ int intel_opregion_notify_encoder(struct + return -EINVAL; + } + ++ /* ++ * The port numbering and mapping here is bizarre. The now-obsolete ++ * swsci spec supports ports numbered [0..4]. Port E is handled as a ++ * special case, but port F and beyond are not. The functionality is ++ * supposed to be obsolete for new platforms. Just bail out if the port ++ * number is out of bounds after mapping. ++ */ ++ if (port > 4) { ++ drm_dbg_kms(&dev_priv->drm, ++ "[ENCODER:%d:%s] port %c (index %u) out of bounds for display power state notification\n", ++ intel_encoder->base.base.id, intel_encoder->base.name, ++ port_name(intel_encoder->port), port); ++ return -EINVAL; ++ } ++ + if (!enable) + parm |= 4 << 8; + diff --git a/queue-5.15/drm-nouveau-backlight-fix-lvds-backlight-detection-on-some-laptops.patch b/queue-5.15/drm-nouveau-backlight-fix-lvds-backlight-detection-on-some-laptops.patch new file mode 100644 index 00000000000..8664963590f --- /dev/null +++ b/queue-5.15/drm-nouveau-backlight-fix-lvds-backlight-detection-on-some-laptops.patch @@ -0,0 +1,41 @@ +From 6b0076540faffd47f5a899bf12f3528c4f0e726b Mon Sep 17 00:00:00 2001 +From: Lyude Paul +Date: Fri, 4 Feb 2022 13:05:04 -0500 +Subject: drm/nouveau/backlight: Fix LVDS backlight detection on some laptops + +From: Lyude Paul + +commit 6b0076540faffd47f5a899bf12f3528c4f0e726b upstream. + +It seems that some laptops will report having both an eDP and LVDS +connector, even though only the LVDS connector is actually hooked up. This +can lead to issues with backlight registration if the eDP connector ends up +getting registered before the LVDS connector, as the backlight device will +then be registered to the eDP connector instead of the LVDS connector. + +So, fix this by only registering the backlight on connectors that are +reported as being connected. + +Signed-off-by: Lyude Paul +Fixes: 6eca310e8924 ("drm/nouveau/kms/nv50-: Add basic DPCD backlight support for nouveau") +Bugzilla: https://gitlab.freedesktop.org/drm/nouveau/-/issues/137 +Cc: # v5.15+ +Reviewed-by: Karol Herbst +Link: https://patchwork.freedesktop.org/patch/msgid/20220204180504.328999-1-lyude@redhat.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/nouveau/nouveau_backlight.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c ++++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c +@@ -294,7 +294,8 @@ nv50_backlight_init(struct nouveau_backl + struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev); + struct nvif_object *device = &drm->client.device.object; + +- if (!nvif_rd32(device, NV50_PDISP_SOR_PWM_CTL(ffs(nv_encoder->dcb->or) - 1))) ++ if (!nvif_rd32(device, NV50_PDISP_SOR_PWM_CTL(ffs(nv_encoder->dcb->or) - 1)) || ++ nv_conn->base.status != connector_status_connected) + return -ENODEV; + + if (nv_conn->type == DCB_CONNECTOR_eDP) { diff --git a/queue-5.15/drm-nouveau-backlight-just-set-all-backlight-types-as-raw.patch b/queue-5.15/drm-nouveau-backlight-just-set-all-backlight-types-as-raw.patch new file mode 100644 index 00000000000..c6867ab0a68 --- /dev/null +++ b/queue-5.15/drm-nouveau-backlight-just-set-all-backlight-types-as-raw.patch @@ -0,0 +1,58 @@ +From b21a142fd2055d8276169efcc95b624ff908a341 Mon Sep 17 00:00:00 2001 +From: Lyude Paul +Date: Fri, 4 Feb 2022 14:33:19 -0500 +Subject: drm/nouveau/backlight: Just set all backlight types as RAW + +From: Lyude Paul + +commit b21a142fd2055d8276169efcc95b624ff908a341 upstream. + +Currently we can get a warning on systems with eDP backlights like so: + + nv_backlight: invalid backlight type + WARNING: CPU: 4 PID: 454 at drivers/video/backlight/backlight.c:420 + backlight_device_register+0x226/0x250 + +This happens as a result of us not filling out props.type for the eDP +backlight, even though we do it for all other backlight types. + +Since nothing in our driver uses anything but BACKLIGHT_RAW, let's take the +props\.type assignments out of the codepaths for individual backlight types +and just set it unconditionally to prevent this from happening again. + +Signed-off-by: Lyude Paul +Fixes: 6eca310e8924 ("drm/nouveau/kms/nv50-: Add basic DPCD backlight support for nouveau") +Cc: # v5.15+ +Reviewed-by: Karol Herbst +Link: https://patchwork.freedesktop.org/patch/msgid/20220204193319.451119-1-lyude@redhat.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/nouveau/nouveau_backlight.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c ++++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c +@@ -101,7 +101,6 @@ nv40_backlight_init(struct nouveau_encod + if (!(nvif_rd32(device, NV40_PMC_BACKLIGHT) & NV40_PMC_BACKLIGHT_MASK)) + return -ENODEV; + +- props->type = BACKLIGHT_RAW; + props->max_brightness = 31; + *ops = &nv40_bl_ops; + return 0; +@@ -340,7 +339,6 @@ nv50_backlight_init(struct nouveau_backl + else + *ops = &nva3_bl_ops; + +- props->type = BACKLIGHT_RAW; + props->max_brightness = 100; + + return 0; +@@ -408,6 +406,7 @@ nouveau_backlight_init(struct drm_connec + goto fail_alloc; + } + ++ props.type = BACKLIGHT_RAW; + bl->dev = backlight_device_register(backlight_name, connector->kdev, + nv_encoder, ops, &props); + if (IS_ERR(bl->dev)) { diff --git a/queue-5.15/drm-simpledrm-add-panel-orientation-property-on-non-upright-mounted-lcd-panels.patch b/queue-5.15/drm-simpledrm-add-panel-orientation-property-on-non-upright-mounted-lcd-panels.patch new file mode 100644 index 00000000000..9498aba4619 --- /dev/null +++ b/queue-5.15/drm-simpledrm-add-panel-orientation-property-on-non-upright-mounted-lcd-panels.patch @@ -0,0 +1,42 @@ +From 94fa115f7b28a3f02611499175e134f0a823b686 Mon Sep 17 00:00:00 2001 +From: Hans de Goede +Date: Mon, 21 Feb 2022 23:00:45 +0100 +Subject: drm/simpledrm: Add "panel orientation" property on non-upright mounted LCD panels + +From: Hans de Goede + +commit 94fa115f7b28a3f02611499175e134f0a823b686 upstream. + +Some devices use e.g. a portrait panel in a standard laptop casing made +for landscape panels. efifb calls drm_get_panel_orientation_quirk() and +sets fb_info.fbcon_rotate_hint to make fbcon rotate the console so that +it shows up-right instead of on its side. + +When switching to simpledrm the fbcon renders on its side. Call the +drm_connector_set_panel_orientation_with_quirk() helper to add +a "panel orientation" property on devices listed in the quirk table, +to make the fbcon (and aware userspace apps) rotate the image to +display properly. + +Cc: Javier Martinez Canillas +Signed-off-by: Hans de Goede +Reviewed-by: Javier Martinez Canillas +Acked-by: Thomas Zimmermann +Link: https://patchwork.freedesktop.org/patch/msgid/20220221220045.11958-1-hdegoede@redhat.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/tiny/simpledrm.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/gpu/drm/tiny/simpledrm.c ++++ b/drivers/gpu/drm/tiny/simpledrm.c +@@ -779,6 +779,9 @@ static int simpledrm_device_init_modeset + if (ret) + return ret; + drm_connector_helper_add(connector, &simpledrm_connector_helper_funcs); ++ drm_connector_set_panel_orientation_with_quirk(connector, ++ DRM_MODE_PANEL_ORIENTATION_UNKNOWN, ++ mode->hdisplay, mode->vdisplay); + + formats = simpledrm_device_formats(sdev, &nformats); + diff --git a/queue-5.15/drm-syncobj-flatten-dma_fence_chains-on-transfer.patch b/queue-5.15/drm-syncobj-flatten-dma_fence_chains-on-transfer.patch new file mode 100644 index 00000000000..07b635bac4c --- /dev/null +++ b/queue-5.15/drm-syncobj-flatten-dma_fence_chains-on-transfer.patch @@ -0,0 +1,112 @@ +From 721255b52700b320c4ae2e23d57f7d9ad1db50b9 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Christian=20K=C3=B6nig?= +Date: Wed, 9 Feb 2022 19:13:04 +0100 +Subject: drm/syncobj: flatten dma_fence_chains on transfer +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Christian König + +commit 721255b52700b320c4ae2e23d57f7d9ad1db50b9 upstream. + +It is illegal to add a dma_fence_chain as timeline point. Flatten out +the fences into a dma_fence_array instead. + +Signed-off-by: Christian König +Reviewed-by: Nirmoy Das +Cc: +Link: https://patchwork.freedesktop.org/patch/msgid/20220209182600.434803-1-christian.koenig@amd.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/drm_syncobj.c | 61 ++++++++++++++++++++++++++++++++++++++---- + 1 file changed, 56 insertions(+), 5 deletions(-) + +--- a/drivers/gpu/drm/drm_syncobj.c ++++ b/drivers/gpu/drm/drm_syncobj.c +@@ -853,12 +853,57 @@ drm_syncobj_fd_to_handle_ioctl(struct dr + &args->handle); + } + ++ ++/* ++ * Try to flatten a dma_fence_chain into a dma_fence_array so that it can be ++ * added as timeline fence to a chain again. ++ */ ++static int drm_syncobj_flatten_chain(struct dma_fence **f) ++{ ++ struct dma_fence_chain *chain = to_dma_fence_chain(*f); ++ struct dma_fence *tmp, **fences; ++ struct dma_fence_array *array; ++ unsigned int count; ++ ++ if (!chain) ++ return 0; ++ ++ count = 0; ++ dma_fence_chain_for_each(tmp, &chain->base) ++ ++count; ++ ++ fences = kmalloc_array(count, sizeof(*fences), GFP_KERNEL); ++ if (!fences) ++ return -ENOMEM; ++ ++ count = 0; ++ dma_fence_chain_for_each(tmp, &chain->base) ++ fences[count++] = dma_fence_get(tmp); ++ ++ array = dma_fence_array_create(count, fences, ++ dma_fence_context_alloc(1), ++ 1, false); ++ if (!array) ++ goto free_fences; ++ ++ dma_fence_put(*f); ++ *f = &array->base; ++ return 0; ++ ++free_fences: ++ while (count--) ++ dma_fence_put(fences[count]); ++ ++ kfree(fences); ++ return -ENOMEM; ++} ++ + static int drm_syncobj_transfer_to_timeline(struct drm_file *file_private, + struct drm_syncobj_transfer *args) + { + struct drm_syncobj *timeline_syncobj = NULL; +- struct dma_fence *fence; + struct dma_fence_chain *chain; ++ struct dma_fence *fence; + int ret; + + timeline_syncobj = drm_syncobj_find(file_private, args->dst_handle); +@@ -869,16 +914,22 @@ static int drm_syncobj_transfer_to_timel + args->src_point, args->flags, + &fence); + if (ret) +- goto err; ++ goto err_put_timeline; ++ ++ ret = drm_syncobj_flatten_chain(&fence); ++ if (ret) ++ goto err_free_fence; ++ + chain = dma_fence_chain_alloc(); + if (!chain) { + ret = -ENOMEM; +- goto err1; ++ goto err_free_fence; + } ++ + drm_syncobj_add_point(timeline_syncobj, chain, fence, args->dst_point); +-err1: ++err_free_fence: + dma_fence_put(fence); +-err: ++err_put_timeline: + drm_syncobj_put(timeline_syncobj); + + return ret; diff --git a/queue-5.15/exec-force-single-empty-string-when-argv-is-empty.patch b/queue-5.15/exec-force-single-empty-string-when-argv-is-empty.patch new file mode 100644 index 00000000000..fb799ee718f --- /dev/null +++ b/queue-5.15/exec-force-single-empty-string-when-argv-is-empty.patch @@ -0,0 +1,129 @@ +From dcd46d897adb70d63e025f175a00a89797d31a43 Mon Sep 17 00:00:00 2001 +From: Kees Cook +Date: Mon, 31 Jan 2022 16:09:47 -0800 +Subject: exec: Force single empty string when argv is empty + +From: Kees Cook + +commit dcd46d897adb70d63e025f175a00a89797d31a43 upstream. + +Quoting[1] Ariadne Conill: + +"In several other operating systems, it is a hard requirement that the +second argument to execve(2) be the name of a program, thus prohibiting +a scenario where argc < 1. POSIX 2017 also recommends this behaviour, +but it is not an explicit requirement[2]: + + The argument arg0 should point to a filename string that is + associated with the process being started by one of the exec + functions. +... +Interestingly, Michael Kerrisk opened an issue about this in 2008[3], +but there was no consensus to support fixing this issue then. +Hopefully now that CVE-2021-4034 shows practical exploitative use[4] +of this bug in a shellcode, we can reconsider. + +This issue is being tracked in the KSPP issue tracker[5]." + +While the initial code searches[6][7] turned up what appeared to be +mostly corner case tests, trying to that just reject argv == NULL +(or an immediately terminated pointer list) quickly started tripping[8] +existing userspace programs. + +The next best approach is forcing a single empty string into argv and +adjusting argc to match. The number of programs depending on argc == 0 +seems a smaller set than those calling execve with a NULL argv. + +Account for the additional stack space in bprm_stack_limits(). Inject an +empty string when argc == 0 (and set argc = 1). Warn about the case so +userspace has some notice about the change: + + process './argc0' launched './argc0' with NULL argv: empty string added + +Additionally WARN() and reject NULL argv usage for kernel threads. + +[1] https://lore.kernel.org/lkml/20220127000724.15106-1-ariadne@dereferenced.org/ +[2] https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html +[3] https://bugzilla.kernel.org/show_bug.cgi?id=8408 +[4] https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt +[5] https://github.com/KSPP/linux/issues/176 +[6] https://codesearch.debian.net/search?q=execve%5C+*%5C%28%5B%5E%2C%5D%2B%2C+*NULL&literal=0 +[7] https://codesearch.debian.net/search?q=execlp%3F%5Cs*%5C%28%5B%5E%2C%5D%2B%2C%5Cs*NULL&literal=0 +[8] https://lore.kernel.org/lkml/20220131144352.GE16385@xsang-OptiPlex-9020/ + +Reported-by: Ariadne Conill +Reported-by: Michael Kerrisk +Cc: Matthew Wilcox +Cc: Christian Brauner +Cc: Rich Felker +Cc: Eric Biederman +Cc: Alexander Viro +Cc: linux-fsdevel@vger.kernel.org +Cc: stable@vger.kernel.org +Signed-off-by: Kees Cook +Acked-by: Christian Brauner +Acked-by: Ariadne Conill +Acked-by: Andy Lutomirski +Link: https://lore.kernel.org/r/20220201000947.2453721-1-keescook@chromium.org +Signed-off-by: Greg Kroah-Hartman +--- + fs/exec.c | 26 +++++++++++++++++++++++++- + 1 file changed, 25 insertions(+), 1 deletion(-) + +--- a/fs/exec.c ++++ b/fs/exec.c +@@ -494,8 +494,14 @@ static int bprm_stack_limits(struct linu + * the stack. They aren't stored until much later when we can't + * signal to the parent that the child has run out of stack space. + * Instead, calculate it here so it's possible to fail gracefully. ++ * ++ * In the case of argc = 0, make sure there is space for adding a ++ * empty string (which will bump argc to 1), to ensure confused ++ * userspace programs don't start processing from argv[1], thinking ++ * argc can never be 0, to keep them from walking envp by accident. ++ * See do_execveat_common(). + */ +- ptr_size = (bprm->argc + bprm->envc) * sizeof(void *); ++ ptr_size = (max(bprm->argc, 1) + bprm->envc) * sizeof(void *); + if (limit <= ptr_size) + return -E2BIG; + limit -= ptr_size; +@@ -1895,6 +1901,9 @@ static int do_execveat_common(int fd, st + } + + retval = count(argv, MAX_ARG_STRINGS); ++ if (retval == 0) ++ pr_warn_once("process '%s' launched '%s' with NULL argv: empty string added\n", ++ current->comm, bprm->filename); + if (retval < 0) + goto out_free; + bprm->argc = retval; +@@ -1921,6 +1930,19 @@ static int do_execveat_common(int fd, st + if (retval < 0) + goto out_free; + ++ /* ++ * When argv is empty, add an empty string ("") as argv[0] to ++ * ensure confused userspace programs that start processing ++ * from argv[1] won't end up walking envp. See also ++ * bprm_stack_limits(). ++ */ ++ if (bprm->argc == 0) { ++ retval = copy_string_kernel("", bprm); ++ if (retval < 0) ++ goto out_free; ++ bprm->argc = 1; ++ } ++ + retval = bprm_execve(bprm, fd, filename, flags); + out_free: + free_bprm(bprm); +@@ -1949,6 +1971,8 @@ int kernel_execve(const char *kernel_fil + } + + retval = count_strings_kernel(argv); ++ if (WARN_ON_ONCE(retval == 0)) ++ retval = -EINVAL; + if (retval < 0) + goto out_free; + bprm->argc = retval; diff --git a/queue-5.15/ext4-fix-ext4_fc_stats-trace-point.patch b/queue-5.15/ext4-fix-ext4_fc_stats-trace-point.patch new file mode 100644 index 00000000000..97fdce8e350 --- /dev/null +++ b/queue-5.15/ext4-fix-ext4_fc_stats-trace-point.patch @@ -0,0 +1,136 @@ +From 7af1974af0a9ba8a8ed2e3e947d87dd4d9a78d27 Mon Sep 17 00:00:00 2001 +From: Ritesh Harjani +Date: Sat, 12 Mar 2022 11:09:47 +0530 +Subject: ext4: fix ext4_fc_stats trace point + +From: Ritesh Harjani + +commit 7af1974af0a9ba8a8ed2e3e947d87dd4d9a78d27 upstream. + +ftrace's __print_symbolic() requires that any enum values used in the +symbol to string translation table be wrapped in a TRACE_DEFINE_ENUM +so that the enum value can be decoded from the ftrace ring buffer by +user space tooling. + +This patch also fixes few other problems found in this trace point. +e.g. dereferencing structures in TP_printk which should not be done +at any cost. + +Also to avoid checkpatch warnings, this patch removes those +whitespaces/tab stops issues. + +Cc: stable@kernel.org +Fixes: aa75f4d3daae ("ext4: main fast-commit commit path") +Reported-by: Steven Rostedt +Signed-off-by: Ritesh Harjani +Reviewed-by: Jan Kara +Reviewed-by: Steven Rostedt (Google) +Reviewed-by: Harshad Shirwadkar +Link: https://lore.kernel.org/r/b4b9691414c35c62e570b723e661c80674169f9a.1647057583.git.riteshh@linux.ibm.com +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman +--- + include/trace/events/ext4.h | 80 +++++++++++++++++++++++++++----------------- + 1 file changed, 50 insertions(+), 30 deletions(-) + +--- a/include/trace/events/ext4.h ++++ b/include/trace/events/ext4.h +@@ -95,6 +95,17 @@ TRACE_DEFINE_ENUM(ES_REFERENCED_B); + { FALLOC_FL_COLLAPSE_RANGE, "COLLAPSE_RANGE"}, \ + { FALLOC_FL_ZERO_RANGE, "ZERO_RANGE"}) + ++TRACE_DEFINE_ENUM(EXT4_FC_REASON_XATTR); ++TRACE_DEFINE_ENUM(EXT4_FC_REASON_CROSS_RENAME); ++TRACE_DEFINE_ENUM(EXT4_FC_REASON_JOURNAL_FLAG_CHANGE); ++TRACE_DEFINE_ENUM(EXT4_FC_REASON_NOMEM); ++TRACE_DEFINE_ENUM(EXT4_FC_REASON_SWAP_BOOT); ++TRACE_DEFINE_ENUM(EXT4_FC_REASON_RESIZE); ++TRACE_DEFINE_ENUM(EXT4_FC_REASON_RENAME_DIR); ++TRACE_DEFINE_ENUM(EXT4_FC_REASON_FALLOC_RANGE); ++TRACE_DEFINE_ENUM(EXT4_FC_REASON_INODE_JOURNAL_DATA); ++TRACE_DEFINE_ENUM(EXT4_FC_REASON_MAX); ++ + #define show_fc_reason(reason) \ + __print_symbolic(reason, \ + { EXT4_FC_REASON_XATTR, "XATTR"}, \ +@@ -2723,41 +2734,50 @@ TRACE_EVENT(ext4_fc_commit_stop, + + #define FC_REASON_NAME_STAT(reason) \ + show_fc_reason(reason), \ +- __entry->sbi->s_fc_stats.fc_ineligible_reason_count[reason] ++ __entry->fc_ineligible_rc[reason] + + TRACE_EVENT(ext4_fc_stats, +- TP_PROTO(struct super_block *sb), ++ TP_PROTO(struct super_block *sb), ++ ++ TP_ARGS(sb), ++ ++ TP_STRUCT__entry( ++ __field(dev_t, dev) ++ __array(unsigned int, fc_ineligible_rc, EXT4_FC_REASON_MAX) ++ __field(unsigned long, fc_commits) ++ __field(unsigned long, fc_ineligible_commits) ++ __field(unsigned long, fc_numblks) ++ ), + +- TP_ARGS(sb), ++ TP_fast_assign( ++ int i; + +- TP_STRUCT__entry( +- __field(dev_t, dev) +- __field(struct ext4_sb_info *, sbi) +- __field(int, count) +- ), +- +- TP_fast_assign( +- __entry->dev = sb->s_dev; +- __entry->sbi = EXT4_SB(sb); +- ), +- +- TP_printk("dev %d:%d fc ineligible reasons:\n" +- "%s:%d, %s:%d, %s:%d, %s:%d, %s:%d, %s:%d, %s:%d, %s:%d, %s:%d; " +- "num_commits:%ld, ineligible: %ld, numblks: %ld", +- MAJOR(__entry->dev), MINOR(__entry->dev), +- FC_REASON_NAME_STAT(EXT4_FC_REASON_XATTR), +- FC_REASON_NAME_STAT(EXT4_FC_REASON_CROSS_RENAME), +- FC_REASON_NAME_STAT(EXT4_FC_REASON_JOURNAL_FLAG_CHANGE), +- FC_REASON_NAME_STAT(EXT4_FC_REASON_NOMEM), +- FC_REASON_NAME_STAT(EXT4_FC_REASON_SWAP_BOOT), +- FC_REASON_NAME_STAT(EXT4_FC_REASON_RESIZE), +- FC_REASON_NAME_STAT(EXT4_FC_REASON_RENAME_DIR), +- FC_REASON_NAME_STAT(EXT4_FC_REASON_FALLOC_RANGE), +- FC_REASON_NAME_STAT(EXT4_FC_REASON_INODE_JOURNAL_DATA), +- __entry->sbi->s_fc_stats.fc_num_commits, +- __entry->sbi->s_fc_stats.fc_ineligible_commits, +- __entry->sbi->s_fc_stats.fc_numblks) ++ __entry->dev = sb->s_dev; ++ for (i = 0; i < EXT4_FC_REASON_MAX; i++) { ++ __entry->fc_ineligible_rc[i] = ++ EXT4_SB(sb)->s_fc_stats.fc_ineligible_reason_count[i]; ++ } ++ __entry->fc_commits = EXT4_SB(sb)->s_fc_stats.fc_num_commits; ++ __entry->fc_ineligible_commits = ++ EXT4_SB(sb)->s_fc_stats.fc_ineligible_commits; ++ __entry->fc_numblks = EXT4_SB(sb)->s_fc_stats.fc_numblks; ++ ), + ++ TP_printk("dev %d,%d fc ineligible reasons:\n" ++ "%s:%u, %s:%u, %s:%u, %s:%u, %s:%u, %s:%u, %s:%u, %s:%u, %s:%u " ++ "num_commits:%lu, ineligible: %lu, numblks: %lu", ++ MAJOR(__entry->dev), MINOR(__entry->dev), ++ FC_REASON_NAME_STAT(EXT4_FC_REASON_XATTR), ++ FC_REASON_NAME_STAT(EXT4_FC_REASON_CROSS_RENAME), ++ FC_REASON_NAME_STAT(EXT4_FC_REASON_JOURNAL_FLAG_CHANGE), ++ FC_REASON_NAME_STAT(EXT4_FC_REASON_NOMEM), ++ FC_REASON_NAME_STAT(EXT4_FC_REASON_SWAP_BOOT), ++ FC_REASON_NAME_STAT(EXT4_FC_REASON_RESIZE), ++ FC_REASON_NAME_STAT(EXT4_FC_REASON_RENAME_DIR), ++ FC_REASON_NAME_STAT(EXT4_FC_REASON_FALLOC_RANGE), ++ FC_REASON_NAME_STAT(EXT4_FC_REASON_INODE_JOURNAL_DATA), ++ __entry->fc_commits, __entry->fc_ineligible_commits, ++ __entry->fc_numblks) + ); + + #define DEFINE_TRACE_DENTRY_EVENT(__type) \ diff --git a/queue-5.15/ext4-fix-fs-corruption-when-tring-to-remove-a-non-empty-directory-with-io-error.patch b/queue-5.15/ext4-fix-fs-corruption-when-tring-to-remove-a-non-empty-directory-with-io-error.patch new file mode 100644 index 00000000000..df8e8e7e5af --- /dev/null +++ b/queue-5.15/ext4-fix-fs-corruption-when-tring-to-remove-a-non-empty-directory-with-io-error.patch @@ -0,0 +1,155 @@ +From 7aab5c84a0f6ec2290e2ba4a6b245178b1bf949a Mon Sep 17 00:00:00 2001 +From: Ye Bin +Date: Mon, 28 Feb 2022 10:48:15 +0800 +Subject: ext4: fix fs corruption when tring to remove a non-empty directory with IO error + +From: Ye Bin + +commit 7aab5c84a0f6ec2290e2ba4a6b245178b1bf949a upstream. + +We inject IO error when rmdir non empty direcory, then got issue as follows: +step1: mkfs.ext4 -F /dev/sda +step2: mount /dev/sda test +step3: cd test +step4: mkdir -p 1/2 +step5: rmdir 1 + [ 110.920551] ext4_empty_dir: inject fault + [ 110.921926] EXT4-fs warning (device sda): ext4_rmdir:3113: inode #12: + comm rmdir: empty directory '1' has too many links (3) +step6: cd .. +step7: umount test +step8: fsck.ext4 -f /dev/sda + e2fsck 1.42.9 (28-Dec-2013) + Pass 1: Checking inodes, blocks, and sizes + Pass 2: Checking directory structure + Entry '..' in .../??? (13) has deleted/unused inode 12. Clear? yes + Pass 3: Checking directory connectivity + Unconnected directory inode 13 (...) + Connect to /lost+found? yes + Pass 4: Checking reference counts + Inode 13 ref count is 3, should be 2. Fix? yes + Pass 5: Checking group summary information + + /dev/sda: ***** FILE SYSTEM WAS MODIFIED ***** + /dev/sda: 12/131072 files (0.0% non-contiguous), 26157/524288 blocks + +ext4_rmdir + if (!ext4_empty_dir(inode)) + goto end_rmdir; +ext4_empty_dir + bh = ext4_read_dirblock(inode, 0, DIRENT_HTREE); + if (IS_ERR(bh)) + return true; +Now if read directory block failed, 'ext4_empty_dir' will return true, assume +directory is empty. Obviously, it will lead to above issue. +To solve this issue, if read directory block failed 'ext4_empty_dir' just +return false. To avoid making things worse when file system is already +corrupted, 'ext4_empty_dir' also return false. + +Signed-off-by: Ye Bin +Cc: stable@kernel.org +Link: https://lore.kernel.org/r/20220228024815.3952506-1-yebin10@huawei.com +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman +--- + fs/ext4/inline.c | 9 ++++----- + fs/ext4/namei.c | 10 +++++----- + 2 files changed, 9 insertions(+), 10 deletions(-) + +--- a/fs/ext4/inline.c ++++ b/fs/ext4/inline.c +@@ -1788,19 +1788,20 @@ bool empty_inline_dir(struct inode *dir, + void *inline_pos; + unsigned int offset; + struct ext4_dir_entry_2 *de; +- bool ret = true; ++ bool ret = false; + + err = ext4_get_inode_loc(dir, &iloc); + if (err) { + EXT4_ERROR_INODE_ERR(dir, -err, + "error %d getting inode %lu block", + err, dir->i_ino); +- return true; ++ return false; + } + + down_read(&EXT4_I(dir)->xattr_sem); + if (!ext4_has_inline_data(dir)) { + *has_inline_data = 0; ++ ret = true; + goto out; + } + +@@ -1809,7 +1810,6 @@ bool empty_inline_dir(struct inode *dir, + ext4_warning(dir->i_sb, + "bad inline directory (dir #%lu) - no `..'", + dir->i_ino); +- ret = true; + goto out; + } + +@@ -1828,16 +1828,15 @@ bool empty_inline_dir(struct inode *dir, + dir->i_ino, le32_to_cpu(de->inode), + le16_to_cpu(de->rec_len), de->name_len, + inline_size); +- ret = true; + goto out; + } + if (le32_to_cpu(de->inode)) { +- ret = false; + goto out; + } + offset += ext4_rec_len_from_disk(de->rec_len, inline_size); + } + ++ ret = true; + out: + up_read(&EXT4_I(dir)->xattr_sem); + brelse(iloc.bh); +--- a/fs/ext4/namei.c ++++ b/fs/ext4/namei.c +@@ -2997,14 +2997,14 @@ bool ext4_empty_dir(struct inode *inode) + if (inode->i_size < ext4_dir_rec_len(1, NULL) + + ext4_dir_rec_len(2, NULL)) { + EXT4_ERROR_INODE(inode, "invalid size"); +- return true; ++ return false; + } + /* The first directory block must not be a hole, + * so treat it as DIRENT_HTREE + */ + bh = ext4_read_dirblock(inode, 0, DIRENT_HTREE); + if (IS_ERR(bh)) +- return true; ++ return false; + + de = (struct ext4_dir_entry_2 *) bh->b_data; + if (ext4_check_dir_entry(inode, NULL, de, bh, bh->b_data, bh->b_size, +@@ -3012,7 +3012,7 @@ bool ext4_empty_dir(struct inode *inode) + le32_to_cpu(de->inode) != inode->i_ino || strcmp(".", de->name)) { + ext4_warning_inode(inode, "directory missing '.'"); + brelse(bh); +- return true; ++ return false; + } + offset = ext4_rec_len_from_disk(de->rec_len, sb->s_blocksize); + de = ext4_next_entry(de, sb->s_blocksize); +@@ -3021,7 +3021,7 @@ bool ext4_empty_dir(struct inode *inode) + le32_to_cpu(de->inode) == 0 || strcmp("..", de->name)) { + ext4_warning_inode(inode, "directory missing '..'"); + brelse(bh); +- return true; ++ return false; + } + offset += ext4_rec_len_from_disk(de->rec_len, sb->s_blocksize); + while (offset < inode->i_size) { +@@ -3035,7 +3035,7 @@ bool ext4_empty_dir(struct inode *inode) + continue; + } + if (IS_ERR(bh)) +- return true; ++ return false; + } + de = (struct ext4_dir_entry_2 *) (bh->b_data + + (offset & (sb->s_blocksize - 1))); diff --git a/queue-5.15/ext4-make-mb_optimize_scan-performance-mount-option-work-with-extents.patch b/queue-5.15/ext4-make-mb_optimize_scan-performance-mount-option-work-with-extents.patch new file mode 100644 index 00000000000..589b36d00b5 --- /dev/null +++ b/queue-5.15/ext4-make-mb_optimize_scan-performance-mount-option-work-with-extents.patch @@ -0,0 +1,121 @@ +From 077d0c2c78df6f7260cdd015a991327efa44d8ad Mon Sep 17 00:00:00 2001 +From: Ojaswin Mujoo +Date: Tue, 8 Mar 2022 15:22:01 +0530 +Subject: ext4: make mb_optimize_scan performance mount option work with extents + +From: Ojaswin Mujoo + +commit 077d0c2c78df6f7260cdd015a991327efa44d8ad upstream. + +Currently mb_optimize_scan scan feature which improves filesystem +performance heavily (when FS is fragmented), seems to be not working +with files with extents (ext4 by default has files with extents). + +This patch fixes that and makes mb_optimize_scan feature work +for files with extents. + +Below are some performance numbers obtained when allocating a 10M and 100M +file with and w/o this patch on a filesytem with no 1M contiguous block. + + +=============== +Workload: dd if=/dev/urandom of=test conv=fsync bs=1M count=10/100 + +Time taken +===================================================== +no. Size without-patch with-patch Diff(%) +1 10M 0m8.401s 0m5.623s 33.06% +2 100M 1m40.465s 1m14.737s 25.6% + + +============= +w/o patch: + mballoc: + reqs: 17056 + success: 11407 + groups_scanned: 13643 + cr0_stats: + hits: 37 + groups_considered: 9472 + useless_loops: 36 + bad_suggestions: 0 + cr1_stats: + hits: 11418 + groups_considered: 908560 + useless_loops: 1894 + bad_suggestions: 0 + cr2_stats: + hits: 1873 + groups_considered: 6913 + useless_loops: 21 + cr3_stats: + hits: 21 + groups_considered: 5040 + useless_loops: 21 + extents_scanned: 417364 + goal_hits: 3707 + 2^n_hits: 37 + breaks: 1873 + lost: 0 + buddies_generated: 239/240 + buddies_time_used: 651080 + preallocated: 705 + discarded: 478 + +with patch: + mballoc: + reqs: 12768 + success: 11305 + groups_scanned: 12768 + cr0_stats: + hits: 1 + groups_considered: 18 + useless_loops: 0 + bad_suggestions: 0 + cr1_stats: + hits: 5829 + groups_considered: 50626 + useless_loops: 0 + bad_suggestions: 0 + cr2_stats: + hits: 6938 + groups_considered: 580363 + useless_loops: 0 + cr3_stats: + hits: 0 + groups_considered: 0 + useless_loops: 0 + extents_scanned: 309059 + goal_hits: 0 + 2^n_hits: 1 + breaks: 1463 + lost: 0 + buddies_generated: 239/240 + buddies_time_used: 791392 + preallocated: 673 + discarded: 446 + +Fixes: 196e402 (ext4: improve cr 0 / cr 1 group scanning) +Cc: stable@kernel.org +Reported-by: Geetika Moolchandani +Reported-by: Nageswara R Sastry +Suggested-by: Ritesh Harjani +Signed-off-by: Ojaswin Mujoo +Link: https://lore.kernel.org/r/fc9a48f7f8dcfc83891a8b21f6dd8cdf056ed810.1646732698.git.ojaswin@linux.ibm.com +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman +--- + fs/ext4/mballoc.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/ext4/mballoc.c ++++ b/fs/ext4/mballoc.c +@@ -1000,7 +1000,7 @@ static inline int should_optimize_scan(s + return 0; + if (ac->ac_criteria >= 2) + return 0; +- if (ext4_test_inode_flag(ac->ac_inode, EXT4_INODE_EXTENTS)) ++ if (!ext4_test_inode_flag(ac->ac_inode, EXT4_INODE_EXTENTS)) + return 0; + return 1; + } diff --git a/queue-5.15/fbdev-hot-unplug-firmware-fb-devices-on-forced-removal.patch b/queue-5.15/fbdev-hot-unplug-firmware-fb-devices-on-forced-removal.patch new file mode 100644 index 00000000000..4ea4abe3cd8 --- /dev/null +++ b/queue-5.15/fbdev-hot-unplug-firmware-fb-devices-on-forced-removal.patch @@ -0,0 +1,119 @@ +From 27599aacbaefcbf2af7b06b0029459bbf682000d Mon Sep 17 00:00:00 2001 +From: Thomas Zimmermann +Date: Tue, 25 Jan 2022 10:12:18 +0100 +Subject: fbdev: Hot-unplug firmware fb devices on forced removal + +From: Thomas Zimmermann + +commit 27599aacbaefcbf2af7b06b0029459bbf682000d upstream. + +Hot-unplug all firmware-framebuffer devices as part of removing +them via remove_conflicting_framebuffers() et al. Releases all +memory regions to be acquired by native drivers. + +Firmware, such as EFI, install a framebuffer while posting the +computer. After removing the firmware-framebuffer device from fbdev, +a native driver takes over the hardware and the firmware framebuffer +becomes invalid. + +Firmware-framebuffer drivers, specifically simplefb, don't release +their device from Linux' device hierarchy. It still owns the firmware +framebuffer and blocks the native drivers from loading. This has been +observed in the vmwgfx driver. [1] + +Initiating a device removal (i.e., hot unplug) as part of +remove_conflicting_framebuffers() removes the underlying device and +returns the memory range to the system. + +[1] https://lore.kernel.org/dri-devel/20220117180359.18114-1-zack@kde.org/ + +v2: + * rename variable 'dev' to 'device' (Javier) + +Signed-off-by: Thomas Zimmermann +Reported-by: Zack Rusin +Reviewed-by: Javier Martinez Canillas +Reviewed-by: Zack Rusin +Reviewed-by: Hans de Goede +CC: stable@vger.kernel.org # v5.11+ +Link: https://patchwork.freedesktop.org/patch/msgid/20220125091222.21457-2-tzimmermann@suse.de +Signed-off-by: Greg Kroah-Hartman +--- + drivers/video/fbdev/core/fbmem.c | 29 ++++++++++++++++++++++++++--- + include/linux/fb.h | 1 + + 2 files changed, 27 insertions(+), 3 deletions(-) + +--- a/drivers/video/fbdev/core/fbmem.c ++++ b/drivers/video/fbdev/core/fbmem.c +@@ -25,6 +25,7 @@ + #include + #include + #include ++#include + #include + #include + #include +@@ -1557,18 +1558,36 @@ static void do_remove_conflicting_frameb + /* check all firmware fbs and kick off if the base addr overlaps */ + for_each_registered_fb(i) { + struct apertures_struct *gen_aper; ++ struct device *device; + + if (!(registered_fb[i]->flags & FBINFO_MISC_FIRMWARE)) + continue; + + gen_aper = registered_fb[i]->apertures; ++ device = registered_fb[i]->device; + if (fb_do_apertures_overlap(gen_aper, a) || + (primary && gen_aper && gen_aper->count && + gen_aper->ranges[0].base == VGA_FB_PHYS)) { + + printk(KERN_INFO "fb%d: switching to %s from %s\n", + i, name, registered_fb[i]->fix.id); +- do_unregister_framebuffer(registered_fb[i]); ++ ++ /* ++ * If we kick-out a firmware driver, we also want to remove ++ * the underlying platform device, such as simple-framebuffer, ++ * VESA, EFI, etc. A native driver will then be able to ++ * allocate the memory range. ++ * ++ * If it's not a platform device, at least print a warning. A ++ * fix would add code to remove the device from the system. ++ */ ++ if (dev_is_platform(device)) { ++ registered_fb[i]->forced_out = true; ++ platform_device_unregister(to_platform_device(device)); ++ } else { ++ pr_warn("fb%d: cannot remove device\n", i); ++ do_unregister_framebuffer(registered_fb[i]); ++ } + } + } + } +@@ -1895,9 +1914,13 @@ EXPORT_SYMBOL(register_framebuffer); + void + unregister_framebuffer(struct fb_info *fb_info) + { +- mutex_lock(®istration_lock); ++ bool forced_out = fb_info->forced_out; ++ ++ if (!forced_out) ++ mutex_lock(®istration_lock); + do_unregister_framebuffer(fb_info); +- mutex_unlock(®istration_lock); ++ if (!forced_out) ++ mutex_unlock(®istration_lock); + } + EXPORT_SYMBOL(unregister_framebuffer); + +--- a/include/linux/fb.h ++++ b/include/linux/fb.h +@@ -502,6 +502,7 @@ struct fb_info { + } *apertures; + + bool skip_vt_switch; /* no VT switch on suspend/resume required */ ++ bool forced_out; /* set when being removed by another driver */ + }; + + static inline struct apertures_struct *alloc_apertures(unsigned int max_num) { diff --git a/queue-5.15/landlock-use-square-brackets-around-landlock-ruleset.patch b/queue-5.15/landlock-use-square-brackets-around-landlock-ruleset.patch new file mode 100644 index 00000000000..63179c932f5 --- /dev/null +++ b/queue-5.15/landlock-use-square-brackets-around-landlock-ruleset.patch @@ -0,0 +1,52 @@ +From aea0b9f2486da8497f35c7114b764bf55e17c7ea Mon Sep 17 00:00:00 2001 +From: Christian Brauner +Date: Mon, 11 Oct 2021 15:37:04 +0200 +Subject: landlock: Use square brackets around "landlock-ruleset" +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Christian Brauner + +commit aea0b9f2486da8497f35c7114b764bf55e17c7ea upstream. + +Make the name of the anon inode fd "[landlock-ruleset]" instead of +"landlock-ruleset". This is minor but most anon inode fds already +carry square brackets around their name: + + [eventfd] + [eventpoll] + [fanotify] + [fscontext] + [io_uring] + [pidfd] + [signalfd] + [timerfd] + [userfaultfd] + +For the sake of consistency lets do the same for the landlock-ruleset anon +inode fd that comes with landlock. We did the same in +1cdc415f1083 ("uapi, fsopen: use square brackets around "fscontext" [ver #2]") +for the new mount api. + +Cc: linux-security-module@vger.kernel.org +Signed-off-by: Christian Brauner +Link: https://lore.kernel.org/r/20211011133704.1704369-1-brauner@kernel.org +Cc: stable@vger.kernel.org +Signed-off-by: Mickaël Salaün +Signed-off-by: Greg Kroah-Hartman +--- + security/landlock/syscalls.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/security/landlock/syscalls.c ++++ b/security/landlock/syscalls.c +@@ -192,7 +192,7 @@ SYSCALL_DEFINE3(landlock_create_ruleset, + return PTR_ERR(ruleset); + + /* Creates anonymous FD referring to the ruleset. */ +- ruleset_fd = anon_inode_getfd("landlock-ruleset", &ruleset_fops, ++ ruleset_fd = anon_inode_getfd("[landlock-ruleset]", &ruleset_fops, + ruleset, O_RDWR | O_CLOEXEC); + if (ruleset_fd < 0) + landlock_put_ruleset(ruleset); diff --git a/queue-5.15/lib-raid6-test-fix-multiple-definition-linking-error.patch b/queue-5.15/lib-raid6-test-fix-multiple-definition-linking-error.patch new file mode 100644 index 00000000000..7d28e22bc6b --- /dev/null +++ b/queue-5.15/lib-raid6-test-fix-multiple-definition-linking-error.patch @@ -0,0 +1,41 @@ +From a5359ddd052860bacf957e65fe819c63e974b3a6 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Dirk=20M=C3=BCller?= +Date: Tue, 8 Feb 2022 17:50:50 +0100 +Subject: lib/raid6/test: fix multiple definition linking error +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Dirk Müller + +commit a5359ddd052860bacf957e65fe819c63e974b3a6 upstream. + +GCC 10+ defaults to -fno-common, which enforces proper declaration of +external references using "extern". without this change a link would +fail with: + + lib/raid6/test/algos.c:28: multiple definition of `raid6_call'; + lib/raid6/test/test.c:22: first defined here + +the pq.h header that is included already includes an extern declaration +so we can just remove the redundant one here. + +Cc: +Signed-off-by: Dirk Müller +Reviewed-by: Paul Menzel +Signed-off-by: Song Liu +Signed-off-by: Greg Kroah-Hartman +--- + lib/raid6/test/test.c | 1 - + 1 file changed, 1 deletion(-) + +--- a/lib/raid6/test/test.c ++++ b/lib/raid6/test/test.c +@@ -19,7 +19,6 @@ + #define NDISKS 16 /* Including P and Q */ + + const char raid6_empty_zero_page[PAGE_SIZE] __attribute__((aligned(PAGE_SIZE))); +-struct raid6_calls raid6_call; + + char *dataptrs[NDISKS]; + char data[NDISKS][PAGE_SIZE] __attribute__((aligned(PAGE_SIZE))); diff --git a/queue-5.15/mailbox-tegra-hsp-flush-whole-channel.patch b/queue-5.15/mailbox-tegra-hsp-flush-whole-channel.patch new file mode 100644 index 00000000000..64824123246 --- /dev/null +++ b/queue-5.15/mailbox-tegra-hsp-flush-whole-channel.patch @@ -0,0 +1,41 @@ +From 60de2d2dc284e0dd1c2c897d08625bde24ef3454 Mon Sep 17 00:00:00 2001 +From: Pekka Pessi +Date: Wed, 2 Mar 2022 16:04:24 +0100 +Subject: mailbox: tegra-hsp: Flush whole channel + +From: Pekka Pessi + +commit 60de2d2dc284e0dd1c2c897d08625bde24ef3454 upstream. + +The txdone can re-fill the mailbox. Keep polling the mailbox during the +flush until all the messages have been delivered. + +This fixes an issue with the Tegra Combined UART (TCU) where output can +get truncated under high traffic load. + +Signed-off-by: Pekka Pessi +Tested-by: Jon Hunter +Fixes: 91b1b1c3da8a ("mailbox: tegra-hsp: Add support for shared mailboxes") +Cc: stable@vger.kernel.org +Signed-off-by: Thierry Reding +Reviewed-by: Jon Hunter +Signed-off-by: Jassi Brar +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mailbox/tegra-hsp.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/drivers/mailbox/tegra-hsp.c ++++ b/drivers/mailbox/tegra-hsp.c +@@ -412,6 +412,11 @@ static int tegra_hsp_mailbox_flush(struc + value = tegra_hsp_channel_readl(ch, HSP_SM_SHRD_MBOX); + if ((value & HSP_SM_SHRD_MBOX_FULL) == 0) { + mbox_chan_txdone(chan, 0); ++ ++ /* Wait until channel is empty */ ++ if (chan->active_req != NULL) ++ continue; ++ + return 0; + } + diff --git a/queue-5.15/media-davinci-vpif-fix-unbalanced-runtime-pm-enable.patch b/queue-5.15/media-davinci-vpif-fix-unbalanced-runtime-pm-enable.patch new file mode 100644 index 00000000000..0a336d0b4c2 --- /dev/null +++ b/queue-5.15/media-davinci-vpif-fix-unbalanced-runtime-pm-enable.patch @@ -0,0 +1,56 @@ +From d42b3ad105b5d3481f6a56bc789aa2b27aa09325 Mon Sep 17 00:00:00 2001 +From: Johan Hovold +Date: Wed, 22 Dec 2021 15:20:23 +0100 +Subject: media: davinci: vpif: fix unbalanced runtime PM enable + +From: Johan Hovold + +commit d42b3ad105b5d3481f6a56bc789aa2b27aa09325 upstream. + +Make sure to disable runtime PM before returning on probe errors. + +Fixes: 479f7a118105 ("[media] davinci: vpif: adaptions for DT support") +Cc: stable@vger.kernel.org +Cc: Kevin Hilman +Signed-off-by: Johan Hovold +Signed-off-by: Hans Verkuil +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman +--- + drivers/media/platform/davinci/vpif.c | 11 +++++++++-- + 1 file changed, 9 insertions(+), 2 deletions(-) + +--- a/drivers/media/platform/davinci/vpif.c ++++ b/drivers/media/platform/davinci/vpif.c +@@ -428,6 +428,7 @@ static int vpif_probe(struct platform_de + static struct resource *res, *res_irq; + struct platform_device *pdev_capture, *pdev_display; + struct device_node *endpoint = NULL; ++ int ret; + + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); + vpif_base = devm_ioremap_resource(&pdev->dev, res); +@@ -457,8 +458,8 @@ static int vpif_probe(struct platform_de + res_irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0); + if (!res_irq) { + dev_warn(&pdev->dev, "Missing IRQ resource.\n"); +- pm_runtime_put(&pdev->dev); +- return -EINVAL; ++ ret = -EINVAL; ++ goto err_put_rpm; + } + + pdev_capture = devm_kzalloc(&pdev->dev, sizeof(*pdev_capture), +@@ -492,6 +493,12 @@ static int vpif_probe(struct platform_de + } + + return 0; ++ ++err_put_rpm: ++ pm_runtime_put(&pdev->dev); ++ pm_runtime_disable(&pdev->dev); ++ ++ return ret; + } + + static int vpif_remove(struct platform_device *pdev) diff --git a/queue-5.15/media-davinci-vpif-fix-unbalanced-runtime-pm-get.patch b/queue-5.15/media-davinci-vpif-fix-unbalanced-runtime-pm-get.patch new file mode 100644 index 00000000000..4e2e5fba8cb --- /dev/null +++ b/queue-5.15/media-davinci-vpif-fix-unbalanced-runtime-pm-get.patch @@ -0,0 +1,33 @@ +From 4a321de239213300a714fa0353a5f1272d381a44 Mon Sep 17 00:00:00 2001 +From: Johan Hovold +Date: Wed, 22 Dec 2021 15:20:22 +0100 +Subject: media: davinci: vpif: fix unbalanced runtime PM get + +From: Johan Hovold + +commit 4a321de239213300a714fa0353a5f1272d381a44 upstream. + +Make sure to balance the runtime PM usage counter on driver unbind. + +Fixes: 407ccc65bfd2 ("[media] davinci: vpif: add pm_runtime support") +Cc: stable@vger.kernel.org # 3.9 +Cc: Lad, Prabhakar +Signed-off-by: Johan Hovold +Reviewed-by: Lad Prabhakar +Signed-off-by: Hans Verkuil +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman +--- + drivers/media/platform/davinci/vpif.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/media/platform/davinci/vpif.c ++++ b/drivers/media/platform/davinci/vpif.c +@@ -496,6 +496,7 @@ static int vpif_probe(struct platform_de + + static int vpif_remove(struct platform_device *pdev) + { ++ pm_runtime_put(&pdev->dev); + pm_runtime_disable(&pdev->dev); + return 0; + } diff --git a/queue-5.15/media-gpio-ir-tx-fix-transmit-with-long-spaces-on-orange-pi-pc.patch b/queue-5.15/media-gpio-ir-tx-fix-transmit-with-long-spaces-on-orange-pi-pc.patch new file mode 100644 index 00000000000..f7a3d0e1838 --- /dev/null +++ b/queue-5.15/media-gpio-ir-tx-fix-transmit-with-long-spaces-on-orange-pi-pc.patch @@ -0,0 +1,79 @@ +From 5ad05ecad4326ddaa26a83ba2233a67be24c1aaa Mon Sep 17 00:00:00 2001 +From: Sean Young +Date: Sun, 20 Feb 2022 15:28:24 +0100 +Subject: media: gpio-ir-tx: fix transmit with long spaces on Orange Pi PC +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Sean Young + +commit 5ad05ecad4326ddaa26a83ba2233a67be24c1aaa upstream. + +Calling udelay for than 1000us does not always yield the correct +results. + +Cc: stable@vger.kernel.org +Reported-by: Михаил +Signed-off-by: Sean Young +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman +--- + drivers/media/rc/gpio-ir-tx.c | 28 +++++++++++++++++++++------- + 1 file changed, 21 insertions(+), 7 deletions(-) + +--- a/drivers/media/rc/gpio-ir-tx.c ++++ b/drivers/media/rc/gpio-ir-tx.c +@@ -48,11 +48,29 @@ static int gpio_ir_tx_set_carrier(struct + return 0; + } + ++static void delay_until(ktime_t until) ++{ ++ /* ++ * delta should never exceed 0.5 seconds (IR_MAX_DURATION) and on ++ * m68k ndelay(s64) does not compile; so use s32 rather than s64. ++ */ ++ s32 delta; ++ ++ while (true) { ++ delta = ktime_us_delta(until, ktime_get()); ++ if (delta <= 0) ++ return; ++ ++ /* udelay more than 1ms may not work */ ++ delta = min(delta, 1000); ++ udelay(delta); ++ } ++} ++ + static void gpio_ir_tx_unmodulated(struct gpio_ir *gpio_ir, uint *txbuf, + uint count) + { + ktime_t edge; +- s32 delta; + int i; + + local_irq_disable(); +@@ -63,9 +81,7 @@ static void gpio_ir_tx_unmodulated(struc + gpiod_set_value(gpio_ir->gpio, !(i % 2)); + + edge = ktime_add_us(edge, txbuf[i]); +- delta = ktime_us_delta(edge, ktime_get()); +- if (delta > 0) +- udelay(delta); ++ delay_until(edge); + } + + gpiod_set_value(gpio_ir->gpio, 0); +@@ -97,9 +113,7 @@ static void gpio_ir_tx_modulated(struct + if (i % 2) { + // space + edge = ktime_add_us(edge, txbuf[i]); +- delta = ktime_us_delta(edge, ktime_get()); +- if (delta > 0) +- udelay(delta); ++ delay_until(edge); + } else { + // pulse + ktime_t last = ktime_add_us(edge, txbuf[i]); diff --git a/queue-5.15/media-venus-hfi_cmds-list-hdr10-property-as-unsupported-for-v1-and-v3.patch b/queue-5.15/media-venus-hfi_cmds-list-hdr10-property-as-unsupported-for-v1-and-v3.patch new file mode 100644 index 00000000000..dfaef89065e --- /dev/null +++ b/queue-5.15/media-venus-hfi_cmds-list-hdr10-property-as-unsupported-for-v1-and-v3.patch @@ -0,0 +1,32 @@ +From 22beb839f48d841ec75974872863dc253d37c21c Mon Sep 17 00:00:00 2001 +From: Stanimir Varbanov +Date: Tue, 1 Feb 2022 16:51:29 +0100 +Subject: media: venus: hfi_cmds: List HDR10 property as unsupported for v1 and v3 + +From: Stanimir Varbanov + +commit 22beb839f48d841ec75974872863dc253d37c21c upstream. + +The HFI_PROPERTY_PARAM_VENC_HDR10_PQ_SEI HFI property is not supported +on Venus v1 and v3. + +cc: stable@vger.kernel.org # 5.13+ +Fixes: 9172652d72f8 ("media: venus: venc: Add support for CLL and Mastering display controls") +Signed-off-by: Stanimir Varbanov +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman +--- + drivers/media/platform/qcom/venus/hfi_cmds.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/media/platform/qcom/venus/hfi_cmds.c ++++ b/drivers/media/platform/qcom/venus/hfi_cmds.c +@@ -1054,6 +1054,8 @@ static int pkt_session_set_property_1x(s + pkt->shdr.hdr.size += sizeof(u32) + sizeof(*info); + break; + } ++ case HFI_PROPERTY_PARAM_VENC_HDR10_PQ_SEI: ++ return -ENOTSUPP; + + /* FOLLOWING PROPERTIES ARE NOT IMPLEMENTED IN CORE YET */ + case HFI_PROPERTY_CONFIG_BUFFER_REQUIREMENTS: diff --git a/queue-5.15/media-venus-venc-fix-h264-8x8-transform-control.patch b/queue-5.15/media-venus-venc-fix-h264-8x8-transform-control.patch new file mode 100644 index 00000000000..8e7b8c65a24 --- /dev/null +++ b/queue-5.15/media-venus-venc-fix-h264-8x8-transform-control.patch @@ -0,0 +1,66 @@ +From 61b3317dd424a3488b6754d7ff8301944d9d17d7 Mon Sep 17 00:00:00 2001 +From: Stanimir Varbanov +Date: Tue, 8 Feb 2022 02:18:16 +0100 +Subject: media: venus: venc: Fix h264 8x8 transform control + +From: Stanimir Varbanov + +commit 61b3317dd424a3488b6754d7ff8301944d9d17d7 upstream. + +During encoder driver open controls are initialized via a call +to v4l2_ctrl_handler_setup which returns EINVAL error for +V4L2_CID_MPEG_VIDEO_H264_8X8_TRANSFORM v4l2 control. The control +default value is disabled and because of firmware limitations +8x8 transform cannot be disabled for the supported HIGH and +CONSTRAINED_HIGH profiles. + +To fix the issue change the control default value to enabled +(this is fine because the firmware enables 8x8 transform for +high and constrained_high profiles by default). Also, correct +the checking of profile ids in s_ctrl from hfi to v4l2 ids. + +cc: stable@vger.kernel.org # 5.15+ +Fixes: bfee75f73c37 ("media: venus: venc: add support for V4L2_CID_MPEG_VIDEO_H264_8X8_TRANSFORM control") +Signed-off-by: Stanimir Varbanov +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman +--- + drivers/media/platform/qcom/venus/venc.c | 4 ++-- + drivers/media/platform/qcom/venus/venc_ctrls.c | 6 +++--- + 2 files changed, 5 insertions(+), 5 deletions(-) + +--- a/drivers/media/platform/qcom/venus/venc.c ++++ b/drivers/media/platform/qcom/venus/venc.c +@@ -604,8 +604,8 @@ static int venc_set_properties(struct ve + + ptype = HFI_PROPERTY_PARAM_VENC_H264_TRANSFORM_8X8; + h264_transform.enable_type = 0; +- if (ctr->profile.h264 == HFI_H264_PROFILE_HIGH || +- ctr->profile.h264 == HFI_H264_PROFILE_CONSTRAINED_HIGH) ++ if (ctr->profile.h264 == V4L2_MPEG_VIDEO_H264_PROFILE_HIGH || ++ ctr->profile.h264 == V4L2_MPEG_VIDEO_H264_PROFILE_CONSTRAINED_HIGH) + h264_transform.enable_type = ctr->h264_8x8_transform; + + ret = hfi_session_set_property(inst, ptype, &h264_transform); +--- a/drivers/media/platform/qcom/venus/venc_ctrls.c ++++ b/drivers/media/platform/qcom/venus/venc_ctrls.c +@@ -320,8 +320,8 @@ static int venc_op_s_ctrl(struct v4l2_ct + ctr->intra_refresh_period = ctrl->val; + break; + case V4L2_CID_MPEG_VIDEO_H264_8X8_TRANSFORM: +- if (ctr->profile.h264 != HFI_H264_PROFILE_HIGH && +- ctr->profile.h264 != HFI_H264_PROFILE_CONSTRAINED_HIGH) ++ if (ctr->profile.h264 != V4L2_MPEG_VIDEO_H264_PROFILE_HIGH && ++ ctr->profile.h264 != V4L2_MPEG_VIDEO_H264_PROFILE_CONSTRAINED_HIGH) + return -EINVAL; + + /* +@@ -457,7 +457,7 @@ int venc_ctrl_init(struct venus_inst *in + V4L2_CID_MPEG_VIDEO_H264_I_FRAME_MIN_QP, 1, 51, 1, 1); + + v4l2_ctrl_new_std(&inst->ctrl_handler, &venc_ctrl_ops, +- V4L2_CID_MPEG_VIDEO_H264_8X8_TRANSFORM, 0, 1, 1, 0); ++ V4L2_CID_MPEG_VIDEO_H264_8X8_TRANSFORM, 0, 1, 1, 1); + + v4l2_ctrl_new_std(&inst->ctrl_handler, &venc_ctrl_ops, + V4L2_CID_MPEG_VIDEO_H264_P_FRAME_MIN_QP, 1, 51, 1, 1); diff --git a/queue-5.15/mgag200-fix-memmapsl-configuration-in-gctl6-register.patch b/queue-5.15/mgag200-fix-memmapsl-configuration-in-gctl6-register.patch new file mode 100644 index 00000000000..c4d6a70770b --- /dev/null +++ b/queue-5.15/mgag200-fix-memmapsl-configuration-in-gctl6-register.patch @@ -0,0 +1,83 @@ +From 028a73e10705af1ffd51f2537460f616dc58680e Mon Sep 17 00:00:00 2001 +From: Jocelyn Falempe +Date: Wed, 19 Jan 2022 11:29:05 +0100 +Subject: mgag200 fix memmapsl configuration in GCTL6 register +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Jocelyn Falempe + +commit 028a73e10705af1ffd51f2537460f616dc58680e upstream. + +On some servers with MGA G200_SE_A (rev 42), booting with Legacy BIOS, +the hardware hangs when using kdump and kexec into the kdump kernel. +This happens when the uncompress code tries to write "Decompressing Linux" +to the VGA Console. + +It can be reproduced by writing to the VGA console (0xB8000) after +booting to graphic mode, it generates the following error: + +kernel:NMI: PCI system error (SERR) for reason a0 on CPU 0. +kernel:Dazed and confused, but trying to continue + +The root cause is the configuration of the MGA GCTL6 register + +According to the GCTL6 register documentation: + +bit 0 is gcgrmode: + 0: Enables alpha mode, and the character generator addressing system is + activated. + 1: Enables graphics mode, and the character addressing system is not + used. + +bit 1 is chainodd even: + 0: The A0 signal of the memory address bus is used during system memory + addressing. + 1: Allows A0 to be replaced by either the A16 signal of the system + address (ifmemmapsl is ‘00’), or by the hpgoddev (MISC<5>, odd/even + page select) field, described on page 3-294). + +bit 3-2 are memmapsl: + Memory map select bits 1 and 0. VGA. + These bits select where the video memory is mapped, as shown below: + 00 => A0000h - BFFFFh + 01 => A0000h - AFFFFh + 10 => B0000h - B7FFFh + 11 => B8000h - BFFFFh + +bit 7-4 are reserved. + +Current code set it to 0x05 => memmapsl to b01 => 0xa0000 (graphic mode) +But on x86, the VGA console is at 0xb8000 (text mode) +In arch/x86/boot/compressed/misc.c debug strings are written to 0xb8000 +As the driver doesn't use this mapping at 0xa0000, it is safe to set it to +0xb8000 instead, to avoid kernel hang on G200_SE_A rev42, with kexec/kdump. + +Thus changing the value 0x05 to 0x0d + +Signed-off-by: Jocelyn Falempe +Reviewed-by: Javier Martinez Canillas +Acked-by: Lyude Paul +Cc: stable@vger.kernel.org +Signed-off-by: Thomas Zimmermann +Link: https://patchwork.freedesktop.org/patch/msgid/20220119102905.1194787-1-jfalempe@redhat.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/mgag200/mgag200_mode.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +--- a/drivers/gpu/drm/mgag200/mgag200_mode.c ++++ b/drivers/gpu/drm/mgag200/mgag200_mode.c +@@ -529,7 +529,10 @@ static void mgag200_set_format_regs(stru + WREG_GFX(3, 0x00); + WREG_GFX(4, 0x00); + WREG_GFX(5, 0x40); +- WREG_GFX(6, 0x05); ++ /* GCTL6 should be 0x05, but we configure memmapsl to 0xb8000 (text mode), ++ * so that it doesn't hang when running kexec/kdump on G200_SE rev42. ++ */ ++ WREG_GFX(6, 0x0d); + WREG_GFX(7, 0x0f); + WREG_GFX(8, 0x0f); + diff --git a/queue-5.15/mm-hwpoison-unmap-poisoned-page-before-invalidation.patch b/queue-5.15/mm-hwpoison-unmap-poisoned-page-before-invalidation.patch new file mode 100644 index 00000000000..1a71324fb94 --- /dev/null +++ b/queue-5.15/mm-hwpoison-unmap-poisoned-page-before-invalidation.patch @@ -0,0 +1,67 @@ +From 3149c79f3cb0e2e3bafb7cfadacec090cbd250d3 Mon Sep 17 00:00:00 2001 +From: Rik van Riel +Date: Fri, 1 Apr 2022 11:28:42 -0700 +Subject: mm,hwpoison: unmap poisoned page before invalidation + +From: Rik van Riel + +commit 3149c79f3cb0e2e3bafb7cfadacec090cbd250d3 upstream. + +In some cases it appears the invalidation of a hwpoisoned page fails +because the page is still mapped in another process. This can cause a +program to be continuously restarted and die when it page faults on the +page that was not invalidated. Avoid that problem by unmapping the +hwpoisoned page when we find it. + +Another issue is that sometimes we end up oopsing in finish_fault, if +the code tries to do something with the now-NULL vmf->page. I did not +hit this error when submitting the previous patch because there are +several opportunities for alloc_set_pte to bail out before accessing +vmf->page, and that apparently happened on those systems, and most of +the time on other systems, too. + +However, across several million systems that error does occur a handful +of times a day. It can be avoided by returning VM_FAULT_NOPAGE which +will cause do_read_fault to return before calling finish_fault. + +Link: https://lkml.kernel.org/r/20220325161428.5068d97e@imladris.surriel.com +Fixes: e53ac7374e64 ("mm: invalidate hwpoison page cache page in fault path") +Signed-off-by: Rik van Riel +Reviewed-by: Miaohe Lin +Tested-by: Naoya Horiguchi +Reviewed-by: Oscar Salvador +Cc: Mel Gorman +Cc: Johannes Weiner +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + mm/memory.c | 12 ++++++++---- + 1 file changed, 8 insertions(+), 4 deletions(-) + +--- a/mm/memory.c ++++ b/mm/memory.c +@@ -3861,14 +3861,18 @@ static vm_fault_t __do_fault(struct vm_f + return ret; + + if (unlikely(PageHWPoison(vmf->page))) { ++ struct page *page = vmf->page; + vm_fault_t poisonret = VM_FAULT_HWPOISON; + if (ret & VM_FAULT_LOCKED) { ++ if (page_mapped(page)) ++ unmap_mapping_pages(page_mapping(page), ++ page->index, 1, false); + /* Retry if a clean page was removed from the cache. */ +- if (invalidate_inode_page(vmf->page)) +- poisonret = 0; +- unlock_page(vmf->page); ++ if (invalidate_inode_page(page)) ++ poisonret = VM_FAULT_NOPAGE; ++ unlock_page(page); + } +- put_page(vmf->page); ++ put_page(page); + vmf->page = NULL; + return poisonret; + } diff --git a/queue-5.15/mm-kmemleak-reset-tag-when-compare-object-pointer.patch b/queue-5.15/mm-kmemleak-reset-tag-when-compare-object-pointer.patch new file mode 100644 index 00000000000..5c39e8d79e7 --- /dev/null +++ b/queue-5.15/mm-kmemleak-reset-tag-when-compare-object-pointer.patch @@ -0,0 +1,99 @@ +From bfc8089f00fa526dea983844c880fa8106c33ac4 Mon Sep 17 00:00:00 2001 +From: Kuan-Ying Lee +Date: Fri, 1 Apr 2022 11:28:54 -0700 +Subject: mm/kmemleak: reset tag when compare object pointer + +From: Kuan-Ying Lee + +commit bfc8089f00fa526dea983844c880fa8106c33ac4 upstream. + +When we use HW-tag based kasan and enable vmalloc support, we hit the +following bug. It is due to comparison between tagged object and +non-tagged pointer. + +We need to reset the kasan tag when we need to compare tagged object and +non-tagged pointer. + + kmemleak: [name:kmemleak&]Scan area larger than object 0xffffffe77076f440 + CPU: 4 PID: 1 Comm: init Tainted: G S W 5.15.25-android13-0-g5cacf919c2bc #1 + Hardware name: MT6983(ENG) (DT) + Call trace: + add_scan_area+0xc4/0x244 + kmemleak_scan_area+0x40/0x9c + layout_and_allocate+0x1e8/0x288 + load_module+0x2c8/0xf00 + __se_sys_finit_module+0x190/0x1d0 + __arm64_sys_finit_module+0x20/0x30 + invoke_syscall+0x60/0x170 + el0_svc_common+0xc8/0x114 + do_el0_svc+0x28/0xa0 + el0_svc+0x60/0xf8 + el0t_64_sync_handler+0x88/0xec + el0t_64_sync+0x1b4/0x1b8 + kmemleak: [name:kmemleak&]Object 0xf5ffffe77076b000 (size 32768): + kmemleak: [name:kmemleak&] comm "init", pid 1, jiffies 4294894197 + kmemleak: [name:kmemleak&] min_count = 0 + kmemleak: [name:kmemleak&] count = 0 + kmemleak: [name:kmemleak&] flags = 0x1 + kmemleak: [name:kmemleak&] checksum = 0 + kmemleak: [name:kmemleak&] backtrace: + module_alloc+0x9c/0x120 + move_module+0x34/0x19c + layout_and_allocate+0x1c4/0x288 + load_module+0x2c8/0xf00 + __se_sys_finit_module+0x190/0x1d0 + __arm64_sys_finit_module+0x20/0x30 + invoke_syscall+0x60/0x170 + el0_svc_common+0xc8/0x114 + do_el0_svc+0x28/0xa0 + el0_svc+0x60/0xf8 + el0t_64_sync_handler+0x88/0xec + el0t_64_sync+0x1b4/0x1b8 + +Link: https://lkml.kernel.org/r/20220318034051.30687-1-Kuan-Ying.Lee@mediatek.com +Signed-off-by: Kuan-Ying Lee +Reviewed-by: Catalin Marinas +Cc: Matthias Brugger +Cc: Chinwen Chang +Cc: Nicholas Tang +Cc: Yee Lee +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + mm/kmemleak.c | 9 +++++++-- + 1 file changed, 7 insertions(+), 2 deletions(-) + +--- a/mm/kmemleak.c ++++ b/mm/kmemleak.c +@@ -789,6 +789,8 @@ static void add_scan_area(unsigned long + unsigned long flags; + struct kmemleak_object *object; + struct kmemleak_scan_area *area = NULL; ++ unsigned long untagged_ptr; ++ unsigned long untagged_objp; + + object = find_and_get_object(ptr, 1); + if (!object) { +@@ -797,6 +799,9 @@ static void add_scan_area(unsigned long + return; + } + ++ untagged_ptr = (unsigned long)kasan_reset_tag((void *)ptr); ++ untagged_objp = (unsigned long)kasan_reset_tag((void *)object->pointer); ++ + if (scan_area_cache) + area = kmem_cache_alloc(scan_area_cache, gfp_kmemleak_mask(gfp)); + +@@ -808,8 +813,8 @@ static void add_scan_area(unsigned long + goto out_unlock; + } + if (size == SIZE_MAX) { +- size = object->pointer + object->size - ptr; +- } else if (ptr + size > object->pointer + object->size) { ++ size = untagged_objp + object->size - untagged_ptr; ++ } else if (untagged_ptr + size > untagged_objp + object->size) { + kmemleak_warn("Scan area larger than object 0x%08lx\n", ptr); + dump_object_info(object); + kmem_cache_free(scan_area_cache, area); diff --git a/queue-5.15/mm-madvise-return-correct-bytes-advised-with-process_madvise.patch b/queue-5.15/mm-madvise-return-correct-bytes-advised-with-process_madvise.patch new file mode 100644 index 00000000000..99694507c5f --- /dev/null +++ b/queue-5.15/mm-madvise-return-correct-bytes-advised-with-process_madvise.patch @@ -0,0 +1,64 @@ +From 5bd009c7c9a9e888077c07535dc0c70aeab242c3 Mon Sep 17 00:00:00 2001 +From: Charan Teja Kalla +Date: Tue, 22 Mar 2022 14:46:44 -0700 +Subject: mm: madvise: return correct bytes advised with process_madvise + +From: Charan Teja Kalla + +commit 5bd009c7c9a9e888077c07535dc0c70aeab242c3 upstream. + +Patch series "mm: madvise: return correct bytes processed with +process_madvise", v2. With the process_madvise(), always choose to return +non zero processed bytes over an error. This can help the user to know on +which VMA, passed in the 'struct iovec' vector list, is failed to advise +thus can take the decission of retrying/skipping on that VMA. + +This patch (of 2): + +The process_madvise() system call returns error even after processing some +VMA's passed in the 'struct iovec' vector list which leaves the user +confused to know where to restart the advise next. It is also against +this syscall man page[1] documentation where it mentions that "return +value may be less than the total number of requested bytes, if an error +occurred after some iovec elements were already processed.". + +Consider a user passed 10 VMA's in the 'struct iovec' vector list of which +9 are processed but one. Then it just returns the error caused on that +failed VMA despite the first 9 VMA's processed, leaving the user confused +about on which VMA it is failed. Returning the number of bytes processed +here can help the user to know which VMA it is failed on and thus can +retry/skip the advise on that VMA. + +[1]https://man7.org/linux/man-pages/man2/process_madvise.2.html. + +Link: https://lkml.kernel.org/r/cover.1647008754.git.quic_charante@quicinc.com +Link: https://lkml.kernel.org/r/125b61a0edcee5c2db8658aed9d06a43a19ccafc.1647008754.git.quic_charante@quicinc.com +Fixes: ecb8ac8b1f14("mm/madvise: introduce process_madvise() syscall: an external memory hinting API") +Signed-off-by: Charan Teja Kalla +Cc: Suren Baghdasaryan +Cc: Vlastimil Babka +Cc: David Rientjes +Cc: Stephen Rothwell +Cc: Minchan Kim +Cc: Nadav Amit +Cc: Michal Hocko +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + mm/madvise.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/mm/madvise.c ++++ b/mm/madvise.c +@@ -1301,8 +1301,7 @@ SYSCALL_DEFINE5(process_madvise, int, pi + iov_iter_advance(&iter, iovec.iov_len); + } + +- if (ret == 0) +- ret = total_len - iov_iter_count(&iter); ++ ret = (total_len - iov_iter_count(&iter)) ? : ret; + + release_mm: + mmput(mm); diff --git a/queue-5.15/mm-madvise-skip-unmapped-vma-holes-passed-to-process_madvise.patch b/queue-5.15/mm-madvise-skip-unmapped-vma-holes-passed-to-process_madvise.patch new file mode 100644 index 00000000000..39645b7229a --- /dev/null +++ b/queue-5.15/mm-madvise-skip-unmapped-vma-holes-passed-to-process_madvise.patch @@ -0,0 +1,57 @@ +From 08095d6310a7ce43256b4251577bc66a25c6e1a6 Mon Sep 17 00:00:00 2001 +From: Charan Teja Kalla +Date: Tue, 22 Mar 2022 14:46:48 -0700 +Subject: mm: madvise: skip unmapped vma holes passed to process_madvise + +From: Charan Teja Kalla + +commit 08095d6310a7ce43256b4251577bc66a25c6e1a6 upstream. + +The process_madvise() system call is expected to skip holes in vma passed +through 'struct iovec' vector list. But do_madvise, which +process_madvise() calls for each vma, returns ENOMEM in case of unmapped +holes, despite the VMA is processed. + +Thus process_madvise() should treat ENOMEM as expected and consider the +VMA passed to as processed and continue processing other vma's in the +vector list. Returning -ENOMEM to user, despite the VMA is processed, +will be unable to figure out where to start the next madvise. + +Link: https://lkml.kernel.org/r/4f091776142f2ebf7b94018146de72318474e686.1647008754.git.quic_charante@quicinc.com +Fixes: ecb8ac8b1f14("mm/madvise: introduce process_madvise() syscall: an external memory hinting API") +Signed-off-by: Charan Teja Kalla +Cc: David Rientjes +Cc: Michal Hocko +Cc: Minchan Kim +Cc: Nadav Amit +Cc: Stephen Rothwell +Cc: Suren Baghdasaryan +Cc: Vlastimil Babka +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + mm/madvise.c | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +--- a/mm/madvise.c ++++ b/mm/madvise.c +@@ -1287,9 +1287,16 @@ SYSCALL_DEFINE5(process_madvise, int, pi + + while (iov_iter_count(&iter)) { + iovec = iov_iter_iovec(&iter); ++ /* ++ * do_madvise returns ENOMEM if unmapped holes are present ++ * in the passed VMA. process_madvise() is expected to skip ++ * unmapped holes passed to it in the 'struct iovec' list ++ * and not fail because of them. Thus treat -ENOMEM return ++ * from do_madvise as valid and continue processing. ++ */ + ret = do_madvise(mm, (unsigned long)iovec.iov_base, + iovec.iov_len, behavior); +- if (ret < 0) ++ if (ret < 0 && ret != -ENOMEM) + break; + iov_iter_advance(&iter, iovec.iov_len); + } diff --git a/queue-5.15/pci-fu740-force-2.5gt-s-for-initial-device-probe.patch b/queue-5.15/pci-fu740-force-2.5gt-s-for-initial-device-probe.patch new file mode 100644 index 00000000000..ca5ce02c944 --- /dev/null +++ b/queue-5.15/pci-fu740-force-2.5gt-s-for-initial-device-probe.patch @@ -0,0 +1,92 @@ +From a382c757ec5ef83137a86125f43a4c43dc2ab50b Mon Sep 17 00:00:00 2001 +From: Ben Dooks +Date: Fri, 18 Mar 2022 15:24:30 +0000 +Subject: PCI: fu740: Force 2.5GT/s for initial device probe + +From: Ben Dooks + +commit a382c757ec5ef83137a86125f43a4c43dc2ab50b upstream. + +The fu740 PCIe core does not probe any devices on the SiFive Unmatched +board without this fix (or having U-Boot explicitly start the PCIe via +either boot-script or user command). The fix is to start the link at +2.5GT/s speeds and once the link is up then change the maximum speed back +to the default. + +The U-Boot driver claims to set the link-speed to 2.5GT/s to get the probe +to work (and U-Boot does print link up at 2.5GT/s) in the following code: +https://source.denx.de/u-boot/u-boot/-/blob/master/drivers/pci/pcie_dw_sifive.c?id=v2022.01#L271 + +Link: https://lore.kernel.org/r/20220318152430.526320-1-ben.dooks@codethink.co.uk +Signed-off-by: Ben Dooks +Signed-off-by: Bjorn Helgaas +Acked-by: Palmer Dabbelt +Signed-off-by: Dimitri John Ledkov +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/controller/dwc/pcie-fu740.c | 51 +++++++++++++++++++++++++++++++- + 1 file changed, 50 insertions(+), 1 deletion(-) + +--- a/drivers/pci/controller/dwc/pcie-fu740.c ++++ b/drivers/pci/controller/dwc/pcie-fu740.c +@@ -181,10 +181,59 @@ static int fu740_pcie_start_link(struct + { + struct device *dev = pci->dev; + struct fu740_pcie *afp = dev_get_drvdata(dev); ++ u8 cap_exp = dw_pcie_find_capability(pci, PCI_CAP_ID_EXP); ++ int ret; ++ u32 orig, tmp; ++ ++ /* ++ * Force 2.5GT/s when starting the link, due to some devices not ++ * probing at higher speeds. This happens with the PCIe switch ++ * on the Unmatched board when U-Boot has not initialised the PCIe. ++ * The fix in U-Boot is to force 2.5GT/s, which then gets cleared ++ * by the soft reset done by this driver. ++ */ ++ dev_dbg(dev, "cap_exp at %x\n", cap_exp); ++ dw_pcie_dbi_ro_wr_en(pci); ++ ++ tmp = dw_pcie_readl_dbi(pci, cap_exp + PCI_EXP_LNKCAP); ++ orig = tmp & PCI_EXP_LNKCAP_SLS; ++ tmp &= ~PCI_EXP_LNKCAP_SLS; ++ tmp |= PCI_EXP_LNKCAP_SLS_2_5GB; ++ dw_pcie_writel_dbi(pci, cap_exp + PCI_EXP_LNKCAP, tmp); + + /* Enable LTSSM */ + writel_relaxed(0x1, afp->mgmt_base + PCIEX8MGMT_APP_LTSSM_ENABLE); +- return 0; ++ ++ ret = dw_pcie_wait_for_link(pci); ++ if (ret) { ++ dev_err(dev, "error: link did not start\n"); ++ goto err; ++ } ++ ++ tmp = dw_pcie_readl_dbi(pci, cap_exp + PCI_EXP_LNKCAP); ++ if ((tmp & PCI_EXP_LNKCAP_SLS) != orig) { ++ dev_dbg(dev, "changing speed back to original\n"); ++ ++ tmp &= ~PCI_EXP_LNKCAP_SLS; ++ tmp |= orig; ++ dw_pcie_writel_dbi(pci, cap_exp + PCI_EXP_LNKCAP, tmp); ++ ++ tmp = dw_pcie_readl_dbi(pci, PCIE_LINK_WIDTH_SPEED_CONTROL); ++ tmp |= PORT_LOGIC_SPEED_CHANGE; ++ dw_pcie_writel_dbi(pci, PCIE_LINK_WIDTH_SPEED_CONTROL, tmp); ++ ++ ret = dw_pcie_wait_for_link(pci); ++ if (ret) { ++ dev_err(dev, "error: link did not start at new speed\n"); ++ goto err; ++ } ++ } ++ ++ ret = 0; ++err: ++ WARN_ON(ret); /* we assume that errors will be very rare */ ++ dw_pcie_dbi_ro_wr_dis(pci); ++ return ret; + } + + static int fu740_pcie_host_init(struct pcie_port *pp) diff --git a/queue-5.15/pci-imx6-allow-to-probe-when-dw_pcie_wait_for_link-fails.patch b/queue-5.15/pci-imx6-allow-to-probe-when-dw_pcie_wait_for_link-fails.patch new file mode 100644 index 00000000000..08c3f5f9e28 --- /dev/null +++ b/queue-5.15/pci-imx6-allow-to-probe-when-dw_pcie_wait_for_link-fails.patch @@ -0,0 +1,80 @@ +From f81f095e87715e198471f4653952fe5e3f824874 Mon Sep 17 00:00:00 2001 +From: Fabio Estevam +Date: Thu, 6 Jan 2022 07:36:45 -0300 +Subject: PCI: imx6: Allow to probe when dw_pcie_wait_for_link() fails + +From: Fabio Estevam + +commit f81f095e87715e198471f4653952fe5e3f824874 upstream. + +The intention of commit 886a9c134755 ("PCI: dwc: Move link handling into +common code") was to standardize the behavior of link down as explained +in its commit log: + +"The behavior for a link down was inconsistent as some drivers would fail +probe in that case while others succeed. Let's standardize this to +succeed as there are usecases where devices (and the link) appear later +even without hotplug. For example, a reconfigured FPGA device." + +The pci-imx6 still fails to probe when the link is not present, which +causes the following warning: + +imx6q-pcie 8ffc000.pcie: Phy link never came up +imx6q-pcie: probe of 8ffc000.pcie failed with error -110 +------------[ cut here ]------------ +WARNING: CPU: 0 PID: 30 at drivers/regulator/core.c:2257 _regulator_put.part.0+0x1b8/0x1dc +Modules linked in: +CPU: 0 PID: 30 Comm: kworker/u2:2 Not tainted 5.15.0-next-20211103 #1 +Hardware name: Freescale i.MX6 SoloX (Device Tree) +Workqueue: events_unbound async_run_entry_fn +[] (unwind_backtrace) from [] (show_stack+0x10/0x14) +[] (show_stack) from [] (dump_stack_lvl+0x58/0x70) +[] (dump_stack_lvl) from [] (__warn+0xd4/0x154) +[] (__warn) from [] (warn_slowpath_fmt+0x74/0xa8) +[] (warn_slowpath_fmt) from [] (_regulator_put.part.0+0x1b8/0x1dc) +[] (_regulator_put.part.0) from [] (regulator_put+0x2c/0x3c) +[] (regulator_put) from [] (release_nodes+0x50/0x178) + +Fix this problem by ignoring the dw_pcie_wait_for_link() error like +it is done on the other dwc drivers. + +Tested on imx6sx-sdb and imx6q-sabresd boards. + +Link: https://lore.kernel.org/r/20220106103645.2790803-1-festevam@gmail.com +Fixes: 886a9c134755 ("PCI: dwc: Move link handling into common code") +Signed-off-by: Fabio Estevam +Signed-off-by: Lorenzo Pieralisi +Reviewed-by: Rob Herring +Reviewed-by: Richard Zhu +Cc: +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/controller/dwc/pci-imx6.c | 10 ++-------- + 1 file changed, 2 insertions(+), 8 deletions(-) + +--- a/drivers/pci/controller/dwc/pci-imx6.c ++++ b/drivers/pci/controller/dwc/pci-imx6.c +@@ -779,9 +779,7 @@ static int imx6_pcie_start_link(struct d + /* Start LTSSM. */ + imx6_pcie_ltssm_enable(dev); + +- ret = dw_pcie_wait_for_link(pci); +- if (ret) +- goto err_reset_phy; ++ dw_pcie_wait_for_link(pci); + + if (pci->link_gen == 2) { + /* Allow Gen2 mode after the link is up. */ +@@ -817,11 +815,7 @@ static int imx6_pcie_start_link(struct d + } + + /* Make sure link training is finished as well! */ +- ret = dw_pcie_wait_for_link(pci); +- if (ret) { +- dev_err(dev, "Failed to bring link up!\n"); +- goto err_reset_phy; +- } ++ dw_pcie_wait_for_link(pci); + } else { + dev_info(dev, "Link: Gen2 disabled\n"); + } diff --git a/queue-5.15/pci-pciehp-clear-cmd_busy-bit-in-polling-mode.patch b/queue-5.15/pci-pciehp-clear-cmd_busy-bit-in-polling-mode.patch new file mode 100644 index 00000000000..0b559c27153 --- /dev/null +++ b/queue-5.15/pci-pciehp-clear-cmd_busy-bit-in-polling-mode.patch @@ -0,0 +1,53 @@ +From 92912b175178c7e895f5e5e9f1e30ac30319162b Mon Sep 17 00:00:00 2001 +From: Liguang Zhang +Date: Thu, 11 Nov 2021 13:42:58 +0800 +Subject: PCI: pciehp: Clear cmd_busy bit in polling mode + +From: Liguang Zhang + +commit 92912b175178c7e895f5e5e9f1e30ac30319162b upstream. + +Writes to a Downstream Port's Slot Control register are PCIe hotplug +"commands." If the Port supports Command Completed events, software must +wait for a command to complete before writing to Slot Control again. + +pcie_do_write_cmd() sets ctrl->cmd_busy when it writes to Slot Control. If +software notification is enabled, i.e., PCI_EXP_SLTCTL_HPIE and +PCI_EXP_SLTCTL_CCIE are set, ctrl->cmd_busy is cleared by pciehp_isr(). + +But when software notification is disabled, as it is when pcie_init() +powers off an empty slot, pcie_wait_cmd() uses pcie_poll_cmd() to poll for +command completion, and it neglects to clear ctrl->cmd_busy, which leads to +spurious timeouts: + + pcieport 0000:00:03.0: pciehp: Timeout on hotplug command 0x01c0 (issued 2264 msec ago) + pcieport 0000:00:03.0: pciehp: Timeout on hotplug command 0x05c0 (issued 2288 msec ago) + +Clear ctrl->cmd_busy in pcie_poll_cmd() when it detects a Command Completed +event (PCI_EXP_SLTSTA_CC). + +[bhelgaas: commit log] +Fixes: a5dd4b4b0570 ("PCI: pciehp: Wait for hotplug command completion where necessary") +Link: https://lore.kernel.org/r/20211111054258.7309-1-zhangliguang@linux.alibaba.com +Link: https://bugzilla.kernel.org/show_bug.cgi?id=215143 +Link: https://lore.kernel.org/r/20211126173309.GA12255@wunner.de +Signed-off-by: Liguang Zhang +Signed-off-by: Bjorn Helgaas +Reviewed-by: Lukas Wunner +Cc: stable@vger.kernel.org # v4.19+ +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/hotplug/pciehp_hpc.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/pci/hotplug/pciehp_hpc.c ++++ b/drivers/pci/hotplug/pciehp_hpc.c +@@ -98,6 +98,8 @@ static int pcie_poll_cmd(struct controll + if (slot_status & PCI_EXP_SLTSTA_CC) { + pcie_capability_write_word(pdev, PCI_EXP_SLTSTA, + PCI_EXP_SLTSTA_CC); ++ ctrl->cmd_busy = 0; ++ smp_mb(); + return 1; + } + msleep(10); diff --git a/queue-5.15/pci-xgene-revert-pci-xgene-fix-ib-window-setup.patch b/queue-5.15/pci-xgene-revert-pci-xgene-fix-ib-window-setup.patch new file mode 100644 index 00000000000..9ca5dc690a6 --- /dev/null +++ b/queue-5.15/pci-xgene-revert-pci-xgene-fix-ib-window-setup.patch @@ -0,0 +1,49 @@ +From 825da4e9cec68713fbb02dc6f71fe1bf65fe8050 Mon Sep 17 00:00:00 2001 +From: Marc Zyngier +Date: Mon, 21 Mar 2022 10:48:43 +0000 +Subject: PCI: xgene: Revert "PCI: xgene: Fix IB window setup" +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Marc Zyngier + +commit 825da4e9cec68713fbb02dc6f71fe1bf65fe8050 upstream. + +Commit c7a75d07827a ("PCI: xgene: Fix IB window setup") tried to +fix the damages that 6dce5aa59e0b ("PCI: xgene: Use inbound resources +for setup") caused, but actually didn't improve anything for some +plarforms (at least Mustang and m400 are still broken). + +Given that 6dce5aa59e0b has been reverted, revert this patch as well, +restoring the PCIe support on XGene to its pre-5.5, working state. + +Link: https://lore.kernel.org/r/YjN8pT5e6/8cRohQ@xps13.dannf +Link: https://lore.kernel.org/r/20220321104843.949645-3-maz@kernel.org +Fixes: c7a75d07827a ("PCI: xgene: Fix IB window setup") +Signed-off-by: Marc Zyngier +Signed-off-by: Lorenzo Pieralisi +Cc: stable@vger.kernel.org +Cc: Rob Herring +Cc: Toan Le +Cc: Lorenzo Pieralisi +Cc: Krzysztof Wilczyński +Cc: Bjorn Helgaas +Cc: Stéphane Graber +Cc: dann frazier +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/controller/pci-xgene.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/pci/controller/pci-xgene.c ++++ b/drivers/pci/controller/pci-xgene.c +@@ -466,7 +466,7 @@ static int xgene_pcie_select_ib_reg(u8 * + return 1; + } + +- if ((size > SZ_1K) && (size < SZ_4G) && !(*ib_reg_mask & (1 << 0))) { ++ if ((size > SZ_1K) && (size < SZ_1T) && !(*ib_reg_mask & (1 << 0))) { + *ib_reg_mask |= (1 << 0); + return 0; + } diff --git a/queue-5.15/pm-domains-fix-sleep-in-atomic-bug-caused-by-genpd_debug_remove.patch b/queue-5.15/pm-domains-fix-sleep-in-atomic-bug-caused-by-genpd_debug_remove.patch new file mode 100644 index 00000000000..e83d25ec355 --- /dev/null +++ b/queue-5.15/pm-domains-fix-sleep-in-atomic-bug-caused-by-genpd_debug_remove.patch @@ -0,0 +1,74 @@ +From f6bfe8b5b2c2a5ac8bd2fc7bca3706e6c3fc26d8 Mon Sep 17 00:00:00 2001 +From: Shawn Guo +Date: Fri, 25 Feb 2022 14:48:15 +0800 +Subject: PM: domains: Fix sleep-in-atomic bug caused by genpd_debug_remove() + +From: Shawn Guo + +commit f6bfe8b5b2c2a5ac8bd2fc7bca3706e6c3fc26d8 upstream. + +When a genpd with GENPD_FLAG_IRQ_SAFE gets removed, the following +sleep-in-atomic bug will be seen, as genpd_debug_remove() will be called +with a spinlock being held. + +[ 0.029183] BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1460 +[ 0.029204] in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 1, name: swapper/0 +[ 0.029219] preempt_count: 1, expected: 0 +[ 0.029230] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.17.0-rc4+ #489 +[ 0.029245] Hardware name: Thundercomm TurboX CM2290 (DT) +[ 0.029256] Call trace: +[ 0.029265] dump_backtrace.part.0+0xbc/0xd0 +[ 0.029285] show_stack+0x3c/0xa0 +[ 0.029298] dump_stack_lvl+0x7c/0xa0 +[ 0.029311] dump_stack+0x18/0x34 +[ 0.029323] __might_resched+0x10c/0x13c +[ 0.029338] __might_sleep+0x4c/0x80 +[ 0.029351] down_read+0x24/0xd0 +[ 0.029363] lookup_one_len_unlocked+0x9c/0xcc +[ 0.029379] lookup_positive_unlocked+0x10/0x50 +[ 0.029392] debugfs_lookup+0x68/0xac +[ 0.029406] genpd_remove.part.0+0x12c/0x1b4 +[ 0.029419] of_genpd_remove_last+0xa8/0xd4 +[ 0.029434] psci_cpuidle_domain_probe+0x174/0x53c +[ 0.029449] platform_probe+0x68/0xe0 +[ 0.029462] really_probe+0x190/0x430 +[ 0.029473] __driver_probe_device+0x90/0x18c +[ 0.029485] driver_probe_device+0x40/0xe0 +[ 0.029497] __driver_attach+0xf4/0x1d0 +[ 0.029508] bus_for_each_dev+0x70/0xd0 +[ 0.029523] driver_attach+0x24/0x30 +[ 0.029534] bus_add_driver+0x164/0x22c +[ 0.029545] driver_register+0x78/0x130 +[ 0.029556] __platform_driver_register+0x28/0x34 +[ 0.029569] psci_idle_init_domains+0x1c/0x28 +[ 0.029583] do_one_initcall+0x50/0x1b0 +[ 0.029595] kernel_init_freeable+0x214/0x280 +[ 0.029609] kernel_init+0x2c/0x13c +[ 0.029622] ret_from_fork+0x10/0x20 + +It doesn't seem necessary to call genpd_debug_remove() with the lock, so +move it out from locking to fix the problem. + +Fixes: 718072ceb211 ("PM: domains: create debugfs nodes when adding power domains") +Signed-off-by: Shawn Guo +Reviewed-by: Ulf Hansson +Cc: 5.11+ # 5.11+ +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + drivers/base/power/domain.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/base/power/domain.c ++++ b/drivers/base/power/domain.c +@@ -2058,9 +2058,9 @@ static int genpd_remove(struct generic_p + kfree(link); + } + +- genpd_debug_remove(genpd); + list_del(&genpd->gpd_list_node); + genpd_unlock(genpd); ++ genpd_debug_remove(genpd); + cancel_work_sync(&genpd->power_off_work); + if (genpd_is_cpu_domain(genpd)) + free_cpumask_var(genpd->cpus); diff --git a/queue-5.15/powerpc-kvm-fix-kvm_use_magic_page.patch b/queue-5.15/powerpc-kvm-fix-kvm_use_magic_page.patch new file mode 100644 index 00000000000..9458680f24a --- /dev/null +++ b/queue-5.15/powerpc-kvm-fix-kvm_use_magic_page.patch @@ -0,0 +1,33 @@ +From 0c8eb2884a42d992c7726539328b7d3568f22143 Mon Sep 17 00:00:00 2001 +From: Andreas Gruenbacher +Date: Mon, 2 Aug 2021 13:46:19 +0200 +Subject: powerpc/kvm: Fix kvm_use_magic_page + +From: Andreas Gruenbacher + +commit 0c8eb2884a42d992c7726539328b7d3568f22143 upstream. + +When switching from __get_user to fault_in_pages_readable, commit +9f9eae5ce717 broke kvm_use_magic_page: like __get_user, +fault_in_pages_readable returns 0 on success. + +Fixes: 9f9eae5ce717 ("powerpc/kvm: Prefer fault_in_pages_readable function") +Cc: stable@vger.kernel.org # v4.18+ +Signed-off-by: Andreas Gruenbacher +Signed-off-by: Anand Jain +Signed-off-by: Greg Kroah-Hartman +--- + arch/powerpc/kernel/kvm.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/powerpc/kernel/kvm.c ++++ b/arch/powerpc/kernel/kvm.c +@@ -669,7 +669,7 @@ static void __init kvm_use_magic_page(vo + on_each_cpu(kvm_map_magic_page, &features, 1); + + /* Quick self-test to see if the mapping works */ +- if (!fault_in_pages_readable((const char *)KVM_MAGIC_PAGE, sizeof(u32))) { ++ if (fault_in_pages_readable((const char *)KVM_MAGIC_PAGE, sizeof(u32))) { + kvm_patching_worked = false; + return; + } diff --git a/queue-5.15/pstore-don-t-use-semaphores-in-always-atomic-context-code.patch b/queue-5.15/pstore-don-t-use-semaphores-in-always-atomic-context-code.patch new file mode 100644 index 00000000000..644714c9390 --- /dev/null +++ b/queue-5.15/pstore-don-t-use-semaphores-in-always-atomic-context-code.patch @@ -0,0 +1,170 @@ +From 8126b1c73108bc691f5643df19071a59a69d0bc6 Mon Sep 17 00:00:00 2001 +From: Jann Horn +Date: Mon, 14 Mar 2022 19:59:53 +0100 +Subject: pstore: Don't use semaphores in always-atomic-context code + +From: Jann Horn + +commit 8126b1c73108bc691f5643df19071a59a69d0bc6 upstream. + +pstore_dump() is *always* invoked in atomic context (nowadays in an RCU +read-side critical section, before that under a spinlock). +It doesn't make sense to try to use semaphores here. + +This is mostly a revert of commit ea84b580b955 ("pstore: Convert buf_lock +to semaphore"), except that two parts aren't restored back exactly as they +were: + + - keep the lock initialization in pstore_register + - in efi_pstore_write(), always set the "block" flag to false + - omit "is_locked", that was unnecessary since + commit 959217c84c27 ("pstore: Actually give up during locking failure") + - fix the bailout message + +The actual problem that the buggy commit was trying to address may have +been that the use of preemptible() in efi_pstore_write() was wrong - it +only looks at preempt_count() and the state of IRQs, but __rcu_read_lock() +doesn't touch either of those under CONFIG_PREEMPT_RCU. +(Sidenote: CONFIG_PREEMPT_RCU means that the scheduler can preempt tasks in +RCU read-side critical sections, but you're not allowed to actively +block/reschedule.) + +Lockdep probably never caught the problem because it's very rare that you +actually hit the contended case, so lockdep always just sees the +down_trylock(), not the down_interruptible(), and so it can't tell that +there's a problem. + +Fixes: ea84b580b955 ("pstore: Convert buf_lock to semaphore") +Cc: stable@vger.kernel.org +Acked-by: Sebastian Andrzej Siewior +Signed-off-by: Jann Horn +Signed-off-by: Kees Cook +Link: https://lore.kernel.org/r/20220314185953.2068993-1-jannh@google.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/firmware/efi/efi-pstore.c | 2 +- + fs/pstore/platform.c | 38 ++++++++++++++++++-------------------- + include/linux/pstore.h | 6 +++--- + 3 files changed, 22 insertions(+), 24 deletions(-) + +--- a/drivers/firmware/efi/efi-pstore.c ++++ b/drivers/firmware/efi/efi-pstore.c +@@ -266,7 +266,7 @@ static int efi_pstore_write(struct pstor + efi_name[i] = name[i]; + + ret = efivar_entry_set_safe(efi_name, vendor, PSTORE_EFI_ATTRIBUTES, +- preemptible(), record->size, record->psi->buf); ++ false, record->size, record->psi->buf); + + if (record->reason == KMSG_DUMP_OOPS && try_module_get(THIS_MODULE)) + if (!schedule_work(&efivar_work)) +--- a/fs/pstore/platform.c ++++ b/fs/pstore/platform.c +@@ -143,21 +143,22 @@ static void pstore_timer_kick(void) + mod_timer(&pstore_timer, jiffies + msecs_to_jiffies(pstore_update_ms)); + } + +-/* +- * Should pstore_dump() wait for a concurrent pstore_dump()? If +- * not, the current pstore_dump() will report a failure to dump +- * and return. +- */ +-static bool pstore_cannot_wait(enum kmsg_dump_reason reason) ++static bool pstore_cannot_block_path(enum kmsg_dump_reason reason) + { +- /* In NMI path, pstore shouldn't block regardless of reason. */ ++ /* ++ * In case of NMI path, pstore shouldn't be blocked ++ * regardless of reason. ++ */ + if (in_nmi()) + return true; + + switch (reason) { + /* In panic case, other cpus are stopped by smp_send_stop(). */ + case KMSG_DUMP_PANIC: +- /* Emergency restart shouldn't be blocked. */ ++ /* ++ * Emergency restart shouldn't be blocked by spinning on ++ * pstore_info::buf_lock. ++ */ + case KMSG_DUMP_EMERG: + return true; + default: +@@ -389,21 +390,19 @@ static void pstore_dump(struct kmsg_dump + unsigned long total = 0; + const char *why; + unsigned int part = 1; ++ unsigned long flags = 0; + int ret; + + why = kmsg_dump_reason_str(reason); + +- if (down_trylock(&psinfo->buf_lock)) { +- /* Failed to acquire lock: give up if we cannot wait. */ +- if (pstore_cannot_wait(reason)) { +- pr_err("dump skipped in %s path: may corrupt error record\n", +- in_nmi() ? "NMI" : why); +- return; +- } +- if (down_interruptible(&psinfo->buf_lock)) { +- pr_err("could not grab semaphore?!\n"); ++ if (pstore_cannot_block_path(reason)) { ++ if (!spin_trylock_irqsave(&psinfo->buf_lock, flags)) { ++ pr_err("dump skipped in %s path because of concurrent dump\n", ++ in_nmi() ? "NMI" : why); + return; + } ++ } else { ++ spin_lock_irqsave(&psinfo->buf_lock, flags); + } + + kmsg_dump_rewind(&iter); +@@ -467,8 +466,7 @@ static void pstore_dump(struct kmsg_dump + total += record.size; + part++; + } +- +- up(&psinfo->buf_lock); ++ spin_unlock_irqrestore(&psinfo->buf_lock, flags); + } + + static struct kmsg_dumper pstore_dumper = { +@@ -594,7 +592,7 @@ int pstore_register(struct pstore_info * + psi->write_user = pstore_write_user_compat; + psinfo = psi; + mutex_init(&psinfo->read_mutex); +- sema_init(&psinfo->buf_lock, 1); ++ spin_lock_init(&psinfo->buf_lock); + + if (psi->flags & PSTORE_FLAGS_DMESG) + allocate_buf_for_compression(); +--- a/include/linux/pstore.h ++++ b/include/linux/pstore.h +@@ -14,7 +14,7 @@ + #include + #include + #include +-#include ++#include + #include + #include + +@@ -87,7 +87,7 @@ struct pstore_record { + * @owner: module which is responsible for this backend driver + * @name: name of the backend driver + * +- * @buf_lock: semaphore to serialize access to @buf ++ * @buf_lock: spinlock to serialize access to @buf + * @buf: preallocated crash dump buffer + * @bufsize: size of @buf available for crash dump bytes (must match + * smallest number of bytes available for writing to a +@@ -178,7 +178,7 @@ struct pstore_info { + struct module *owner; + const char *name; + +- struct semaphore buf_lock; ++ spinlock_t buf_lock; + char *buf; + size_t bufsize; + diff --git a/queue-5.15/revert-acpi-pass-the-same-capabilities-to-the-_osc-regardless-of-the-query-flag.patch b/queue-5.15/revert-acpi-pass-the-same-capabilities-to-the-_osc-regardless-of-the-query-flag.patch new file mode 100644 index 00000000000..108934b97c3 --- /dev/null +++ b/queue-5.15/revert-acpi-pass-the-same-capabilities-to-the-_osc-regardless-of-the-query-flag.patch @@ -0,0 +1,72 @@ +From 2ca8e6285250c07a2e5a22ecbfd59b5a4ef73484 Mon Sep 17 00:00:00 2001 +From: "Rafael J. Wysocki" +Date: Wed, 16 Mar 2022 13:37:44 +0100 +Subject: Revert "ACPI: Pass the same capabilities to the _OSC regardless of the query flag" + +From: Rafael J. Wysocki + +commit 2ca8e6285250c07a2e5a22ecbfd59b5a4ef73484 upstream. + +Revert commit 159d8c274fd9 ("ACPI: Pass the same capabilities to the +_OSC regardless of the query flag") which caused legitimate usage +scenarios (when the platform firmware does not want the OS to control +certain platform features controlled by the system bus scope _OSC) to +break and was misguided by some misleading language in the _OSC +definition in the ACPI specification (in particular, Section 6.2.11.1.3 +"Sequence of _OSC Calls" that contradicts other perts of the _OSC +definition). + +Link: https://lore.kernel.org/linux-acpi/CAJZ5v0iStA0JmO0H3z+VgQsVuQONVjKPpw0F5HKfiq=Gb6B5yw@mail.gmail.com +Reported-by: Mario Limonciello +Signed-off-by: Rafael J. Wysocki +Tested-by: Mario Limonciello +Acked-by: Huang Rui +Reviewed-by: Mika Westerberg +Signed-off-by: Greg Kroah-Hartman +--- + drivers/acpi/bus.c | 27 +++++++++++++++++++-------- + 1 file changed, 19 insertions(+), 8 deletions(-) + +--- a/drivers/acpi/bus.c ++++ b/drivers/acpi/bus.c +@@ -332,21 +332,32 @@ static void acpi_bus_osc_negotiate_platf + if (ACPI_FAILURE(acpi_run_osc(handle, &context))) + return; + +- kfree(context.ret.pointer); ++ capbuf_ret = context.ret.pointer; ++ if (context.ret.length <= OSC_SUPPORT_DWORD) { ++ kfree(context.ret.pointer); ++ return; ++ } + +- /* Now run _OSC again with query flag clear */ ++ /* ++ * Now run _OSC again with query flag clear and with the caps ++ * supported by both the OS and the platform. ++ */ + capbuf[OSC_QUERY_DWORD] = 0; ++ capbuf[OSC_SUPPORT_DWORD] = capbuf_ret[OSC_SUPPORT_DWORD]; ++ kfree(context.ret.pointer); + + if (ACPI_FAILURE(acpi_run_osc(handle, &context))) + return; + + capbuf_ret = context.ret.pointer; +- osc_sb_apei_support_acked = +- capbuf_ret[OSC_SUPPORT_DWORD] & OSC_SB_APEI_SUPPORT; +- osc_pc_lpi_support_confirmed = +- capbuf_ret[OSC_SUPPORT_DWORD] & OSC_SB_PCLPI_SUPPORT; +- osc_sb_native_usb4_support_confirmed = +- capbuf_ret[OSC_SUPPORT_DWORD] & OSC_SB_NATIVE_USB4_SUPPORT; ++ if (context.ret.length > OSC_SUPPORT_DWORD) { ++ osc_sb_apei_support_acked = ++ capbuf_ret[OSC_SUPPORT_DWORD] & OSC_SB_APEI_SUPPORT; ++ osc_pc_lpi_support_confirmed = ++ capbuf_ret[OSC_SUPPORT_DWORD] & OSC_SB_PCLPI_SUPPORT; ++ osc_sb_native_usb4_support_confirmed = ++ capbuf_ret[OSC_SUPPORT_DWORD] & OSC_SB_NATIVE_USB4_SUPPORT; ++ } + + kfree(context.ret.pointer); + } diff --git a/queue-5.15/revert-mm-madvise-skip-unmapped-vma-holes-passed-to-process_madvise.patch b/queue-5.15/revert-mm-madvise-skip-unmapped-vma-holes-passed-to-process_madvise.patch new file mode 100644 index 00000000000..dc7a0457b31 --- /dev/null +++ b/queue-5.15/revert-mm-madvise-skip-unmapped-vma-holes-passed-to-process_madvise.patch @@ -0,0 +1,57 @@ +From e6b0a7b357659c332231621e4315658d062c23ee Mon Sep 17 00:00:00 2001 +From: Charan Teja Kalla +Date: Fri, 1 Apr 2022 11:28:12 -0700 +Subject: Revert "mm: madvise: skip unmapped vma holes passed to process_madvise" + +From: Charan Teja Kalla + +commit e6b0a7b357659c332231621e4315658d062c23ee upstream. + +This reverts commit 08095d6310a7 ("mm: madvise: skip unmapped vma holes +passed to process_madvise") as process_madvise() fails to return the +exact processed bytes in other cases too. + +As an example: if process_madvise() hits mlocked pages after processing +some initial bytes passed in [start, end), it just returns EINVAL +although some bytes are processed. Thus making an exception only for +ENOMEM is partially fixing the problem of returning the proper advised +bytes. + +Thus revert this patch and return proper bytes advised. + +Link: https://lkml.kernel.org/r/e73da1304a88b6a8a11907045117cccf4c2b8374.1648046642.git.quic_charante@quicinc.com +Fixes: 08095d6310a7ce ("mm: madvise: skip unmapped vma holes passed to process_madvise") +Signed-off-by: Charan Teja Kalla +Acked-by: Michal Hocko +Cc: Suren Baghdasaryan +Cc: Vlastimil Babka +Cc: David Rientjes +Cc: Nadav Amit +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + mm/madvise.c | 9 +-------- + 1 file changed, 1 insertion(+), 8 deletions(-) + +--- a/mm/madvise.c ++++ b/mm/madvise.c +@@ -1287,16 +1287,9 @@ SYSCALL_DEFINE5(process_madvise, int, pi + + while (iov_iter_count(&iter)) { + iovec = iov_iter_iovec(&iter); +- /* +- * do_madvise returns ENOMEM if unmapped holes are present +- * in the passed VMA. process_madvise() is expected to skip +- * unmapped holes passed to it in the 'struct iovec' list +- * and not fail because of them. Thus treat -ENOMEM return +- * from do_madvise as valid and continue processing. +- */ + ret = do_madvise(mm, (unsigned long)iovec.iov_base, + iovec.iov_len, behavior); +- if (ret < 0 && ret != -ENOMEM) ++ if (ret < 0) + break; + iov_iter_advance(&iter, iovec.iov_len); + } diff --git a/queue-5.15/rfkill-make-new-event-layout-opt-in.patch b/queue-5.15/rfkill-make-new-event-layout-opt-in.patch new file mode 100644 index 00000000000..9608888a7e1 --- /dev/null +++ b/queue-5.15/rfkill-make-new-event-layout-opt-in.patch @@ -0,0 +1,180 @@ +From 54f586a9153201c6cff55e1f561990c78bd99aa7 Mon Sep 17 00:00:00 2001 +From: Johannes Berg +Date: Wed, 16 Mar 2022 21:27:51 +0100 +Subject: rfkill: make new event layout opt-in + +From: Johannes Berg + +commit 54f586a9153201c6cff55e1f561990c78bd99aa7 upstream. + +Again new complaints surfaced that we had broken the ABI here, +although previously all the userspace tools had agreed that it +was their mistake and fixed it. Yet now there are cases (e.g. +RHEL) that want to run old userspace with newer kernels, and +thus are broken. + +Since this is a bit of a whack-a-mole thing, change the whole +extensibility scheme of rfkill to no longer just rely on the +message lengths, but instead require userspace to opt in via a +new ioctl to a given maximum event size that it is willing to +understand. + +By default, set that to RFKILL_EVENT_SIZE_V1 (8), so that the +behaviour for userspace not calling the ioctl will look as if +it's just running on an older kernel. + +Fixes: 14486c82612a ("rfkill: add a reason to the HW rfkill state") +Cc: stable@vger.kernel.org # 5.11+ +Signed-off-by: Johannes Berg +Signed-off-by: Kalle Valo +Link: https://lore.kernel.org/r/20220316212749.16491491b270.Ifcb1950998330a596f29a2a162e00b7546a1d6d0@changeid +Signed-off-by: Greg Kroah-Hartman +--- + include/uapi/linux/rfkill.h | 14 +++++++++++- + net/rfkill/core.c | 48 +++++++++++++++++++++++++++++++------------- + 2 files changed, 46 insertions(+), 16 deletions(-) + +--- a/include/uapi/linux/rfkill.h ++++ b/include/uapi/linux/rfkill.h +@@ -159,8 +159,16 @@ struct rfkill_event_ext { + * old behaviour for all userspace, unless it explicitly opts in to the + * rules outlined here by using the new &struct rfkill_event_ext. + * +- * Userspace using &struct rfkill_event_ext must adhere to the following +- * rules ++ * Additionally, some other userspace (bluez, g-s-d) was reading with a ++ * large size but as streaming reads rather than message-based, or with ++ * too strict checks for the returned size. So eventually, we completely ++ * reverted this, and extended messages need to be opted in to by using ++ * an ioctl: ++ * ++ * ioctl(fd, RFKILL_IOCTL_MAX_SIZE, sizeof(struct rfkill_event_ext)); ++ * ++ * Userspace using &struct rfkill_event_ext and the ioctl must adhere to ++ * the following rules: + * + * 1. accept short writes, optionally using them to detect that it's + * running on an older kernel; +@@ -175,6 +183,8 @@ struct rfkill_event_ext { + #define RFKILL_IOC_MAGIC 'R' + #define RFKILL_IOC_NOINPUT 1 + #define RFKILL_IOCTL_NOINPUT _IO(RFKILL_IOC_MAGIC, RFKILL_IOC_NOINPUT) ++#define RFKILL_IOC_MAX_SIZE 2 ++#define RFKILL_IOCTL_MAX_SIZE _IOW(RFKILL_IOC_MAGIC, RFKILL_IOC_EXT_SIZE, __u32) + + /* and that's all userspace gets */ + +--- a/net/rfkill/core.c ++++ b/net/rfkill/core.c +@@ -78,6 +78,7 @@ struct rfkill_data { + struct mutex mtx; + wait_queue_head_t read_wait; + bool input_handler; ++ u8 max_size; + }; + + +@@ -1141,6 +1142,8 @@ static int rfkill_fop_open(struct inode + if (!data) + return -ENOMEM; + ++ data->max_size = RFKILL_EVENT_SIZE_V1; ++ + INIT_LIST_HEAD(&data->events); + mutex_init(&data->mtx); + init_waitqueue_head(&data->read_wait); +@@ -1223,6 +1226,7 @@ static ssize_t rfkill_fop_read(struct fi + list); + + sz = min_t(unsigned long, sizeof(ev->ev), count); ++ sz = min_t(unsigned long, sz, data->max_size); + ret = sz; + if (copy_to_user(buf, &ev->ev, sz)) + ret = -EFAULT; +@@ -1237,6 +1241,7 @@ static ssize_t rfkill_fop_read(struct fi + static ssize_t rfkill_fop_write(struct file *file, const char __user *buf, + size_t count, loff_t *pos) + { ++ struct rfkill_data *data = file->private_data; + struct rfkill *rfkill; + struct rfkill_event_ext ev; + int ret; +@@ -1251,6 +1256,7 @@ static ssize_t rfkill_fop_write(struct f + * our API version even in a write() call, if it cares. + */ + count = min(count, sizeof(ev)); ++ count = min_t(size_t, count, data->max_size); + if (copy_from_user(&ev, buf, count)) + return -EFAULT; + +@@ -1310,31 +1316,47 @@ static int rfkill_fop_release(struct ino + return 0; + } + +-#ifdef CONFIG_RFKILL_INPUT + static long rfkill_fop_ioctl(struct file *file, unsigned int cmd, + unsigned long arg) + { + struct rfkill_data *data = file->private_data; ++ int ret = -ENOSYS; ++ u32 size; + + if (_IOC_TYPE(cmd) != RFKILL_IOC_MAGIC) + return -ENOSYS; + +- if (_IOC_NR(cmd) != RFKILL_IOC_NOINPUT) +- return -ENOSYS; +- + mutex_lock(&data->mtx); +- +- if (!data->input_handler) { +- if (atomic_inc_return(&rfkill_input_disabled) == 1) +- printk(KERN_DEBUG "rfkill: input handler disabled\n"); +- data->input_handler = true; ++ switch (_IOC_NR(cmd)) { ++#ifdef CONFIG_RFKILL_INPUT ++ case RFKILL_IOC_NOINPUT: ++ if (!data->input_handler) { ++ if (atomic_inc_return(&rfkill_input_disabled) == 1) ++ printk(KERN_DEBUG "rfkill: input handler disabled\n"); ++ data->input_handler = true; ++ } ++ ret = 0; ++ break; ++#endif ++ case RFKILL_IOC_MAX_SIZE: ++ if (get_user(size, (__u32 __user *)arg)) { ++ ret = -EFAULT; ++ break; ++ } ++ if (size < RFKILL_EVENT_SIZE_V1 || size > U8_MAX) { ++ ret = -EINVAL; ++ break; ++ } ++ data->max_size = size; ++ ret = 0; ++ break; ++ default: ++ break; + } +- + mutex_unlock(&data->mtx); + +- return 0; ++ return ret; + } +-#endif + + static const struct file_operations rfkill_fops = { + .owner = THIS_MODULE, +@@ -1343,10 +1365,8 @@ static const struct file_operations rfki + .write = rfkill_fop_write, + .poll = rfkill_fop_poll, + .release = rfkill_fop_release, +-#ifdef CONFIG_RFKILL_INPUT + .unlocked_ioctl = rfkill_fop_ioctl, + .compat_ioctl = compat_ptr_ioctl, +-#endif + .llseek = no_llseek, + }; + diff --git a/queue-5.15/samples-landlock-fix-path_list-memory-leak.patch b/queue-5.15/samples-landlock-fix-path_list-memory-leak.patch new file mode 100644 index 00000000000..39b36910d7f --- /dev/null +++ b/queue-5.15/samples-landlock-fix-path_list-memory-leak.patch @@ -0,0 +1,39 @@ +From 66b513b7c64a7290c1fbb88e657f7cece992e131 Mon Sep 17 00:00:00 2001 +From: Tom Rix +Date: Wed, 28 Apr 2021 14:38:52 -0700 +Subject: samples/landlock: Fix path_list memory leak +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Tom Rix + +commit 66b513b7c64a7290c1fbb88e657f7cece992e131 upstream. + +Clang static analysis reports this error + +sandboxer.c:134:8: warning: Potential leak of memory + pointed to by 'path_list' + ret = 0; + ^ +path_list is allocated in parse_path() but never freed. + +Signed-off-by: Tom Rix +Link: https://lore.kernel.org/r/20210428213852.2874324-1-trix@redhat.com +Cc: stable@vger.kernel.org +Signed-off-by: Mickaël Salaün +Signed-off-by: Greg Kroah-Hartman +--- + samples/landlock/sandboxer.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/samples/landlock/sandboxer.c ++++ b/samples/landlock/sandboxer.c +@@ -134,6 +134,7 @@ static int populate_ruleset( + ret = 0; + + out_free_name: ++ free(path_list); + free(env_path_name); + return ret; + } diff --git a/queue-5.15/series b/queue-5.15/series index ee9fc25b84f..88e08123a35 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -103,3 +103,87 @@ alsa-hda-realtek-fix-audio-regression-on-mi-notebook-pro-2020.patch rtc-mc146818-lib-fix-locking-in-mc146818_set_time.patch rtc-pl031-fix-rtc-features-null-pointer-dereference.patch ocfs2-fix-crash-when-mount-with-quota-enabled.patch +drm-simpledrm-add-panel-orientation-property-on-non-upright-mounted-lcd-panels.patch +mm-madvise-skip-unmapped-vma-holes-passed-to-process_madvise.patch +mm-madvise-return-correct-bytes-advised-with-process_madvise.patch +revert-mm-madvise-skip-unmapped-vma-holes-passed-to-process_madvise.patch +mm-hwpoison-unmap-poisoned-page-before-invalidation.patch +mm-kmemleak-reset-tag-when-compare-object-pointer.patch +dm-stats-fix-too-short-end-duration_ns-when-using-precise_timestamps.patch +dm-fix-use-after-free-in-dm_cleanup_zoned_dev.patch +dm-interlock-pending-dm_io-and-dm_wait_for_bios_completion.patch +dm-fix-double-accounting-of-flush-with-data.patch +dm-integrity-set-journal-entry-unused-when-shrinking-device.patch +tracing-have-trace-event-string-test-handle-zero-length-strings.patch +drbd-fix-potential-silent-data-corruption.patch +can-isotp-sanitize-can-id-checks-in-isotp_bind.patch +powerpc-kvm-fix-kvm_use_magic_page.patch +pci-fu740-force-2.5gt-s-for-initial-device-probe.patch +arm64-signal-nofpsimd-do-not-allocate-fp-simd-context-when-not-available.patch +arm64-do-not-defer-reserve_crashkernel-for-platforms-with-no-dma-memory-zones.patch +arm64-dts-qcom-sm8250-fix-msi-irq-for-pcie1-and-pcie2.patch +arm64-dts-ti-k3-am65-fix-gic-v3-compatible-regs.patch +arm64-dts-ti-k3-j721e-fix-gic-v3-compatible-regs.patch +arm64-dts-ti-k3-j7200-fix-gic-v3-compatible-regs.patch +arm64-dts-ti-k3-am64-fix-gic-v3-compatible-regs.patch +asoc-sof-intel-fix-null-ptr-dereference-when-enomem.patch +revert-acpi-pass-the-same-capabilities-to-the-_osc-regardless-of-the-query-flag.patch +acpi-properties-consistently-return-enoent-if-there-are-no-more-references.patch +coredump-also-dump-first-pages-of-non-executable-elf-libraries.patch +ext4-fix-ext4_fc_stats-trace-point.patch +ext4-fix-fs-corruption-when-tring-to-remove-a-non-empty-directory-with-io-error.patch +ext4-make-mb_optimize_scan-performance-mount-option-work-with-extents.patch +drivers-hamradio-6pack-fix-uaf-bug-caused-by-mod_timer.patch +samples-landlock-fix-path_list-memory-leak.patch +landlock-use-square-brackets-around-landlock-ruleset.patch +mailbox-tegra-hsp-flush-whole-channel.patch +block-limit-request-dispatch-loop-duration.patch +block-don-t-merge-across-cgroup-boundaries-if-blkcg-is-enabled.patch +drm-edid-check-basic-audio-support-on-cea-extension-block.patch +fbdev-hot-unplug-firmware-fb-devices-on-forced-removal.patch +video-fbdev-sm712fb-fix-crash-in-smtcfb_read.patch +video-fbdev-atari-atari-2-bpp-ste-palette-bugfix.patch +rfkill-make-new-event-layout-opt-in.patch +arm-dts-at91-sama7g5-remove-unused-properties-in-i2c-nodes.patch +arm-dts-at91-sama5d2-fix-pmerrloc-resource-size.patch +arm-dts-exynos-fix-uart3-pins-configuration-in-exynos5250.patch +arm-dts-exynos-add-missing-hdmi-supplies-on-smdk5250.patch +arm-dts-exynos-add-missing-hdmi-supplies-on-smdk5420.patch +mgag200-fix-memmapsl-configuration-in-gctl6-register.patch +carl9170-fix-missing-bit-wise-or-operator-for-tx_params.patch +pstore-don-t-use-semaphores-in-always-atomic-context-code.patch +thermal-int340x-increase-bitmap-size.patch +lib-raid6-test-fix-multiple-definition-linking-error.patch +exec-force-single-empty-string-when-argv-is-empty.patch +crypto-rsa-pkcs1pad-only-allow-with-rsa.patch +crypto-rsa-pkcs1pad-correctly-get-hash-from-source-scatterlist.patch +crypto-rsa-pkcs1pad-restore-signature-length-check.patch +crypto-rsa-pkcs1pad-fix-buffer-overread-in-pkcs1pad_verify_complete.patch +bcache-fixup-multiple-threads-crash.patch +pm-domains-fix-sleep-in-atomic-bug-caused-by-genpd_debug_remove.patch +dec-limit-pmax-memory-probing-to-r3k-systems.patch +media-gpio-ir-tx-fix-transmit-with-long-spaces-on-orange-pi-pc.patch +media-venus-hfi_cmds-list-hdr10-property-as-unsupported-for-v1-and-v3.patch +media-venus-venc-fix-h264-8x8-transform-control.patch +media-davinci-vpif-fix-unbalanced-runtime-pm-get.patch +media-davinci-vpif-fix-unbalanced-runtime-pm-enable.patch +btrfs-zoned-mark-relocation-as-writing.patch +btrfs-extend-locking-to-all-space_info-members-accesses.patch +btrfs-verify-the-tranisd-of-the-to-be-written-dirty-extent-buffer.patch +xtensa-define-update_mmu_tlb-function.patch +xtensa-fix-stop_machine_cpuslocked-call-in-patch_text.patch +xtensa-fix-xtensa_wsr-always-writing-0.patch +drm-syncobj-flatten-dma_fence_chains-on-transfer.patch +drm-nouveau-backlight-fix-lvds-backlight-detection-on-some-laptops.patch +drm-nouveau-backlight-just-set-all-backlight-types-as-raw.patch +drm-fb-helper-mark-screen-buffers-in-system-memory-with-fbinfo_virtfb.patch +brcmfmac-firmware-allocate-space-for-default-boardrev-in-nvram.patch +brcmfmac-pcie-release-firmwares-in-the-brcmf_pcie_setup-error-path.patch +brcmfmac-pcie-declare-missing-firmware-files-in-pcie.c.patch +brcmfmac-pcie-replace-brcmf_pcie_copy_mem_todev-with-memcpy_toio.patch +brcmfmac-pcie-fix-crashes-due-to-early-irqs.patch +drm-i915-opregion-check-port-number-bounds-for-swsci-display-power-state.patch +drm-i915-gem-add-missing-boundary-check-in-vm_access.patch +pci-imx6-allow-to-probe-when-dw_pcie_wait_for_link-fails.patch +pci-pciehp-clear-cmd_busy-bit-in-polling-mode.patch +pci-xgene-revert-pci-xgene-fix-ib-window-setup.patch diff --git a/queue-5.15/thermal-int340x-increase-bitmap-size.patch b/queue-5.15/thermal-int340x-increase-bitmap-size.patch new file mode 100644 index 00000000000..e4368f5a0ec --- /dev/null +++ b/queue-5.15/thermal-int340x-increase-bitmap-size.patch @@ -0,0 +1,35 @@ +From 668f69a5f863b877bc3ae129efe9a80b6f055141 Mon Sep 17 00:00:00 2001 +From: Srinivas Pandruvada +Date: Mon, 14 Mar 2022 15:08:55 -0700 +Subject: thermal: int340x: Increase bitmap size + +From: Srinivas Pandruvada + +commit 668f69a5f863b877bc3ae129efe9a80b6f055141 upstream. + +The number of policies are 10, so can't be supported by the bitmap size +of u8. + +Even though there are no platfoms with these many policies, but +for correctness increase to u32. + +Signed-off-by: Srinivas Pandruvada +Fixes: 16fc8eca1975 ("thermal/int340x_thermal: Add additional UUIDs") +Cc: 5.1+ # 5.1+ +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + drivers/thermal/intel/int340x_thermal/int3400_thermal.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/thermal/intel/int340x_thermal/int3400_thermal.c ++++ b/drivers/thermal/intel/int340x_thermal/int3400_thermal.c +@@ -53,7 +53,7 @@ struct int3400_thermal_priv { + struct art *arts; + int trt_count; + struct trt *trts; +- u8 uuid_bitmap; ++ u32 uuid_bitmap; + int rel_misc_dev_res; + int current_uuid_index; + char *data_vault; diff --git a/queue-5.15/tracing-have-trace-event-string-test-handle-zero-length-strings.patch b/queue-5.15/tracing-have-trace-event-string-test-handle-zero-length-strings.patch new file mode 100644 index 00000000000..41d24e17f51 --- /dev/null +++ b/queue-5.15/tracing-have-trace-event-string-test-handle-zero-length-strings.patch @@ -0,0 +1,62 @@ +From eca344a7362e0f34f179298fd8366bcd556eede1 Mon Sep 17 00:00:00 2001 +From: "Steven Rostedt (Google)" +Date: Wed, 23 Mar 2022 10:32:51 -0400 +Subject: tracing: Have trace event string test handle zero length strings + +From: Steven Rostedt (Google) + +commit eca344a7362e0f34f179298fd8366bcd556eede1 upstream. + +If a trace event has in its TP_printk(): + + "%*.s", len, len ? __get_str(string) : NULL + +It is perfectly valid if len is zero and passing in the NULL. +Unfortunately, the runtime string check at time of reading the trace sees +the NULL and flags it as a bad string and produces a WARN_ON(). + +Handle this case by passing into the test function if the format has an +asterisk (star) and if so, if the length is zero, then mark it as safe. + +Link: https://lore.kernel.org/all/YjsWzuw5FbWPrdqq@bfoster/ + +Cc: stable@vger.kernel.org +Reported-by: Brian Foster +Tested-by: Brian Foster +Fixes: 9a6944fee68e2 ("tracing: Add a verifier to check string pointers for trace events") +Signed-off-by: Steven Rostedt (Google) +Signed-off-by: Greg Kroah-Hartman +--- + kernel/trace/trace.c | 9 +++++++-- + 1 file changed, 7 insertions(+), 2 deletions(-) + +--- a/kernel/trace/trace.c ++++ b/kernel/trace/trace.c +@@ -3678,12 +3678,17 @@ static char *trace_iter_expand_format(st + } + + /* Returns true if the string is safe to dereference from an event */ +-static bool trace_safe_str(struct trace_iterator *iter, const char *str) ++static bool trace_safe_str(struct trace_iterator *iter, const char *str, ++ bool star, int len) + { + unsigned long addr = (unsigned long)str; + struct trace_event *trace_event; + struct trace_event_call *event; + ++ /* Ignore strings with no length */ ++ if (star && !len) ++ return true; ++ + /* OK if part of the event data */ + if ((addr >= (unsigned long)iter->ent) && + (addr < (unsigned long)iter->ent + iter->ent_size)) +@@ -3869,7 +3874,7 @@ void trace_check_vprintf(struct trace_it + * instead. See samples/trace_events/trace-events-sample.h + * for reference. + */ +- if (WARN_ONCE(!trace_safe_str(iter, str), ++ if (WARN_ONCE(!trace_safe_str(iter, str, star, len), + "fmt: '%s' current_buffer: '%s'", + fmt, show_buffer(&iter->seq))) { + int ret; diff --git a/queue-5.15/video-fbdev-atari-atari-2-bpp-ste-palette-bugfix.patch b/queue-5.15/video-fbdev-atari-atari-2-bpp-ste-palette-bugfix.patch new file mode 100644 index 00000000000..47f8d311d1f --- /dev/null +++ b/queue-5.15/video-fbdev-atari-atari-2-bpp-ste-palette-bugfix.patch @@ -0,0 +1,62 @@ +From c8be5edbd36ceed2ff3d6b8f8e40643c3f396ea3 Mon Sep 17 00:00:00 2001 +From: Michael Schmitz +Date: Wed, 16 Feb 2022 20:26:25 +1300 +Subject: video: fbdev: atari: Atari 2 bpp (STe) palette bugfix + +From: Michael Schmitz + +commit c8be5edbd36ceed2ff3d6b8f8e40643c3f396ea3 upstream. + +The code to set the shifter STe palette registers has a long +standing operator precedence bug, manifesting as colors set +on a 2 bits per pixel frame buffer coming up with a distinctive +blue tint. + +Add parentheses around the calculation of the per-color palette +data before shifting those into their respective bit field position. + +This bug goes back a long way (2.4 days at the very least) so there +won't be a Fixes: tag. + +Tested on ARAnyM as well on Falcon030 hardware. + +Cc: stable@vger.kernel.org +Reported-by: Geert Uytterhoeven +Link: https://lore.kernel.org/all/CAMuHMdU3ievhXxKR_xi_v3aumnYW7UNUO6qMdhgfyWTyVSsCkQ@mail.gmail.com +Tested-by: Michael Schmitz +Tested-by: Geert Uytterhoeven +Signed-off-by: Michael Schmitz +Signed-off-by: Helge Deller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/video/fbdev/atafb.c | 12 ++++++------ + 1 file changed, 6 insertions(+), 6 deletions(-) + +--- a/drivers/video/fbdev/atafb.c ++++ b/drivers/video/fbdev/atafb.c +@@ -1683,9 +1683,9 @@ static int falcon_setcolreg(unsigned int + ((blue & 0xfc00) >> 8)); + if (regno < 16) { + shifter_tt.color_reg[regno] = +- (((red & 0xe000) >> 13) | ((red & 0x1000) >> 12) << 8) | +- (((green & 0xe000) >> 13) | ((green & 0x1000) >> 12) << 4) | +- ((blue & 0xe000) >> 13) | ((blue & 0x1000) >> 12); ++ ((((red & 0xe000) >> 13) | ((red & 0x1000) >> 12)) << 8) | ++ ((((green & 0xe000) >> 13) | ((green & 0x1000) >> 12)) << 4) | ++ ((blue & 0xe000) >> 13) | ((blue & 0x1000) >> 12); + ((u32 *)info->pseudo_palette)[regno] = ((red & 0xf800) | + ((green & 0xfc00) >> 5) | + ((blue & 0xf800) >> 11)); +@@ -1971,9 +1971,9 @@ static int stste_setcolreg(unsigned int + green >>= 12; + if (ATARIHW_PRESENT(EXTD_SHIFTER)) + shifter_tt.color_reg[regno] = +- (((red & 0xe) >> 1) | ((red & 1) << 3) << 8) | +- (((green & 0xe) >> 1) | ((green & 1) << 3) << 4) | +- ((blue & 0xe) >> 1) | ((blue & 1) << 3); ++ ((((red & 0xe) >> 1) | ((red & 1) << 3)) << 8) | ++ ((((green & 0xe) >> 1) | ((green & 1) << 3)) << 4) | ++ ((blue & 0xe) >> 1) | ((blue & 1) << 3); + else + shifter_tt.color_reg[regno] = + ((red & 0xe) << 7) | diff --git a/queue-5.15/video-fbdev-sm712fb-fix-crash-in-smtcfb_read.patch b/queue-5.15/video-fbdev-sm712fb-fix-crash-in-smtcfb_read.patch new file mode 100644 index 00000000000..18f7e526ad6 --- /dev/null +++ b/queue-5.15/video-fbdev-sm712fb-fix-crash-in-smtcfb_read.patch @@ -0,0 +1,76 @@ +From bd771cf5c4254511cc4abb88f3dab3bd58bdf8e8 Mon Sep 17 00:00:00 2001 +From: Helge Deller +Date: Sun, 27 Feb 2022 08:43:56 +0100 +Subject: video: fbdev: sm712fb: Fix crash in smtcfb_read() + +From: Helge Deller + +commit bd771cf5c4254511cc4abb88f3dab3bd58bdf8e8 upstream. + +Zheyu Ma reported this crash in the sm712fb driver when reading +three bytes from the framebuffer: + + BUG: unable to handle page fault for address: ffffc90001ffffff + RIP: 0010:smtcfb_read+0x230/0x3e0 + Call Trace: + vfs_read+0x198/0xa00 + ? do_sys_openat2+0x27d/0x350 + ? __fget_light+0x54/0x340 + ksys_read+0xce/0x190 + do_syscall_64+0x43/0x90 + +Fix it by removing the open-coded endianess fixup-code and +by moving the pointer post decrement out the fb_readl() function. + +Reported-by: Zheyu Ma +Signed-off-by: Helge Deller +Tested-by: Zheyu Ma +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/video/fbdev/sm712fb.c | 25 +++++++------------------ + 1 file changed, 7 insertions(+), 18 deletions(-) + +--- a/drivers/video/fbdev/sm712fb.c ++++ b/drivers/video/fbdev/sm712fb.c +@@ -1047,7 +1047,7 @@ static ssize_t smtcfb_read(struct fb_inf + if (count + p > total_size) + count = total_size - p; + +- buffer = kmalloc((count > PAGE_SIZE) ? PAGE_SIZE : count, GFP_KERNEL); ++ buffer = kmalloc(PAGE_SIZE, GFP_KERNEL); + if (!buffer) + return -ENOMEM; + +@@ -1059,25 +1059,14 @@ static ssize_t smtcfb_read(struct fb_inf + while (count) { + c = (count > PAGE_SIZE) ? PAGE_SIZE : count; + dst = buffer; +- for (i = c >> 2; i--;) { +- *dst = fb_readl(src++); +- *dst = big_swap(*dst); ++ for (i = (c + 3) >> 2; i--;) { ++ u32 val; ++ ++ val = fb_readl(src); ++ *dst = big_swap(val); ++ src++; + dst++; + } +- if (c & 3) { +- u8 *dst8 = (u8 *)dst; +- u8 __iomem *src8 = (u8 __iomem *)src; +- +- for (i = c & 3; i--;) { +- if (i & 1) { +- *dst8++ = fb_readb(++src8); +- } else { +- *dst8++ = fb_readb(--src8); +- src8 += 2; +- } +- } +- src = (u32 __iomem *)src8; +- } + + if (copy_to_user(buf, buffer, c)) { + err = -EFAULT; diff --git a/queue-5.15/xtensa-define-update_mmu_tlb-function.patch b/queue-5.15/xtensa-define-update_mmu_tlb-function.patch new file mode 100644 index 00000000000..94624a9046e --- /dev/null +++ b/queue-5.15/xtensa-define-update_mmu_tlb-function.patch @@ -0,0 +1,56 @@ +From 1c4664faa38923330d478f046dc743a00c1e2dec Mon Sep 17 00:00:00 2001 +From: Max Filippov +Date: Mon, 3 Jan 2022 12:08:31 -0800 +Subject: xtensa: define update_mmu_tlb function + +From: Max Filippov + +commit 1c4664faa38923330d478f046dc743a00c1e2dec upstream. + +Before the commit f9ce0be71d1f ("mm: Cleanup faultaround and finish_fault() +codepaths") there was a call to update_mmu_cache in alloc_set_pte that +used to invalidate TLB entry caching invalid PTE that caused a page +fault. That commit removed that call so now invalid TLB entry survives +causing repetitive page faults on the CPU that took the initial fault +until that TLB entry is occasionally evicted. This issue is spotted by +the xtensa TLB sanity checker. + +Fix this issue by defining update_mmu_tlb function that flushes TLB entry +for the faulting address. + +Cc: stable@vger.kernel.org # 5.12+ +Signed-off-by: Max Filippov +Signed-off-by: Greg Kroah-Hartman +--- + arch/xtensa/include/asm/pgtable.h | 4 ++++ + arch/xtensa/mm/tlb.c | 6 ++++++ + 2 files changed, 10 insertions(+) + +--- a/arch/xtensa/include/asm/pgtable.h ++++ b/arch/xtensa/include/asm/pgtable.h +@@ -411,6 +411,10 @@ extern void update_mmu_cache(struct vm_ + + typedef pte_t *pte_addr_t; + ++void update_mmu_tlb(struct vm_area_struct *vma, ++ unsigned long address, pte_t *ptep); ++#define __HAVE_ARCH_UPDATE_MMU_TLB ++ + #endif /* !defined (__ASSEMBLY__) */ + + #define __HAVE_ARCH_PTEP_TEST_AND_CLEAR_YOUNG +--- a/arch/xtensa/mm/tlb.c ++++ b/arch/xtensa/mm/tlb.c +@@ -162,6 +162,12 @@ void local_flush_tlb_kernel_range(unsign + } + } + ++void update_mmu_tlb(struct vm_area_struct *vma, ++ unsigned long address, pte_t *ptep) ++{ ++ local_flush_tlb_page(vma, address); ++} ++ + #ifdef CONFIG_DEBUG_TLB_SANITY + + static unsigned get_pte_for_vaddr(unsigned vaddr) diff --git a/queue-5.15/xtensa-fix-stop_machine_cpuslocked-call-in-patch_text.patch b/queue-5.15/xtensa-fix-stop_machine_cpuslocked-call-in-patch_text.patch new file mode 100644 index 00000000000..2d5b713dea2 --- /dev/null +++ b/queue-5.15/xtensa-fix-stop_machine_cpuslocked-call-in-patch_text.patch @@ -0,0 +1,34 @@ +From f406f2d03e07afc199dd8cf501f361dde6be8a69 Mon Sep 17 00:00:00 2001 +From: Max Filippov +Date: Wed, 16 Mar 2022 02:04:17 -0700 +Subject: xtensa: fix stop_machine_cpuslocked call in patch_text + +From: Max Filippov + +commit f406f2d03e07afc199dd8cf501f361dde6be8a69 upstream. + +patch_text must invoke patch_text_stop_machine on all online CPUs, but +it calls stop_machine_cpuslocked with NULL cpumask. As a result only one +CPU runs patch_text_stop_machine potentially leaving stale icache +entries on other CPUs. Fix that by calling stop_machine_cpuslocked with +cpu_online_mask as the last argument. + +Cc: stable@vger.kernel.org +Fixes: 64711f9a47d4 ("xtensa: implement jump_label support") +Signed-off-by: Max Filippov +Signed-off-by: Greg Kroah-Hartman +--- + arch/xtensa/kernel/jump_label.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/xtensa/kernel/jump_label.c ++++ b/arch/xtensa/kernel/jump_label.c +@@ -61,7 +61,7 @@ static void patch_text(unsigned long add + .data = data, + }; + stop_machine_cpuslocked(patch_text_stop_machine, +- &patch, NULL); ++ &patch, cpu_online_mask); + } else { + unsigned long flags; + diff --git a/queue-5.15/xtensa-fix-xtensa_wsr-always-writing-0.patch b/queue-5.15/xtensa-fix-xtensa_wsr-always-writing-0.patch new file mode 100644 index 00000000000..e567745f456 --- /dev/null +++ b/queue-5.15/xtensa-fix-xtensa_wsr-always-writing-0.patch @@ -0,0 +1,38 @@ +From a3d0245c58f962ee99d4440ea0eaf45fb7f5a5cc Mon Sep 17 00:00:00 2001 +From: Max Filippov +Date: Sun, 20 Mar 2022 09:40:14 -0700 +Subject: xtensa: fix xtensa_wsr always writing 0 + +From: Max Filippov + +commit a3d0245c58f962ee99d4440ea0eaf45fb7f5a5cc upstream. + +The commit cad6fade6e78 ("xtensa: clean up WSR*/RSR*/get_sr/set_sr") +replaced 'WSR' macro in the function xtensa_wsr with 'xtensa_set_sr', +but variable 'v' in the xtensa_set_sr body shadowed the argument 'v' +passed to it, resulting in wrong value written to debug registers. + +Fix that by removing intermediate variable from the xtensa_set_sr +macro body. + +Cc: stable@vger.kernel.org +Fixes: cad6fade6e78 ("xtensa: clean up WSR*/RSR*/get_sr/set_sr") +Signed-off-by: Max Filippov +Signed-off-by: Greg Kroah-Hartman +--- + arch/xtensa/include/asm/processor.h | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/arch/xtensa/include/asm/processor.h ++++ b/arch/xtensa/include/asm/processor.h +@@ -226,8 +226,8 @@ extern unsigned long get_wchan(struct ta + + #define xtensa_set_sr(x, sr) \ + ({ \ +- unsigned int v = (unsigned int)(x); \ +- __asm__ __volatile__ ("wsr %0, "__stringify(sr) :: "a"(v)); \ ++ __asm__ __volatile__ ("wsr %0, "__stringify(sr) :: \ ++ "a"((unsigned int)(x))); \ + }) + + #define xtensa_get_sr(sr) \