From 34dd582ac37a3755001efe629373520b07723f8a Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Sat, 12 Aug 2023 08:15:11 +0200 Subject: [PATCH] 6.4-stable patches added patches: accel-ivpu-add-set_pages_array_wc-uc-for-internal-buffers.patch acpi-resource-add-irq-override-quirk-for-pcspecialist-elimina-pro-16-m.patch acpi-resource-always-use-madt-override-irq-settings-for-all-legacy-non-i8042-irqs.patch acpi-resource-honor-madt-int_src_ovr-settings-for-irq1-on-amd-zen.patch acpi-resource-revert-remove-zen-specific-match-and-quirks.patch cpufreq-amd-pstate-fix-global-sysfs-attribute-type.patch cpuidle-dt_idle_genpd-add-helper-function-to-remove-genpd-topology.patch cpuidle-psci-move-enabling-osi-mode-after-power-domains-creation.patch dmaengine-pl330-return-dma_paused-when-transaction-is-paused.patch dmaengine-xilinx-xdma-fix-interrupt-vector-setting.patch drm-amd-disable-s-g-for-apus-when-64gb-or-more-host-memory.patch drm-amd-display-check-attr-flag-before-set-cursor-degamma-on-dcn3.patch drm-amd-display-fix-a-regression-on-polaris-cards.patch drm-amd-pm-correct-the-pcie-width-for-smu-13.0.0.patch drm-amdgpu-fix-possible-uaf-in-amdgpu_cs_pass1.patch drm-nouveau-gr-enable-memory-loads-on-helper-invocation-on-all-channels.patch drm-nouveau-nvkm-dp-add-workaround-to-fix-dp-1.3-dpcd-issues.patch drm-shmem-helper-reset-vma-vm_ops-before-calling-dma_buf_mmap.patch fs-proc-kcore-reinstate-bounce-buffer-for-kcore_text-regions.patch hugetlb-do-not-clear-hugetlb-dtor-until-allocating-vmemmap.patch hwmon-pmbus-bel-pfe-enable-pmbus_skip_status_check-for-pfe1100.patch io_uring-correct-check-for-o_tmpfile.patch io_uring-parisc-adjust-pgoff-in-io_uring-mmap-for-parisc.patch mm-damon-core-initialize-damo_filter-list-from-damos_new_filter.patch mm-memory-failure-avoid-false-hwpoison-page-mapped-error-info.patch mm-memory-failure-fix-potential-unexpected-return-value-from-unpoison_memory.patch mptcp-avoid-bogus-reset-on-fallback-close.patch mptcp-fix-disconnect-vs-accept-race.patch net-mana-fix-mana-vf-unload-when-hardware-is-unresponsive.patch nilfs2-fix-use-after-free-of-nilfs_root-in-dirtying-inodes-via-iput.patch nvme-fix-possible-hang-when-removing-a-controller-during-error-recovery.patch nvme-pci-add-nvme_quirk_bogus_nid-for-samsung-pm9b1-256g-and-512g.patch nvme-rdma-fix-potential-unbalanced-freeze-unfreeze.patch nvme-tcp-fix-potential-unbalanced-freeze-unfreeze.patch parisc-fix-lightweight-spinlock-checks-to-not-break-futexes.patch radix-tree-test-suite-fix-incorrect-allocation-size-for-pthreads.patch riscv-kexec-handle-r_riscv_call_plt-relocation-type.patch riscv-kexec-load-initrd-high-in-available-memory.patch riscv-mm-fix-2-instances-of-wmissing-variable-declarations.patch riscv-mmio-fix-readx-to-delay-ordering.patch riscv-start-of-dram-should-at-least-be-aligned-on-pmd-size-for-the-direct-mapping.patch selftests-mm-ksm-fix-incorrect-evaluation-of-parameter.patch selftests-mptcp-join-fix-delete-and-re-add-test.patch selftests-mptcp-join-fix-implicit-ep-test.patch tpm-tpm_tis-fix-upx-i11-dmi_match-condition.patch tpm_tis-opt-in-interrupts.patch zram-take-device-and-not-only-bvec-offset-into-account.patch zsmalloc-fix-races-between-modifications-of-fullness-and-isolated.patch --- ...ges_array_wc-uc-for-internal-buffers.patch | 54 +++++ ...rk-for-pcspecialist-elimina-pro-16-m.patch | 59 +++++ ...ttings-for-all-legacy-non-i8042-irqs.patch | 78 +++++++ ...src_ovr-settings-for-irq1-on-amd-zen.patch | 90 ++++++++ ...remove-zen-specific-match-and-quirks.patch | 120 +++++++++++ ...tate-fix-global-sysfs-attribute-type.patch | 100 +++++++++ ...er-function-to-remove-genpd-topology.patch | 80 +++++++ ...si-mode-after-power-domains-creation.patch | 118 ++++++++++ ...ma_paused-when-transaction-is-paused.patch | 98 +++++++++ ...nx-xdma-fix-interrupt-vector-setting.patch | 46 ++++ ...r-apus-when-64gb-or-more-host-memory.patch | 95 ++++++++ ...ag-before-set-cursor-degamma-on-dcn3.patch | 48 +++++ ...ay-fix-a-regression-on-polaris-cards.patch | 42 ++++ ...orrect-the-pcie-width-for-smu-13.0.0.patch | 40 ++++ ...-fix-possible-uaf-in-amdgpu_cs_pass1.patch | 37 ++++ ...on-helper-invocation-on-all-channels.patch | 112 ++++++++++ ...workaround-to-fix-dp-1.3-dpcd-issues.patch | 108 ++++++++++ ...a-vm_ops-before-calling-dma_buf_mmap.patch | 45 ++++ ...bounce-buffer-for-kcore_text-regions.patch | 119 ++++++++++ ...ugetlb-dtor-until-allocating-vmemmap.patch | 203 ++++++++++++++++++ ...-pmbus_skip_status_check-for-pfe1100.patch | 62 ++++++ ...io_uring-correct-check-for-o_tmpfile.patch | 39 ++++ ...st-pgoff-in-io_uring-mmap-for-parisc.patch | 88 ++++++++ ...mo_filter-list-from-damos_new_filter.patch | 41 ++++ ...alse-hwpoison-page-mapped-error-info.patch | 53 +++++ ...ed-return-value-from-unpoison_memory.patch | 80 +++++++ ...-avoid-bogus-reset-on-fallback-close.patch | 41 ++++ .../mptcp-fix-disconnect-vs-accept-race.patch | 172 +++++++++++++++ ...unload-when-hardware-is-unresponsive.patch | 96 +++++++++ ...lfs_root-in-dirtying-inodes-via-iput.patch | 120 +++++++++++ ...g-a-controller-during-error-recovery.patch | 57 +++++ ..._nid-for-samsung-pm9b1-256g-and-512g.patch | 36 ++++ ...potential-unbalanced-freeze-unfreeze.patch | 62 ++++++ ...potential-unbalanced-freeze-unfreeze.patch | 62 ++++++ ...spinlock-checks-to-not-break-futexes.patch | 178 +++++++++++++++ ...correct-allocation-size-for-pthreads.patch | 41 ++++ ...dle-r_riscv_call_plt-relocation-type.patch | 50 +++++ ...load-initrd-high-in-available-memory.patch | 44 ++++ ...es-of-wmissing-variable-declarations.patch | 89 ++++++++ ...scv-mmio-fix-readx-to-delay-ordering.patch | 68 ++++++ ...d-on-pmd-size-for-the-direct-mapping.patch | 48 +++++ ...ix-incorrect-evaluation-of-parameter.patch | 61 ++++++ ...ptcp-join-fix-delete-and-re-add-test.patch | 49 +++++ ...ests-mptcp-join-fix-implicit-ep-test.patch | 57 +++++ queue-6.4/series | 48 +++++ ..._tis-fix-upx-i11-dmi_match-condition.patch | 44 ++++ queue-6.4/tpm_tis-opt-in-interrupts.patch | 34 +++ ...nd-not-only-bvec-offset-into-account.patch | 103 +++++++++ ...difications-of-fullness-and-isolated.patch | 95 ++++++++ 49 files changed, 3710 insertions(+) create mode 100644 queue-6.4/accel-ivpu-add-set_pages_array_wc-uc-for-internal-buffers.patch create mode 100644 queue-6.4/acpi-resource-add-irq-override-quirk-for-pcspecialist-elimina-pro-16-m.patch create mode 100644 queue-6.4/acpi-resource-always-use-madt-override-irq-settings-for-all-legacy-non-i8042-irqs.patch create mode 100644 queue-6.4/acpi-resource-honor-madt-int_src_ovr-settings-for-irq1-on-amd-zen.patch create mode 100644 queue-6.4/acpi-resource-revert-remove-zen-specific-match-and-quirks.patch create mode 100644 queue-6.4/cpufreq-amd-pstate-fix-global-sysfs-attribute-type.patch create mode 100644 queue-6.4/cpuidle-dt_idle_genpd-add-helper-function-to-remove-genpd-topology.patch create mode 100644 queue-6.4/cpuidle-psci-move-enabling-osi-mode-after-power-domains-creation.patch create mode 100644 queue-6.4/dmaengine-pl330-return-dma_paused-when-transaction-is-paused.patch create mode 100644 queue-6.4/dmaengine-xilinx-xdma-fix-interrupt-vector-setting.patch create mode 100644 queue-6.4/drm-amd-disable-s-g-for-apus-when-64gb-or-more-host-memory.patch create mode 100644 queue-6.4/drm-amd-display-check-attr-flag-before-set-cursor-degamma-on-dcn3.patch create mode 100644 queue-6.4/drm-amd-display-fix-a-regression-on-polaris-cards.patch create mode 100644 queue-6.4/drm-amd-pm-correct-the-pcie-width-for-smu-13.0.0.patch create mode 100644 queue-6.4/drm-amdgpu-fix-possible-uaf-in-amdgpu_cs_pass1.patch create mode 100644 queue-6.4/drm-nouveau-gr-enable-memory-loads-on-helper-invocation-on-all-channels.patch create mode 100644 queue-6.4/drm-nouveau-nvkm-dp-add-workaround-to-fix-dp-1.3-dpcd-issues.patch create mode 100644 queue-6.4/drm-shmem-helper-reset-vma-vm_ops-before-calling-dma_buf_mmap.patch create mode 100644 queue-6.4/fs-proc-kcore-reinstate-bounce-buffer-for-kcore_text-regions.patch create mode 100644 queue-6.4/hugetlb-do-not-clear-hugetlb-dtor-until-allocating-vmemmap.patch create mode 100644 queue-6.4/hwmon-pmbus-bel-pfe-enable-pmbus_skip_status_check-for-pfe1100.patch create mode 100644 queue-6.4/io_uring-correct-check-for-o_tmpfile.patch create mode 100644 queue-6.4/io_uring-parisc-adjust-pgoff-in-io_uring-mmap-for-parisc.patch create mode 100644 queue-6.4/mm-damon-core-initialize-damo_filter-list-from-damos_new_filter.patch create mode 100644 queue-6.4/mm-memory-failure-avoid-false-hwpoison-page-mapped-error-info.patch create mode 100644 queue-6.4/mm-memory-failure-fix-potential-unexpected-return-value-from-unpoison_memory.patch create mode 100644 queue-6.4/mptcp-avoid-bogus-reset-on-fallback-close.patch create mode 100644 queue-6.4/mptcp-fix-disconnect-vs-accept-race.patch create mode 100644 queue-6.4/net-mana-fix-mana-vf-unload-when-hardware-is-unresponsive.patch create mode 100644 queue-6.4/nilfs2-fix-use-after-free-of-nilfs_root-in-dirtying-inodes-via-iput.patch create mode 100644 queue-6.4/nvme-fix-possible-hang-when-removing-a-controller-during-error-recovery.patch create mode 100644 queue-6.4/nvme-pci-add-nvme_quirk_bogus_nid-for-samsung-pm9b1-256g-and-512g.patch create mode 100644 queue-6.4/nvme-rdma-fix-potential-unbalanced-freeze-unfreeze.patch create mode 100644 queue-6.4/nvme-tcp-fix-potential-unbalanced-freeze-unfreeze.patch create mode 100644 queue-6.4/parisc-fix-lightweight-spinlock-checks-to-not-break-futexes.patch create mode 100644 queue-6.4/radix-tree-test-suite-fix-incorrect-allocation-size-for-pthreads.patch create mode 100644 queue-6.4/riscv-kexec-handle-r_riscv_call_plt-relocation-type.patch create mode 100644 queue-6.4/riscv-kexec-load-initrd-high-in-available-memory.patch create mode 100644 queue-6.4/riscv-mm-fix-2-instances-of-wmissing-variable-declarations.patch create mode 100644 queue-6.4/riscv-mmio-fix-readx-to-delay-ordering.patch create mode 100644 queue-6.4/riscv-start-of-dram-should-at-least-be-aligned-on-pmd-size-for-the-direct-mapping.patch create mode 100644 queue-6.4/selftests-mm-ksm-fix-incorrect-evaluation-of-parameter.patch create mode 100644 queue-6.4/selftests-mptcp-join-fix-delete-and-re-add-test.patch create mode 100644 queue-6.4/selftests-mptcp-join-fix-implicit-ep-test.patch create mode 100644 queue-6.4/tpm-tpm_tis-fix-upx-i11-dmi_match-condition.patch create mode 100644 queue-6.4/tpm_tis-opt-in-interrupts.patch create mode 100644 queue-6.4/zram-take-device-and-not-only-bvec-offset-into-account.patch create mode 100644 queue-6.4/zsmalloc-fix-races-between-modifications-of-fullness-and-isolated.patch diff --git a/queue-6.4/accel-ivpu-add-set_pages_array_wc-uc-for-internal-buffers.patch b/queue-6.4/accel-ivpu-add-set_pages_array_wc-uc-for-internal-buffers.patch new file mode 100644 index 00000000000..c38ce0044e3 --- /dev/null +++ b/queue-6.4/accel-ivpu-add-set_pages_array_wc-uc-for-internal-buffers.patch @@ -0,0 +1,54 @@ +From 1963546390ed8b649f529993a755eba0fdeb7aaa Mon Sep 17 00:00:00 2001 +From: Karol Wachowski +Date: Wed, 2 Aug 2023 08:37:35 +0200 +Subject: accel/ivpu: Add set_pages_array_wc/uc for internal buffers + +From: Karol Wachowski + +commit 1963546390ed8b649f529993a755eba0fdeb7aaa upstream. + +Buffers mapped with pgprot_writecombined() are not correctly +flushed. This triggers issues on VPU access using random +memory content such as MMU translation faults, invalid context +descriptors being fetched and can lead to VPU FW crashes. + +Fixes: 647371a6609d ("accel/ivpu: Add GEM buffer object management") +Cc: stable@vger.kernel.org # 6.3+ +Signed-off-by: Karol Wachowski +Reviewed-by: Stanislaw Gruszka +Signed-off-by: Stanislaw Gruszka +Link: https://patchwork.freedesktop.org/patch/msgid/20230802063735.3005291-1-stanislaw.gruszka@linux.intel.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/accel/ivpu/ivpu_gem.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +diff --git a/drivers/accel/ivpu/ivpu_gem.c b/drivers/accel/ivpu/ivpu_gem.c +index 52b339aefadc..9967fcfa27ec 100644 +--- a/drivers/accel/ivpu/ivpu_gem.c ++++ b/drivers/accel/ivpu/ivpu_gem.c +@@ -173,6 +173,9 @@ static void internal_free_pages_locked(struct ivpu_bo *bo) + { + unsigned int i, npages = bo->base.size >> PAGE_SHIFT; + ++ if (ivpu_bo_cache_mode(bo) != DRM_IVPU_BO_CACHED) ++ set_pages_array_wb(bo->pages, bo->base.size >> PAGE_SHIFT); ++ + for (i = 0; i < npages; i++) + put_page(bo->pages[i]); + +@@ -587,6 +590,11 @@ ivpu_bo_alloc_internal(struct ivpu_device *vdev, u64 vpu_addr, u64 size, u32 fla + if (ivpu_bo_cache_mode(bo) != DRM_IVPU_BO_CACHED) + drm_clflush_pages(bo->pages, bo->base.size >> PAGE_SHIFT); + ++ if (bo->flags & DRM_IVPU_BO_WC) ++ set_pages_array_wc(bo->pages, bo->base.size >> PAGE_SHIFT); ++ else if (bo->flags & DRM_IVPU_BO_UNCACHED) ++ set_pages_array_uc(bo->pages, bo->base.size >> PAGE_SHIFT); ++ + prot = ivpu_bo_pgprot(bo, PAGE_KERNEL); + bo->kvaddr = vmap(bo->pages, bo->base.size >> PAGE_SHIFT, VM_MAP, prot); + if (!bo->kvaddr) { +-- +2.41.0 + diff --git a/queue-6.4/acpi-resource-add-irq-override-quirk-for-pcspecialist-elimina-pro-16-m.patch b/queue-6.4/acpi-resource-add-irq-override-quirk-for-pcspecialist-elimina-pro-16-m.patch new file mode 100644 index 00000000000..62e3c4830d3 --- /dev/null +++ b/queue-6.4/acpi-resource-add-irq-override-quirk-for-pcspecialist-elimina-pro-16-m.patch @@ -0,0 +1,59 @@ +From 56fec0051a69ace182ca3fba47be9c13038b4e3f Mon Sep 17 00:00:00 2001 +From: Hans de Goede +Date: Thu, 10 Aug 2023 11:00:11 +0200 +Subject: ACPI: resource: Add IRQ override quirk for PCSpecialist Elimina Pro 16 M + +From: Hans de Goede + +commit 56fec0051a69ace182ca3fba47be9c13038b4e3f upstream. + +The PCSpecialist Elimina Pro 16 M laptop model is a Zen laptop which +needs to use the MADT IRQ settings override and which does not have +an INT_SRC_OVR entry for IRQ 1 in its MADT. + +So this model needs a DMI quirk to enable the MADT IRQ settings override +to fix its keyboard not working. + +Fixes: a9c4a912b7dc ("ACPI: resource: Remove "Zen" specific match and quirks") +Link: https://bugzilla.kernel.org/show_bug.cgi?id=217394#c18 +Cc: All applicable +Signed-off-by: Hans de Goede +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + drivers/acpi/resource.c | 12 ++++++++++++ + 1 file changed, 12 insertions(+) + +diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c +index 8e32dd5776f5..a4d9f149b48d 100644 +--- a/drivers/acpi/resource.c ++++ b/drivers/acpi/resource.c +@@ -498,6 +498,17 @@ static const struct dmi_system_id maingear_laptop[] = { + { } + }; + ++static const struct dmi_system_id pcspecialist_laptop[] = { ++ { ++ .ident = "PCSpecialist Elimina Pro 16 M", ++ .matches = { ++ DMI_MATCH(DMI_SYS_VENDOR, "PCSpecialist"), ++ DMI_MATCH(DMI_PRODUCT_NAME, "Elimina Pro 16 M"), ++ }, ++ }, ++ { } ++}; ++ + static const struct dmi_system_id lg_laptop[] = { + { + .ident = "LG Electronics 17U70P", +@@ -523,6 +534,7 @@ static const struct irq_override_cmp override_table[] = { + { asus_laptop, 1, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW, 0, false }, + { tongfang_gm_rg, 1, ACPI_EDGE_SENSITIVE, ACPI_ACTIVE_LOW, 1, true }, + { maingear_laptop, 1, ACPI_EDGE_SENSITIVE, ACPI_ACTIVE_LOW, 1, true }, ++ { pcspecialist_laptop, 1, ACPI_EDGE_SENSITIVE, ACPI_ACTIVE_LOW, 1, true }, + { lg_laptop, 1, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW, 0, false }, + }; + +-- +2.41.0 + diff --git a/queue-6.4/acpi-resource-always-use-madt-override-irq-settings-for-all-legacy-non-i8042-irqs.patch b/queue-6.4/acpi-resource-always-use-madt-override-irq-settings-for-all-legacy-non-i8042-irqs.patch new file mode 100644 index 00000000000..c76278b861d --- /dev/null +++ b/queue-6.4/acpi-resource-always-use-madt-override-irq-settings-for-all-legacy-non-i8042-irqs.patch @@ -0,0 +1,78 @@ +From 9728ac221160c5ea111879125a7694bb81364720 Mon Sep 17 00:00:00 2001 +From: Hans de Goede +Date: Wed, 9 Aug 2023 10:55:24 +0200 +Subject: ACPI: resource: Always use MADT override IRQ settings for all legacy non i8042 IRQs + +From: Hans de Goede + +commit 9728ac221160c5ea111879125a7694bb81364720 upstream. + +All the cases, were the DSDT IRQ settings should be used instead of +the MADT override, are for IRQ 1 or 12, the PS/2 kbd resp. mouse IRQs. + +Simplify things by always honering the override for other legacy IRQs +(for non DMI quirked cases). + +This allows removing the DMI quirks to honor the override for +some non i8042 IRQs on some AMD ZEN based Lenovo models. + +Fixes: a9c4a912b7dc ("ACPI: resource: Remove "Zen" specific match and quirks") +Cc: All applicable +Signed-off-by: Hans de Goede +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + drivers/acpi/resource.c | 28 ++++++++-------------------- + 1 file changed, 8 insertions(+), 20 deletions(-) + +--- a/drivers/acpi/resource.c ++++ b/drivers/acpi/resource.c +@@ -470,24 +470,6 @@ static const struct dmi_system_id asus_l + { } + }; + +-static const struct dmi_system_id lenovo_laptop[] = { +- { +- .ident = "LENOVO IdeaPad Flex 5 14ALC7", +- .matches = { +- DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), +- DMI_MATCH(DMI_PRODUCT_NAME, "82R9"), +- }, +- }, +- { +- .ident = "LENOVO IdeaPad Flex 5 16ALC7", +- .matches = { +- DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), +- DMI_MATCH(DMI_PRODUCT_NAME, "82RA"), +- }, +- }, +- { } +-}; +- + static const struct dmi_system_id tongfang_gm_rg[] = { + { + .ident = "TongFang GMxRGxx/XMG CORE 15 (M22)/TUXEDO Stellaris 15 Gen4 AMD", +@@ -539,8 +521,6 @@ struct irq_override_cmp { + static const struct irq_override_cmp override_table[] = { + { medion_laptop, 1, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW, 0, false }, + { asus_laptop, 1, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW, 0, false }, +- { lenovo_laptop, 6, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW, 0, true }, +- { lenovo_laptop, 10, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW, 0, true }, + { tongfang_gm_rg, 1, ACPI_EDGE_SENSITIVE, ACPI_ACTIVE_LOW, 1, true }, + { maingear_laptop, 1, ACPI_EDGE_SENSITIVE, ACPI_ACTIVE_LOW, 1, true }, + { lg_laptop, 1, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW, 0, false }, +@@ -564,6 +544,14 @@ static bool acpi_dev_irq_override(u32 gs + + #ifdef CONFIG_X86 + /* ++ * Always use the MADT override info, except for the i8042 PS/2 ctrl ++ * IRQs (1 and 12). For these the DSDT IRQ settings should sometimes ++ * be used otherwise PS/2 keyboards / mice will not work. ++ */ ++ if (gsi != 1 && gsi != 12) ++ return true; ++ ++ /* + * IRQ override isn't needed on modern AMD Zen systems and + * this override breaks active low IRQs on AMD Ryzen 6000 and + * newer systems. Skip it. diff --git a/queue-6.4/acpi-resource-honor-madt-int_src_ovr-settings-for-irq1-on-amd-zen.patch b/queue-6.4/acpi-resource-honor-madt-int_src_ovr-settings-for-irq1-on-amd-zen.patch new file mode 100644 index 00000000000..389b7df3583 --- /dev/null +++ b/queue-6.4/acpi-resource-honor-madt-int_src_ovr-settings-for-irq1-on-amd-zen.patch @@ -0,0 +1,90 @@ +From c6a1fd910d1bf8a0e3db7aebb229e3c81bc305c4 Mon Sep 17 00:00:00 2001 +From: Hans de Goede +Date: Wed, 9 Aug 2023 10:55:25 +0200 +Subject: ACPI: resource: Honor MADT INT_SRC_OVR settings for IRQ1 on AMD Zen + +From: Hans de Goede + +commit c6a1fd910d1bf8a0e3db7aebb229e3c81bc305c4 upstream. + +On AMD Zen acpi_dev_irq_override() by default prefers the DSDT IRQ 1 +settings over the MADT settings. + +This causes the keyboard to malfunction on some laptop models +(see Links), all models from the Links have an INT_SRC_OVR MADT entry +for IRQ 1. + +Fixes: a9c4a912b7dc ("ACPI: resource: Remove "Zen" specific match and quirks") +Link: https://bugzilla.kernel.org/show_bug.cgi?id=217336 +Link: https://bugzilla.kernel.org/show_bug.cgi?id=217394 +Link: https://bugzilla.kernel.org/show_bug.cgi?id=217406 +Cc: All applicable +Signed-off-by: Hans de Goede +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/include/asm/acpi.h | 2 ++ + arch/x86/kernel/acpi/boot.c | 4 ++++ + drivers/acpi/resource.c | 4 ++++ + 3 files changed, 10 insertions(+) + +diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h +index 8eb74cf386db..2888c0ee4df0 100644 +--- a/arch/x86/include/asm/acpi.h ++++ b/arch/x86/include/asm/acpi.h +@@ -15,6 +15,7 @@ + #include + #include + #include ++#include + + #ifdef CONFIG_ACPI_APEI + # include +@@ -31,6 +32,7 @@ extern int acpi_skip_timer_override; + extern int acpi_use_timer_override; + extern int acpi_fix_pin2_polarity; + extern int acpi_disable_cmcff; ++extern bool acpi_int_src_ovr[NR_IRQS_LEGACY]; + + extern u8 acpi_sci_flags; + extern u32 acpi_sci_override_gsi; +diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c +index 21b542a6866c..53369c57751e 100644 +--- a/arch/x86/kernel/acpi/boot.c ++++ b/arch/x86/kernel/acpi/boot.c +@@ -52,6 +52,7 @@ int acpi_lapic; + int acpi_ioapic; + int acpi_strict; + int acpi_disable_cmcff; ++bool acpi_int_src_ovr[NR_IRQS_LEGACY]; + + /* ACPI SCI override configuration */ + u8 acpi_sci_flags __initdata; +@@ -588,6 +589,9 @@ acpi_parse_int_src_ovr(union acpi_subtable_headers * header, + + acpi_table_print_madt_entry(&header->common); + ++ if (intsrc->source_irq < NR_IRQS_LEGACY) ++ acpi_int_src_ovr[intsrc->source_irq] = true; ++ + if (intsrc->source_irq == acpi_gbl_FADT.sci_interrupt) { + acpi_sci_ioapic_setup(intsrc->source_irq, + intsrc->inti_flags & ACPI_MADT_POLARITY_MASK, +diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c +index 380cda1e86f4..8e32dd5776f5 100644 +--- a/drivers/acpi/resource.c ++++ b/drivers/acpi/resource.c +@@ -551,6 +551,10 @@ static bool acpi_dev_irq_override(u32 gsi, u8 triggering, u8 polarity, + if (gsi != 1 && gsi != 12) + return true; + ++ /* If the override comes from an INT_SRC_OVR MADT entry, honor it. */ ++ if (acpi_int_src_ovr[gsi]) ++ return true; ++ + /* + * IRQ override isn't needed on modern AMD Zen systems and + * this override breaks active low IRQs on AMD Ryzen 6000 and +-- +2.41.0 + diff --git a/queue-6.4/acpi-resource-revert-remove-zen-specific-match-and-quirks.patch b/queue-6.4/acpi-resource-revert-remove-zen-specific-match-and-quirks.patch new file mode 100644 index 00000000000..43f53e1f698 --- /dev/null +++ b/queue-6.4/acpi-resource-revert-remove-zen-specific-match-and-quirks.patch @@ -0,0 +1,120 @@ +From 2d331a6ac4815e2e2fe5f2d80d908566e57797cc Mon Sep 17 00:00:00 2001 +From: Hans de Goede +Date: Wed, 9 Aug 2023 10:55:23 +0200 +Subject: ACPI: resource: revert "Remove "Zen" specific match and quirks" + +From: Hans de Goede + +commit 2d331a6ac4815e2e2fe5f2d80d908566e57797cc upstream. + +Commit a9c4a912b7dc ("ACPI: resource: Remove "Zen" specific match and +quirks") is causing keyboard problems for quite a log of AMD based +laptop users, leading to many bug reports. + +Revert this change for now, until we can come up with +a better fix for the PS/2 IRQ trigger-type/polarity problems +on some x86 laptops. + +Fixes: a9c4a912b7dc ("ACPI: resource: Remove "Zen" specific match and quirks") +Link: https://bugzilla.redhat.com/show_bug.cgi?id=2228891 +Link: https://bugzilla.redhat.com/show_bug.cgi?id=2229165 +Link: https://bugzilla.redhat.com/show_bug.cgi?id=2229317 +Link: https://bugzilla.kernel.org/show_bug.cgi?id=217718 +Link: https://bugzilla.kernel.org/show_bug.cgi?id=217726 +Link: https://bugzilla.kernel.org/show_bug.cgi?id=217731 +Cc: All applicable +Signed-off-by: Hans de Goede +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + drivers/acpi/resource.c | 60 +++++++++++++++++++++++++++++++++++++++++ + 1 file changed, 60 insertions(+) + +diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c +index 1dd8d5aebf67..0800a9d77558 100644 +--- a/drivers/acpi/resource.c ++++ b/drivers/acpi/resource.c +@@ -470,6 +470,52 @@ static const struct dmi_system_id asus_laptop[] = { + { } + }; + ++static const struct dmi_system_id lenovo_laptop[] = { ++ { ++ .ident = "LENOVO IdeaPad Flex 5 14ALC7", ++ .matches = { ++ DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), ++ DMI_MATCH(DMI_PRODUCT_NAME, "82R9"), ++ }, ++ }, ++ { ++ .ident = "LENOVO IdeaPad Flex 5 16ALC7", ++ .matches = { ++ DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), ++ DMI_MATCH(DMI_PRODUCT_NAME, "82RA"), ++ }, ++ }, ++ { } ++}; ++ ++static const struct dmi_system_id tongfang_gm_rg[] = { ++ { ++ .ident = "TongFang GMxRGxx/XMG CORE 15 (M22)/TUXEDO Stellaris 15 Gen4 AMD", ++ .matches = { ++ DMI_MATCH(DMI_BOARD_NAME, "GMxRGxx"), ++ }, ++ }, ++ { } ++}; ++ ++static const struct dmi_system_id maingear_laptop[] = { ++ { ++ .ident = "MAINGEAR Vector Pro 2 15", ++ .matches = { ++ DMI_MATCH(DMI_SYS_VENDOR, "Micro Electronics Inc"), ++ DMI_MATCH(DMI_PRODUCT_NAME, "MG-VCP2-15A3070T"), ++ } ++ }, ++ { ++ .ident = "MAINGEAR Vector Pro 2 17", ++ .matches = { ++ DMI_MATCH(DMI_SYS_VENDOR, "Micro Electronics Inc"), ++ DMI_MATCH(DMI_PRODUCT_NAME, "MG-VCP2-17A3070T"), ++ }, ++ }, ++ { } ++}; ++ + static const struct dmi_system_id lg_laptop[] = { + { + .ident = "LG Electronics 17U70P", +@@ -493,6 +539,10 @@ struct irq_override_cmp { + static const struct irq_override_cmp override_table[] = { + { medion_laptop, 1, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW, 0, false }, + { asus_laptop, 1, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW, 0, false }, ++ { lenovo_laptop, 6, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW, 0, true }, ++ { lenovo_laptop, 10, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW, 0, true }, ++ { tongfang_gm_rg, 1, ACPI_EDGE_SENSITIVE, ACPI_ACTIVE_LOW, 1, true }, ++ { maingear_laptop, 1, ACPI_EDGE_SENSITIVE, ACPI_ACTIVE_LOW, 1, true }, + { lg_laptop, 1, ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_LOW, 0, false }, + }; + +@@ -512,6 +562,16 @@ static bool acpi_dev_irq_override(u32 gsi, u8 triggering, u8 polarity, + return entry->override; + } + ++#ifdef CONFIG_X86 ++ /* ++ * IRQ override isn't needed on modern AMD Zen systems and ++ * this override breaks active low IRQs on AMD Ryzen 6000 and ++ * newer systems. Skip it. ++ */ ++ if (boot_cpu_has(X86_FEATURE_ZEN)) ++ return false; ++#endif ++ + return true; + } + +-- +2.41.0 + diff --git a/queue-6.4/cpufreq-amd-pstate-fix-global-sysfs-attribute-type.patch b/queue-6.4/cpufreq-amd-pstate-fix-global-sysfs-attribute-type.patch new file mode 100644 index 00000000000..ed929191eea --- /dev/null +++ b/queue-6.4/cpufreq-amd-pstate-fix-global-sysfs-attribute-type.patch @@ -0,0 +1,100 @@ +From 5e720f8c8c9d959283c3908bbf32a91a01a86547 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Thomas=20Wei=C3=9Fschuh?= +Date: Mon, 7 Aug 2023 08:37:45 +0200 +Subject: cpufreq: amd-pstate: fix global sysfs attribute type +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Thomas Weißschuh + +commit 5e720f8c8c9d959283c3908bbf32a91a01a86547 upstream. + +In commit 3666062b87ec ("cpufreq: amd-pstate: move to use bus_get_dev_root()") +the "amd_pstate" attributes where moved from a dedicated kobject to the +cpu root kobject. + +While the dedicated kobject expects to contain kobj_attributes the root +kobject needs device_attributes. + +As the changed arguments are not used by the callbacks it works most of +the time. +However CFI will detect this issue: + +[ 4947.849350] CFI failure at dev_attr_show+0x24/0x60 (target: show_status+0x0/0x70; expected type: 0x8651b1de) +... +[ 4947.849409] Call Trace: +[ 4947.849410] +[ 4947.849411] ? __warn+0xcf/0x1c0 +[ 4947.849414] ? dev_attr_show+0x24/0x60 +[ 4947.849415] ? report_cfi_failure+0x4e/0x60 +[ 4947.849417] ? handle_cfi_failure+0x14c/0x1d0 +[ 4947.849419] ? __cfi_show_status+0x10/0x10 +[ 4947.849420] ? handle_bug+0x4f/0x90 +[ 4947.849421] ? exc_invalid_op+0x1a/0x60 +[ 4947.849422] ? asm_exc_invalid_op+0x1a/0x20 +[ 4947.849424] ? __cfi_show_status+0x10/0x10 +[ 4947.849425] ? dev_attr_show+0x24/0x60 +[ 4947.849426] sysfs_kf_seq_show+0xa6/0x110 +[ 4947.849433] seq_read_iter+0x16c/0x4b0 +[ 4947.849436] vfs_read+0x272/0x2d0 +[ 4947.849438] ksys_read+0x72/0xe0 +[ 4947.849439] do_syscall_64+0x76/0xb0 +[ 4947.849440] ? do_user_addr_fault+0x252/0x650 +[ 4947.849442] ? exc_page_fault+0x7a/0x1b0 +[ 4947.849443] entry_SYSCALL_64_after_hwframe+0x72/0xdc + +Fixes: 3666062b87ec ("cpufreq: amd-pstate: move to use bus_get_dev_root()") +Reported-by: Jannik Glückert +Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217765 +Link: https://lore.kernel.org/lkml/c7f1bf9b-b183-bf6e-1cbb-d43f72494083@gmail.com/ +Cc: All applicable +Signed-off-by: Thomas Weißschuh +Reviewed-by: Greg Kroah-Hartman +Reviewed-by: Nathan Chancellor +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + drivers/cpufreq/amd-pstate.c | 10 +++++----- + 1 file changed, 5 insertions(+), 5 deletions(-) + +--- a/drivers/cpufreq/amd-pstate.c ++++ b/drivers/cpufreq/amd-pstate.c +@@ -986,8 +986,8 @@ static int amd_pstate_update_status(cons + return 0; + } + +-static ssize_t show_status(struct kobject *kobj, +- struct kobj_attribute *attr, char *buf) ++static ssize_t status_show(struct device *dev, ++ struct device_attribute *attr, char *buf) + { + ssize_t ret; + +@@ -998,7 +998,7 @@ static ssize_t show_status(struct kobjec + return ret; + } + +-static ssize_t store_status(struct kobject *a, struct kobj_attribute *b, ++static ssize_t status_store(struct device *a, struct device_attribute *b, + const char *buf, size_t count) + { + char *p = memchr(buf, '\n', count); +@@ -1017,7 +1017,7 @@ cpufreq_freq_attr_ro(amd_pstate_lowest_n + cpufreq_freq_attr_ro(amd_pstate_highest_perf); + cpufreq_freq_attr_rw(energy_performance_preference); + cpufreq_freq_attr_ro(energy_performance_available_preferences); +-define_one_global_rw(status); ++static DEVICE_ATTR_RW(status); + + static struct freq_attr *amd_pstate_attr[] = { + &amd_pstate_max_freq, +@@ -1036,7 +1036,7 @@ static struct freq_attr *amd_pstate_epp_ + }; + + static struct attribute *pstate_global_attributes[] = { +- &status.attr, ++ &dev_attr_status.attr, + NULL + }; + diff --git a/queue-6.4/cpuidle-dt_idle_genpd-add-helper-function-to-remove-genpd-topology.patch b/queue-6.4/cpuidle-dt_idle_genpd-add-helper-function-to-remove-genpd-topology.patch new file mode 100644 index 00000000000..5fb59668fc2 --- /dev/null +++ b/queue-6.4/cpuidle-dt_idle_genpd-add-helper-function-to-remove-genpd-topology.patch @@ -0,0 +1,80 @@ +From 9a8fa00dad3c7b260071f2f220cfb00505372c40 Mon Sep 17 00:00:00 2001 +From: Maulik Shah +Date: Mon, 3 Jul 2023 14:25:53 +0530 +Subject: cpuidle: dt_idle_genpd: Add helper function to remove genpd topology + +From: Maulik Shah + +commit 9a8fa00dad3c7b260071f2f220cfb00505372c40 upstream. + +Genpd parent and child domain topology created using dt_idle_pd_init_topology() +needs to be removed during error cases. + +Add new helper function dt_idle_pd_remove_topology() for same. + +Cc: stable@vger.kernel.org +Reviewed-by: Ulf Hanssson +Signed-off-by: Maulik Shah +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/cpuidle/dt_idle_genpd.c | 24 ++++++++++++++++++++++++ + drivers/cpuidle/dt_idle_genpd.h | 7 +++++++ + 2 files changed, 31 insertions(+) + +--- a/drivers/cpuidle/dt_idle_genpd.c ++++ b/drivers/cpuidle/dt_idle_genpd.c +@@ -152,6 +152,30 @@ int dt_idle_pd_init_topology(struct devi + return 0; + } + ++int dt_idle_pd_remove_topology(struct device_node *np) ++{ ++ struct device_node *node; ++ struct of_phandle_args child, parent; ++ int ret; ++ ++ for_each_child_of_node(np, node) { ++ if (of_parse_phandle_with_args(node, "power-domains", ++ "#power-domain-cells", 0, &parent)) ++ continue; ++ ++ child.np = node; ++ child.args_count = 0; ++ ret = of_genpd_remove_subdomain(&parent, &child); ++ of_node_put(parent.np); ++ if (ret) { ++ of_node_put(node); ++ return ret; ++ } ++ } ++ ++ return 0; ++} ++ + struct device *dt_idle_attach_cpu(int cpu, const char *name) + { + struct device *dev; +--- a/drivers/cpuidle/dt_idle_genpd.h ++++ b/drivers/cpuidle/dt_idle_genpd.h +@@ -14,6 +14,8 @@ struct generic_pm_domain *dt_idle_pd_all + + int dt_idle_pd_init_topology(struct device_node *np); + ++int dt_idle_pd_remove_topology(struct device_node *np); ++ + struct device *dt_idle_attach_cpu(int cpu, const char *name); + + void dt_idle_detach_cpu(struct device *dev); +@@ -35,6 +37,11 @@ static inline int dt_idle_pd_init_topolo + { + return 0; + } ++ ++static inline int dt_idle_pd_remove_topology(struct device_node *np) ++{ ++ return 0; ++} + + static inline struct device *dt_idle_attach_cpu(int cpu, const char *name) + { diff --git a/queue-6.4/cpuidle-psci-move-enabling-osi-mode-after-power-domains-creation.patch b/queue-6.4/cpuidle-psci-move-enabling-osi-mode-after-power-domains-creation.patch new file mode 100644 index 00000000000..9911a2ff424 --- /dev/null +++ b/queue-6.4/cpuidle-psci-move-enabling-osi-mode-after-power-domains-creation.patch @@ -0,0 +1,118 @@ +From 12acb348fa4528a4203edf1cce7a3be2c9af2279 Mon Sep 17 00:00:00 2001 +From: Maulik Shah +Date: Mon, 3 Jul 2023 14:25:54 +0530 +Subject: cpuidle: psci: Move enabling OSI mode after power domains creation + +From: Maulik Shah + +commit 12acb348fa4528a4203edf1cce7a3be2c9af2279 upstream. + +A switch from OSI to PC mode is only possible if all CPUs other than the +calling one are OFF, either through a call to CPU_OFF or not yet booted. + +Currently OSI mode is enabled before power domains are created. In cases +where CPUidle states are not using hierarchical CPU topology the bail out +path tries to switch back to PC mode which gets denied by firmware since +other CPUs are online at this point and creates inconsistent state as +firmware is in OSI mode and Linux in PC mode. + +This change moves enabling OSI mode after power domains are created, +this would makes sure that hierarchical CPU topology is used before +switching firmware to OSI mode. + +Cc: stable@vger.kernel.org +Fixes: 70c179b49870 ("cpuidle: psci: Allow PM domain to be initialized even if no OSI mode") +Signed-off-by: Maulik Shah +Reviewed-by: Ulf Hansson +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/cpuidle/cpuidle-psci-domain.c | 39 +++++++++++----------------------- + 1 file changed, 13 insertions(+), 26 deletions(-) + +--- a/drivers/cpuidle/cpuidle-psci-domain.c ++++ b/drivers/cpuidle/cpuidle-psci-domain.c +@@ -120,20 +120,6 @@ static void psci_pd_remove(void) + } + } + +-static bool psci_pd_try_set_osi_mode(void) +-{ +- int ret; +- +- if (!psci_has_osi_support()) +- return false; +- +- ret = psci_set_osi_mode(true); +- if (ret) +- return false; +- +- return true; +-} +- + static void psci_cpuidle_domain_sync_state(struct device *dev) + { + /* +@@ -152,15 +138,12 @@ static int psci_cpuidle_domain_probe(str + { + struct device_node *np = pdev->dev.of_node; + struct device_node *node; +- bool use_osi; ++ bool use_osi = psci_has_osi_support(); + int ret = 0, pd_count = 0; + + if (!np) + return -ENODEV; + +- /* If OSI mode is supported, let's try to enable it. */ +- use_osi = psci_pd_try_set_osi_mode(); +- + /* + * Parse child nodes for the "#power-domain-cells" property and + * initialize a genpd/genpd-of-provider pair when it's found. +@@ -170,33 +153,37 @@ static int psci_cpuidle_domain_probe(str + continue; + + ret = psci_pd_init(node, use_osi); +- if (ret) +- goto put_node; ++ if (ret) { ++ of_node_put(node); ++ goto exit; ++ } + + pd_count++; + } + + /* Bail out if not using the hierarchical CPU topology. */ + if (!pd_count) +- goto no_pd; ++ return 0; + + /* Link genpd masters/subdomains to model the CPU topology. */ + ret = dt_idle_pd_init_topology(np); + if (ret) + goto remove_pd; + ++ /* let's try to enable OSI. */ ++ ret = psci_set_osi_mode(use_osi); ++ if (ret) ++ goto remove_pd; ++ + pr_info("Initialized CPU PM domain topology using %s mode\n", + use_osi ? "OSI" : "PC"); + return 0; + +-put_node: +- of_node_put(node); + remove_pd: ++ dt_idle_pd_remove_topology(np); + psci_pd_remove(); ++exit: + pr_err("failed to create CPU PM domains ret=%d\n", ret); +-no_pd: +- if (use_osi) +- psci_set_osi_mode(false); + return ret; + } + diff --git a/queue-6.4/dmaengine-pl330-return-dma_paused-when-transaction-is-paused.patch b/queue-6.4/dmaengine-pl330-return-dma_paused-when-transaction-is-paused.patch new file mode 100644 index 00000000000..0b543d24537 --- /dev/null +++ b/queue-6.4/dmaengine-pl330-return-dma_paused-when-transaction-is-paused.patch @@ -0,0 +1,98 @@ +From 8cda3ececf07d374774f6a13e5a94bc2dc04c26c Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= +Date: Fri, 26 May 2023 13:54:34 +0300 +Subject: dmaengine: pl330: Return DMA_PAUSED when transaction is paused +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Ilpo Järvinen + +commit 8cda3ececf07d374774f6a13e5a94bc2dc04c26c upstream. + +pl330_pause() does not set anything to indicate paused condition which +causes pl330_tx_status() to return DMA_IN_PROGRESS. This breaks 8250 +DMA flush after the fix in commit 57e9af7831dc ("serial: 8250_dma: Fix +DMA Rx rearm race"). The function comment for pl330_pause() claims +pause is supported but resume is not which is enough for 8250 DMA flush +to work as long as DMA status reports DMA_PAUSED when appropriate. + +Add PAUSED state for descriptor and mark BUSY descriptors with PAUSED +in pl330_pause(). Return DMA_PAUSED from pl330_tx_status() when the +descriptor is PAUSED. + +Reported-by: Richard Tresidder +Tested-by: Richard Tresidder +Fixes: 88987d2c7534 ("dmaengine: pl330: add DMA_PAUSE feature") +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/linux-serial/f8a86ecd-64b1-573f-c2fa-59f541083f1a@electromag.com.au/ +Signed-off-by: Ilpo Järvinen +Link: https://lore.kernel.org/r/20230526105434.14959-1-ilpo.jarvinen@linux.intel.com +Signed-off-by: Vinod Koul +Signed-off-by: Greg Kroah-Hartman +--- + drivers/dma/pl330.c | 18 ++++++++++++++++-- + 1 file changed, 16 insertions(+), 2 deletions(-) + +--- a/drivers/dma/pl330.c ++++ b/drivers/dma/pl330.c +@@ -404,6 +404,12 @@ enum desc_status { + */ + BUSY, + /* ++ * Pause was called while descriptor was BUSY. Due to hardware ++ * limitations, only termination is possible for descriptors ++ * that have been paused. ++ */ ++ PAUSED, ++ /* + * Sitting on the channel work_list but xfer done + * by PL330 core + */ +@@ -2041,7 +2047,7 @@ static inline void fill_queue(struct dma + list_for_each_entry(desc, &pch->work_list, node) { + + /* If already submitted */ +- if (desc->status == BUSY) ++ if (desc->status == BUSY || desc->status == PAUSED) + continue; + + ret = pl330_submit_req(pch->thread, desc); +@@ -2326,6 +2332,7 @@ static int pl330_pause(struct dma_chan * + { + struct dma_pl330_chan *pch = to_pchan(chan); + struct pl330_dmac *pl330 = pch->dmac; ++ struct dma_pl330_desc *desc; + unsigned long flags; + + pm_runtime_get_sync(pl330->ddma.dev); +@@ -2335,6 +2342,10 @@ static int pl330_pause(struct dma_chan * + _stop(pch->thread); + spin_unlock(&pl330->lock); + ++ list_for_each_entry(desc, &pch->work_list, node) { ++ if (desc->status == BUSY) ++ desc->status = PAUSED; ++ } + spin_unlock_irqrestore(&pch->lock, flags); + pm_runtime_mark_last_busy(pl330->ddma.dev); + pm_runtime_put_autosuspend(pl330->ddma.dev); +@@ -2425,7 +2436,7 @@ pl330_tx_status(struct dma_chan *chan, d + else if (running && desc == running) + transferred = + pl330_get_current_xferred_count(pch, desc); +- else if (desc->status == BUSY) ++ else if (desc->status == BUSY || desc->status == PAUSED) + /* + * Busy but not running means either just enqueued, + * or finished and not yet marked done +@@ -2442,6 +2453,9 @@ pl330_tx_status(struct dma_chan *chan, d + case DONE: + ret = DMA_COMPLETE; + break; ++ case PAUSED: ++ ret = DMA_PAUSED; ++ break; + case PREP: + case BUSY: + ret = DMA_IN_PROGRESS; diff --git a/queue-6.4/dmaengine-xilinx-xdma-fix-interrupt-vector-setting.patch b/queue-6.4/dmaengine-xilinx-xdma-fix-interrupt-vector-setting.patch new file mode 100644 index 00000000000..776e95e6f47 --- /dev/null +++ b/queue-6.4/dmaengine-xilinx-xdma-fix-interrupt-vector-setting.patch @@ -0,0 +1,46 @@ +From 96891e90d1256b569b1c183e7c9a0cfc568fa3b0 Mon Sep 17 00:00:00 2001 +From: Miquel Raynal +Date: Mon, 31 Jul 2023 12:14:39 +0200 +Subject: dmaengine: xilinx: xdma: Fix interrupt vector setting + +From: Miquel Raynal + +commit 96891e90d1256b569b1c183e7c9a0cfc568fa3b0 upstream. + +A couple of hardware registers need to be set to reflect which +interrupts have been allocated to the device. Each register is 32-bit +wide and can receive four 8-bit values. If we provide any other interrupt +number than four, the irq_num variable will never be 0 within the while +check and the while block will loop forever. + +There is an easy way to prevent this: just break the for loop +when we reach "irq_num == 0", which anyway means all interrupts have +been processed. + +Cc: stable@vger.kernel.org +Fixes: 17ce252266c7 ("dmaengine: xilinx: xdma: Add xilinx xdma driver") +Signed-off-by: Miquel Raynal +Acked-by: Lizhi Hou +Link: https://lore.kernel.org/r/20230731101442.792514-2-miquel.raynal@bootlin.com +Signed-off-by: Vinod Koul +Signed-off-by: Greg Kroah-Hartman +--- + drivers/dma/xilinx/xdma.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/drivers/dma/xilinx/xdma.c b/drivers/dma/xilinx/xdma.c +index ad5ff63354cf..5116188b9977 100644 +--- a/drivers/dma/xilinx/xdma.c ++++ b/drivers/dma/xilinx/xdma.c +@@ -668,6 +668,8 @@ static int xdma_set_vector_reg(struct xdma_device *xdev, u32 vec_tbl_start, + val |= irq_start << shift; + irq_start++; + irq_num--; ++ if (!irq_num) ++ break; + } + + /* write IRQ register */ +-- +2.41.0 + diff --git a/queue-6.4/drm-amd-disable-s-g-for-apus-when-64gb-or-more-host-memory.patch b/queue-6.4/drm-amd-disable-s-g-for-apus-when-64gb-or-more-host-memory.patch new file mode 100644 index 00000000000..6afebf891b6 --- /dev/null +++ b/queue-6.4/drm-amd-disable-s-g-for-apus-when-64gb-or-more-host-memory.patch @@ -0,0 +1,95 @@ +From 08fffa74d9772d9538338be3f304006c94dde6f0 Mon Sep 17 00:00:00 2001 +From: Mario Limonciello +Date: Thu, 27 Jul 2023 10:22:20 -0500 +Subject: drm/amd: Disable S/G for APUs when 64GB or more host memory + +From: Mario Limonciello + +commit 08fffa74d9772d9538338be3f304006c94dde6f0 upstream. + +Users report a white flickering screen on multiple systems that +is tied to having 64GB or more memory. When S/G is enabled pages +will get pinned to both VRAM carve out and system RAM leading to +this. + +Until it can be fixed properly, disable S/G when 64GB of memory or +more is detected. This will force pages to be pinned into VRAM. +This should fix white screen flickers but if VRAM pressure is +encountered may lead to black screens. It's a trade-off for now. + +Fixes: 81d0bcf99009 ("drm/amdgpu: make display pinning more flexible (v2)") +Cc: Hamza Mahfooz +Cc: Roman Li +Cc: # 6.1.y: bf0207e172703 ("drm/amdgpu: add S/G display parameter") +Cc: # 6.4.y +Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2735 +Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2354 +Signed-off-by: Mario Limonciello +Reviewed-by: Alex Deucher +Signed-off-by: Alex Deucher +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 26 ++++++++++++++++++++++ + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +--- + 3 files changed, 29 insertions(+), 3 deletions(-) + +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h +@@ -1246,6 +1246,7 @@ int amdgpu_device_gpu_recover(struct amd + void amdgpu_device_pci_config_reset(struct amdgpu_device *adev); + int amdgpu_device_pci_reset(struct amdgpu_device *adev); + bool amdgpu_device_need_post(struct amdgpu_device *adev); ++bool amdgpu_sg_display_supported(struct amdgpu_device *adev); + bool amdgpu_device_pcie_dynamic_switching_supported(void); + bool amdgpu_device_should_use_aspm(struct amdgpu_device *adev); + bool amdgpu_device_aspm_support_quirk(void); +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +@@ -1353,6 +1353,32 @@ bool amdgpu_device_need_post(struct amdg + } + + /* ++ * On APUs with >= 64GB white flickering has been observed w/ SG enabled. ++ * Disable S/G on such systems until we have a proper fix. ++ * https://gitlab.freedesktop.org/drm/amd/-/issues/2354 ++ * https://gitlab.freedesktop.org/drm/amd/-/issues/2735 ++ */ ++bool amdgpu_sg_display_supported(struct amdgpu_device *adev) ++{ ++ switch (amdgpu_sg_display) { ++ case -1: ++ break; ++ case 0: ++ return false; ++ case 1: ++ return true; ++ default: ++ return false; ++ } ++ if ((totalram_pages() << (PAGE_SHIFT - 10)) + ++ (adev->gmc.real_vram_size / 1024) >= 64000000) { ++ DRM_WARN("Disabling S/G due to >=64GB RAM\n"); ++ return false; ++ } ++ return true; ++} ++ ++/* + * Intel hosts such as Raptor Lake and Sapphire Rapids don't support dynamic + * speed switching. Until we have confirmation from Intel that a specific host + * supports it, it's safer that we keep it disabled for all. +--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c ++++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +@@ -1630,9 +1630,8 @@ static int amdgpu_dm_init(struct amdgpu_ + } + break; + } +- if (init_data.flags.gpu_vm_support && +- (amdgpu_sg_display == 0)) +- init_data.flags.gpu_vm_support = false; ++ if (init_data.flags.gpu_vm_support) ++ init_data.flags.gpu_vm_support = amdgpu_sg_display_supported(adev); + + if (init_data.flags.gpu_vm_support) + adev->mode_info.gpu_vm_support = true; diff --git a/queue-6.4/drm-amd-display-check-attr-flag-before-set-cursor-degamma-on-dcn3.patch b/queue-6.4/drm-amd-display-check-attr-flag-before-set-cursor-degamma-on-dcn3.patch new file mode 100644 index 00000000000..1ad71ec6912 --- /dev/null +++ b/queue-6.4/drm-amd-display-check-attr-flag-before-set-cursor-degamma-on-dcn3.patch @@ -0,0 +1,48 @@ +From 96b020e2163fb2197266b2f71b1007495206e6bb Mon Sep 17 00:00:00 2001 +From: Melissa Wen +Date: Mon, 31 Jul 2023 07:35:05 -0100 +Subject: drm/amd/display: check attr flag before set cursor degamma on DCN3+ + +From: Melissa Wen + +commit 96b020e2163fb2197266b2f71b1007495206e6bb upstream. + +Don't set predefined degamma curve to cursor plane if the cursor +attribute flag is not set. Applying a degamma curve to the cursor by +default breaks userspace expectation. Checking the flag before +performing any color transformation prevents too dark cursor gamma in +DCN3+ on many Linux desktop environment (KDE Plasma, GNOME, +wlroots-based, etc.) as reported at: +- https://gitlab.freedesktop.org/drm/amd/-/issues/1513 + +This is the same approach followed by DCN2 drivers where the issue is +not present. + +Fixes: 03f54d7d3448 ("drm/amd/display: Add DCN3 DPP") +Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1513 +Signed-off-by: Melissa Wen +Reviewed-by: Harry Wentland +Tested-by: Alex Hung +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c | 7 +++++-- + 1 file changed, 5 insertions(+), 2 deletions(-) + +--- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c ++++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_dpp.c +@@ -357,8 +357,11 @@ void dpp3_set_cursor_attributes( + int cur_rom_en = 0; + + if (color_format == CURSOR_MODE_COLOR_PRE_MULTIPLIED_ALPHA || +- color_format == CURSOR_MODE_COLOR_UN_PRE_MULTIPLIED_ALPHA) +- cur_rom_en = 1; ++ color_format == CURSOR_MODE_COLOR_UN_PRE_MULTIPLIED_ALPHA) { ++ if (cursor_attributes->attribute_flags.bits.ENABLE_CURSOR_DEGAMMA) { ++ cur_rom_en = 1; ++ } ++ } + + REG_UPDATE_3(CURSOR0_CONTROL, + CUR0_MODE, color_format, diff --git a/queue-6.4/drm-amd-display-fix-a-regression-on-polaris-cards.patch b/queue-6.4/drm-amd-display-fix-a-regression-on-polaris-cards.patch new file mode 100644 index 00000000000..139a621033c --- /dev/null +++ b/queue-6.4/drm-amd-display-fix-a-regression-on-polaris-cards.patch @@ -0,0 +1,42 @@ +From 3bb575572bf498a9d39e9d1ca5c06cc3152928a1 Mon Sep 17 00:00:00 2001 +From: Mario Limonciello +Date: Fri, 28 Jul 2023 17:04:01 -0500 +Subject: drm/amd/display: Fix a regression on Polaris cards + +From: Mario Limonciello + +commit 3bb575572bf498a9d39e9d1ca5c06cc3152928a1 upstream. + +DCE products don't define a `remove_stream_from_ctx` like DCN ones +do. This means that when compute_mst_dsc_configs_for_state() is called +it always returns -EINVAL which causes MST to fail to setup. + +Cc: stable@vger.kernel.org # 6.4.y +Cc: Harry Wentland +Reported-by: Klaus.Kusche@computerix.info +Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2671 +Fixes: efa4c4df864e ("drm/amd/display: call remove_stream_from_ctx from res_pool funcs") +Signed-off-by: Mario Limonciello +Reviewed-by: Harry Wentland +Signed-off-by: Alex Deucher +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c +index 9bc86deac9e8..b885c39bd16b 100644 +--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c ++++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c +@@ -1320,7 +1320,7 @@ int compute_mst_dsc_configs_for_state(struct drm_atomic_state *state, + if (computed_streams[i]) + continue; + +- if (!res_pool->funcs->remove_stream_from_ctx || ++ if (res_pool->funcs->remove_stream_from_ctx && + res_pool->funcs->remove_stream_from_ctx(stream->ctx->dc, dc_state, stream) != DC_OK) + return -EINVAL; + +-- +2.41.0 + diff --git a/queue-6.4/drm-amd-pm-correct-the-pcie-width-for-smu-13.0.0.patch b/queue-6.4/drm-amd-pm-correct-the-pcie-width-for-smu-13.0.0.patch new file mode 100644 index 00000000000..8625d5c524b --- /dev/null +++ b/queue-6.4/drm-amd-pm-correct-the-pcie-width-for-smu-13.0.0.patch @@ -0,0 +1,40 @@ +From bd60e2eafd8fb053948b6e23e8167baf7a159750 Mon Sep 17 00:00:00 2001 +From: Kenneth Feng +Date: Thu, 27 Jul 2023 19:37:31 +0800 +Subject: drm/amd/pm: correct the pcie width for smu 13.0.0 + +From: Kenneth Feng + +commit bd60e2eafd8fb053948b6e23e8167baf7a159750 upstream. + +correct the pcie width value in pp_dpm_pcie for smu 13.0.0 + +Signed-off-by: Kenneth Feng +Reviewed-by: Harish Kasiviswanathan +Acked-by: Alex Deucher +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c ++++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c +@@ -1030,7 +1030,6 @@ static int smu_v13_0_0_print_clk_levels( + struct smu_13_0_dpm_context *dpm_context = smu_dpm->dpm_context; + struct smu_13_0_dpm_table *single_dpm_table; + struct smu_13_0_pcie_table *pcie_table; +- const int link_width[] = {0, 1, 2, 4, 8, 12, 16}; + uint32_t gen_speed, lane_width; + int i, curr_freq, size = 0; + int ret = 0; +@@ -1145,7 +1144,7 @@ static int smu_v13_0_0_print_clk_levels( + (pcie_table->pcie_lane[i] == 6) ? "x16" : "", + pcie_table->clk_freq[i], + (gen_speed == DECODE_GEN_SPEED(pcie_table->pcie_gen[i])) && +- (lane_width == DECODE_LANE_WIDTH(link_width[pcie_table->pcie_lane[i]])) ? ++ (lane_width == DECODE_LANE_WIDTH(pcie_table->pcie_lane[i])) ? + "*" : ""); + break; + diff --git a/queue-6.4/drm-amdgpu-fix-possible-uaf-in-amdgpu_cs_pass1.patch b/queue-6.4/drm-amdgpu-fix-possible-uaf-in-amdgpu_cs_pass1.patch new file mode 100644 index 00000000000..b494cc95a3d --- /dev/null +++ b/queue-6.4/drm-amdgpu-fix-possible-uaf-in-amdgpu_cs_pass1.patch @@ -0,0 +1,37 @@ +From 90e065677e0362a777b9db97ea21d43a39211399 Mon Sep 17 00:00:00 2001 +From: Alex Deucher +Date: Fri, 28 Jul 2023 11:14:05 -0400 +Subject: drm/amdgpu: fix possible UAF in amdgpu_cs_pass1() +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Alex Deucher + +commit 90e065677e0362a777b9db97ea21d43a39211399 upstream. + +Since the gang_size check is outside of chunk parsing +loop, we need to reset i before we free the chunk data. + +Suggested by Ye Zhang (@VAR10CK) of Baidu Security. + +Reviewed-by: Guchun Chen +Reviewed-by: Christian König +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c +@@ -291,7 +291,7 @@ static int amdgpu_cs_pass1(struct amdgpu + + if (!p->gang_size) { + ret = -EINVAL; +- goto free_partial_kdata; ++ goto free_all_kdata; + } + + for (i = 0; i < p->gang_size; ++i) { diff --git a/queue-6.4/drm-nouveau-gr-enable-memory-loads-on-helper-invocation-on-all-channels.patch b/queue-6.4/drm-nouveau-gr-enable-memory-loads-on-helper-invocation-on-all-channels.patch new file mode 100644 index 00000000000..afdf6edcc7f --- /dev/null +++ b/queue-6.4/drm-nouveau-gr-enable-memory-loads-on-helper-invocation-on-all-channels.patch @@ -0,0 +1,112 @@ +From 1cb9e2ef66d53b020842b18762e30d0eb4384de8 Mon Sep 17 00:00:00 2001 +From: Karol Herbst +Date: Thu, 22 Jun 2023 17:20:17 +0200 +Subject: drm/nouveau/gr: enable memory loads on helper invocation on all channels + +From: Karol Herbst + +commit 1cb9e2ef66d53b020842b18762e30d0eb4384de8 upstream. + +We have a lurking bug where Fragment Shader Helper Invocations can't load +from memory. But this is actually required in OpenGL and is causing random +hangs or failures in random shaders. + +It is unknown how widespread this issue is, but shaders hitting this can +end up with infinite loops. + +We enable those only on all Kepler and newer GPUs where we use our own +Firmware. + +Nvidia's firmware provides a way to set a kernelspace controlled list of +mmio registers in the gr space from push buffers via MME macros. + +v2: drop code for gm200 and newer. + +Cc: Ben Skeggs +Cc: David Airlie +Cc: nouveau@lists.freedesktop.org +Cc: stable@vger.kernel.org # 4.19+ +Signed-off-by: Karol Herbst +Reviewed-by: Dave Airlie +Link: https://patchwork.freedesktop.org/patch/msgid/20230622152017.2512101-1-kherbst@redhat.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.h | 1 + + drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk104.c | 4 +++- + drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110.c | 10 ++++++++++ + drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110b.c | 1 + + drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk208.c | 1 + + drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c | 1 + + 6 files changed, 17 insertions(+), 1 deletion(-) + +--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.h ++++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.h +@@ -117,6 +117,7 @@ void gk104_grctx_generate_r418800(struct + + extern const struct gf100_grctx_func gk110_grctx; + void gk110_grctx_generate_r419eb0(struct gf100_gr *); ++void gk110_grctx_generate_r419f78(struct gf100_gr *); + + extern const struct gf100_grctx_func gk110b_grctx; + extern const struct gf100_grctx_func gk208_grctx; +--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk104.c ++++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk104.c +@@ -906,7 +906,9 @@ static void + gk104_grctx_generate_r419f78(struct gf100_gr *gr) + { + struct nvkm_device *device = gr->base.engine.subdev.device; +- nvkm_mask(device, 0x419f78, 0x00000001, 0x00000000); ++ ++ /* bit 3 set disables loads in fp helper invocations, we need it enabled */ ++ nvkm_mask(device, 0x419f78, 0x00000009, 0x00000000); + } + + void +--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110.c ++++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110.c +@@ -820,6 +820,15 @@ gk110_grctx_generate_r419eb0(struct gf10 + nvkm_mask(device, 0x419eb0, 0x00001000, 0x00001000); + } + ++void ++gk110_grctx_generate_r419f78(struct gf100_gr *gr) ++{ ++ struct nvkm_device *device = gr->base.engine.subdev.device; ++ ++ /* bit 3 set disables loads in fp helper invocations, we need it enabled */ ++ nvkm_mask(device, 0x419f78, 0x00000008, 0x00000000); ++} ++ + const struct gf100_grctx_func + gk110_grctx = { + .main = gf100_grctx_generate_main, +@@ -854,4 +863,5 @@ gk110_grctx = { + .gpc_tpc_nr = gk104_grctx_generate_gpc_tpc_nr, + .r418800 = gk104_grctx_generate_r418800, + .r419eb0 = gk110_grctx_generate_r419eb0, ++ .r419f78 = gk110_grctx_generate_r419f78, + }; +--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110b.c ++++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110b.c +@@ -103,4 +103,5 @@ gk110b_grctx = { + .gpc_tpc_nr = gk104_grctx_generate_gpc_tpc_nr, + .r418800 = gk104_grctx_generate_r418800, + .r419eb0 = gk110_grctx_generate_r419eb0, ++ .r419f78 = gk110_grctx_generate_r419f78, + }; +--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk208.c ++++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk208.c +@@ -568,4 +568,5 @@ gk208_grctx = { + .dist_skip_table = gf117_grctx_generate_dist_skip_table, + .gpc_tpc_nr = gk104_grctx_generate_gpc_tpc_nr, + .r418800 = gk104_grctx_generate_r418800, ++ .r419f78 = gk110_grctx_generate_r419f78, + }; +--- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c ++++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.c +@@ -988,4 +988,5 @@ gm107_grctx = { + .r406500 = gm107_grctx_generate_r406500, + .gpc_tpc_nr = gk104_grctx_generate_gpc_tpc_nr, + .r419e00 = gm107_grctx_generate_r419e00, ++ .r419f78 = gk110_grctx_generate_r419f78, + }; diff --git a/queue-6.4/drm-nouveau-nvkm-dp-add-workaround-to-fix-dp-1.3-dpcd-issues.patch b/queue-6.4/drm-nouveau-nvkm-dp-add-workaround-to-fix-dp-1.3-dpcd-issues.patch new file mode 100644 index 00000000000..6cdd2c27744 --- /dev/null +++ b/queue-6.4/drm-nouveau-nvkm-dp-add-workaround-to-fix-dp-1.3-dpcd-issues.patch @@ -0,0 +1,108 @@ +From e4060dad253352382b20420d8ef98daab24dbc17 Mon Sep 17 00:00:00 2001 +From: Lyude Paul +Date: Fri, 28 Jul 2023 18:58:57 -0400 +Subject: drm/nouveau/nvkm/dp: Add workaround to fix DP 1.3+ DPCD issues + +From: Lyude Paul + +commit e4060dad253352382b20420d8ef98daab24dbc17 upstream. + +Currently we use the drm_dp_dpcd_read_caps() helper in the DRM side of +nouveau in order to read the DPCD of a DP connector, which makes sure we do +the right thing and also check for extended DPCD caps. However, it turns +out we're not currently doing this on the nvkm side since we don't have +access to the drm_dp_aux structure there - which means that the DRM side of +the driver and the NVKM side can end up with different DPCD capabilities +for the same connector. + +Ideally in order to fix this, we just want to use the +drm_dp_read_dpcd_caps() helper in nouveau. That's not currently possible +though, and is going to depend on having a bunch of the DP code moved out +of nvkm and into the DRM side of things as part of the GSP enablement work. + +Until then however, let's workaround this problem by porting a copy of +drm_dp_read_dpcd_caps() into NVKM - which should fix this issue. + +Signed-off-by: Lyude Paul +Reviewed-by: Karol Herbst +Link: https://gitlab.freedesktop.org/drm/nouveau/-/issues/211 +Link: https://patchwork.freedesktop.org/patch/msgid/20230728225858.350581-1-lyude@redhat.com +(cherry picked from commit cc4adf3a7323212f303bc9ff0f96346c44fcba06 in drm-misc-next) +Cc: # 6.3+ +Signed-off-by: Karol Herbst +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c | 48 +++++++++++++++++++++++++- + 1 file changed, 47 insertions(+), 1 deletion(-) + +--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c ++++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c +@@ -26,6 +26,8 @@ + #include "head.h" + #include "ior.h" + ++#include ++ + #include + #include + #include +@@ -634,6 +636,50 @@ nvkm_dp_enable_supported_link_rates(stru + return outp->dp.rates != 0; + } + ++/* XXX: This is a big fat hack, and this is just drm_dp_read_dpcd_caps() ++ * converted to work inside nvkm. This is a temporary holdover until we start ++ * passing the drm_dp_aux device through NVKM ++ */ ++static int ++nvkm_dp_read_dpcd_caps(struct nvkm_outp *outp) ++{ ++ struct nvkm_i2c_aux *aux = outp->dp.aux; ++ u8 dpcd_ext[DP_RECEIVER_CAP_SIZE]; ++ int ret; ++ ++ ret = nvkm_rdaux(aux, DPCD_RC00_DPCD_REV, outp->dp.dpcd, DP_RECEIVER_CAP_SIZE); ++ if (ret < 0) ++ return ret; ++ ++ /* ++ * Prior to DP1.3 the bit represented by ++ * DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT was reserved. ++ * If it is set DP_DPCD_REV at 0000h could be at a value less than ++ * the true capability of the panel. The only way to check is to ++ * then compare 0000h and 2200h. ++ */ ++ if (!(outp->dp.dpcd[DP_TRAINING_AUX_RD_INTERVAL] & ++ DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT)) ++ return 0; ++ ++ ret = nvkm_rdaux(aux, DP_DP13_DPCD_REV, dpcd_ext, sizeof(dpcd_ext)); ++ if (ret < 0) ++ return ret; ++ ++ if (outp->dp.dpcd[DP_DPCD_REV] > dpcd_ext[DP_DPCD_REV]) { ++ OUTP_DBG(outp, "Extended DPCD rev less than base DPCD rev (%d > %d)\n", ++ outp->dp.dpcd[DP_DPCD_REV], dpcd_ext[DP_DPCD_REV]); ++ return 0; ++ } ++ ++ if (!memcmp(outp->dp.dpcd, dpcd_ext, sizeof(dpcd_ext))) ++ return 0; ++ ++ memcpy(outp->dp.dpcd, dpcd_ext, sizeof(dpcd_ext)); ++ ++ return 0; ++} ++ + void + nvkm_dp_enable(struct nvkm_outp *outp, bool auxpwr) + { +@@ -689,7 +735,7 @@ nvkm_dp_enable(struct nvkm_outp *outp, b + memset(outp->dp.lttpr, 0x00, sizeof(outp->dp.lttpr)); + } + +- if (!nvkm_rdaux(aux, DPCD_RC00_DPCD_REV, outp->dp.dpcd, sizeof(outp->dp.dpcd))) { ++ if (!nvkm_dp_read_dpcd_caps(outp)) { + const u8 rates[] = { 0x1e, 0x14, 0x0a, 0x06, 0 }; + const u8 *rate; + int rate_max; diff --git a/queue-6.4/drm-shmem-helper-reset-vma-vm_ops-before-calling-dma_buf_mmap.patch b/queue-6.4/drm-shmem-helper-reset-vma-vm_ops-before-calling-dma_buf_mmap.patch new file mode 100644 index 00000000000..c14dc6d7aea --- /dev/null +++ b/queue-6.4/drm-shmem-helper-reset-vma-vm_ops-before-calling-dma_buf_mmap.patch @@ -0,0 +1,45 @@ +From 07dd476f6116966cb2006e25fdcf48f0715115ff Mon Sep 17 00:00:00 2001 +From: Boris Brezillon +Date: Mon, 24 Jul 2023 13:26:10 +0200 +Subject: drm/shmem-helper: Reset vma->vm_ops before calling dma_buf_mmap() + +From: Boris Brezillon + +commit 07dd476f6116966cb2006e25fdcf48f0715115ff upstream. + +The dma-buf backend is supposed to provide its own vm_ops, but some +implementation just have nothing special to do and leave vm_ops +untouched, probably expecting this field to be zero initialized (this +is the case with the system_heap implementation for instance). +Let's reset vma->vm_ops to NULL to keep things working with these +implementations. + +Fixes: 26d3ac3cb04d ("drm/shmem-helpers: Redirect mmap for imported dma-buf") +Cc: +Cc: Daniel Vetter +Reported-by: Roman Stratiienko +Signed-off-by: Boris Brezillon +Tested-by: Roman Stratiienko +Reviewed-by: Thomas Zimmermann +Link: https://patchwork.freedesktop.org/patch/msgid/20230724112610.60974-1-boris.brezillon@collabora.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/drm_gem_shmem_helper.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +--- a/drivers/gpu/drm/drm_gem_shmem_helper.c ++++ b/drivers/gpu/drm/drm_gem_shmem_helper.c +@@ -623,7 +623,13 @@ int drm_gem_shmem_mmap(struct drm_gem_sh + int ret; + + if (obj->import_attach) { ++ /* Reset both vm_ops and vm_private_data, so we don't end up with ++ * vm_ops pointing to our implementation if the dma-buf backend ++ * doesn't set those fields. ++ */ + vma->vm_private_data = NULL; ++ vma->vm_ops = NULL; ++ + ret = dma_buf_mmap(obj->dma_buf, vma, 0); + + /* Drop the reference drm_gem_mmap_obj() acquired.*/ diff --git a/queue-6.4/fs-proc-kcore-reinstate-bounce-buffer-for-kcore_text-regions.patch b/queue-6.4/fs-proc-kcore-reinstate-bounce-buffer-for-kcore_text-regions.patch new file mode 100644 index 00000000000..1fe7904f03a --- /dev/null +++ b/queue-6.4/fs-proc-kcore-reinstate-bounce-buffer-for-kcore_text-regions.patch @@ -0,0 +1,119 @@ +From 17457784004c84178798432a029ab20e14f728b1 Mon Sep 17 00:00:00 2001 +From: Lorenzo Stoakes +Date: Mon, 31 Jul 2023 22:50:21 +0100 +Subject: fs/proc/kcore: reinstate bounce buffer for KCORE_TEXT regions + +From: Lorenzo Stoakes + +commit 17457784004c84178798432a029ab20e14f728b1 upstream. + +Some architectures do not populate the entire range categorised by +KCORE_TEXT, so we must ensure that the kernel address we read from is +valid. + +Unfortunately there is no solution currently available to do so with a +purely iterator solution so reinstate the bounce buffer in this instance +so we can use copy_from_kernel_nofault() in order to avoid page faults +when regions are unmapped. + +This change partly reverts commit 2e1c0170771e ("fs/proc/kcore: avoid +bounce buffer for ktext data"), reinstating the bounce buffer, but adapts +the code to continue to use an iterator. + +[lstoakes@gmail.com: correct comment to be strictly correct about reasoning] + Link: https://lkml.kernel.org/r/525a3f14-74fa-4c22-9fca-9dab4de8a0c3@lucifer.local +Link: https://lkml.kernel.org/r/20230731215021.70911-1-lstoakes@gmail.com +Fixes: 2e1c0170771e ("fs/proc/kcore: avoid bounce buffer for ktext data") +Signed-off-by: Lorenzo Stoakes +Reported-by: Jiri Olsa +Closes: https://lore.kernel.org/all/ZHc2fm+9daF6cgCE@krava +Tested-by: Jiri Olsa +Tested-by: Will Deacon +Cc: Alexander Viro +Cc: Ard Biesheuvel +Cc: Baoquan He +Cc: Catalin Marinas +Cc: David Hildenbrand +Cc: Jens Axboe +Cc: Kefeng Wang +Cc: Liu Shixin +Cc: Matthew Wilcox +Cc: Mike Galbraith +Cc: Thorsten Leemhuis +Cc: Uladzislau Rezki (Sony) +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + fs/proc/kcore.c | 30 +++++++++++++++++++++++++++--- + 1 file changed, 27 insertions(+), 3 deletions(-) + +diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c +index 9cb32e1a78a0..23fc24d16b31 100644 +--- a/fs/proc/kcore.c ++++ b/fs/proc/kcore.c +@@ -309,6 +309,8 @@ static void append_kcore_note(char *notes, size_t *i, const char *name, + + static ssize_t read_kcore_iter(struct kiocb *iocb, struct iov_iter *iter) + { ++ struct file *file = iocb->ki_filp; ++ char *buf = file->private_data; + loff_t *fpos = &iocb->ki_pos; + size_t phdrs_offset, notes_offset, data_offset; + size_t page_offline_frozen = 1; +@@ -555,10 +557,21 @@ static ssize_t read_kcore_iter(struct kiocb *iocb, struct iov_iter *iter) + case KCORE_VMEMMAP: + case KCORE_TEXT: + /* +- * We use _copy_to_iter() to bypass usermode hardening +- * which would otherwise prevent this operation. ++ * Sadly we must use a bounce buffer here to be able to ++ * make use of copy_from_kernel_nofault(), as these ++ * memory regions might not always be mapped on all ++ * architectures. + */ +- if (_copy_to_iter((char *)start, tsz, iter) != tsz) { ++ if (copy_from_kernel_nofault(buf, (void *)start, tsz)) { ++ if (iov_iter_zero(tsz, iter) != tsz) { ++ ret = -EFAULT; ++ goto out; ++ } ++ /* ++ * We know the bounce buffer is safe to copy from, so ++ * use _copy_to_iter() directly. ++ */ ++ } else if (_copy_to_iter(buf, tsz, iter) != tsz) { + ret = -EFAULT; + goto out; + } +@@ -595,6 +608,10 @@ static int open_kcore(struct inode *inode, struct file *filp) + if (ret) + return ret; + ++ filp->private_data = kmalloc(PAGE_SIZE, GFP_KERNEL); ++ if (!filp->private_data) ++ return -ENOMEM; ++ + if (kcore_need_update) + kcore_update_ram(); + if (i_size_read(inode) != proc_root_kcore->size) { +@@ -605,9 +622,16 @@ static int open_kcore(struct inode *inode, struct file *filp) + return 0; + } + ++static int release_kcore(struct inode *inode, struct file *file) ++{ ++ kfree(file->private_data); ++ return 0; ++} ++ + static const struct proc_ops kcore_proc_ops = { + .proc_read_iter = read_kcore_iter, + .proc_open = open_kcore, ++ .proc_release = release_kcore, + .proc_lseek = default_llseek, + }; + +-- +2.41.0 + diff --git a/queue-6.4/hugetlb-do-not-clear-hugetlb-dtor-until-allocating-vmemmap.patch b/queue-6.4/hugetlb-do-not-clear-hugetlb-dtor-until-allocating-vmemmap.patch new file mode 100644 index 00000000000..a20dc83e7d2 --- /dev/null +++ b/queue-6.4/hugetlb-do-not-clear-hugetlb-dtor-until-allocating-vmemmap.patch @@ -0,0 +1,203 @@ +From 32c877191e022b55fe3a374f3d7e9fb5741c514d Mon Sep 17 00:00:00 2001 +From: Mike Kravetz +Date: Tue, 11 Jul 2023 15:09:41 -0700 +Subject: hugetlb: do not clear hugetlb dtor until allocating vmemmap + +From: Mike Kravetz + +commit 32c877191e022b55fe3a374f3d7e9fb5741c514d upstream. + +Patch series "Fix hugetlb free path race with memory errors". + +In the discussion of Jiaqi Yan's series "Improve hugetlbfs read on +HWPOISON hugepages" the race window was discovered. +https://lore.kernel.org/linux-mm/20230616233447.GB7371@monkey/ + +Freeing a hugetlb page back to low level memory allocators is performed +in two steps. +1) Under hugetlb lock, remove page from hugetlb lists and clear destructor +2) Outside lock, allocate vmemmap if necessary and call low level free +Between these two steps, the hugetlb page will appear as a normal +compound page. However, vmemmap for tail pages could be missing. +If a memory error occurs at this time, we could try to update page +flags non-existant page structs. + +A much more detailed description is in the first patch. + +The first patch addresses the race window. However, it adds a +hugetlb_lock lock/unlock cycle to every vmemmap optimized hugetlb page +free operation. This could lead to slowdowns if one is freeing a large +number of hugetlb pages. + +The second path optimizes the update_and_free_pages_bulk routine to only +take the lock once in bulk operations. + +The second patch is technically not a bug fix, but includes a Fixes tag +and Cc stable to avoid a performance regression. It can be combined with +the first, but was done separately make reviewing easier. + + +This patch (of 2): + +Freeing a hugetlb page and releasing base pages back to the underlying +allocator such as buddy or cma is performed in two steps: +- remove_hugetlb_folio() is called to remove the folio from hugetlb + lists, get a ref on the page and remove hugetlb destructor. This + all must be done under the hugetlb lock. After this call, the page + can be treated as a normal compound page or a collection of base + size pages. +- update_and_free_hugetlb_folio() is called to allocate vmemmap if + needed and the free routine of the underlying allocator is called + on the resulting page. We can not hold the hugetlb lock here. + +One issue with this scheme is that a memory error could occur between +these two steps. In this case, the memory error handling code treats +the old hugetlb page as a normal compound page or collection of base +pages. It will then try to SetPageHWPoison(page) on the page with an +error. If the page with error is a tail page without vmemmap, a write +error will occur when trying to set the flag. + +Address this issue by modifying remove_hugetlb_folio() and +update_and_free_hugetlb_folio() such that the hugetlb destructor is not +cleared until after allocating vmemmap. Since clearing the destructor +requires holding the hugetlb lock, the clearing is done in +remove_hugetlb_folio() if the vmemmap is present. This saves a +lock/unlock cycle. Otherwise, destructor is cleared in +update_and_free_hugetlb_folio() after allocating vmemmap. + +Note that this will leave hugetlb pages in a state where they are marked +free (by hugetlb specific page flag) and have a ref count. This is not +a normal state. The only code that would notice is the memory error +code, and it is set up to retry in such a case. + +A subsequent patch will create a routine to do bulk processing of +vmemmap allocation. This will eliminate a lock/unlock cycle for each +hugetlb page in the case where we are freeing a large number of pages. + +Link: https://lkml.kernel.org/r/20230711220942.43706-1-mike.kravetz@oracle.com +Link: https://lkml.kernel.org/r/20230711220942.43706-2-mike.kravetz@oracle.com +Fixes: ad2fa3717b74 ("mm: hugetlb: alloc the vmemmap pages associated with each HugeTLB page") +Signed-off-by: Mike Kravetz +Reviewed-by: Muchun Song +Tested-by: Naoya Horiguchi +Cc: Axel Rasmussen +Cc: James Houghton +Cc: Jiaqi Yan +Cc: Miaohe Lin +Cc: Michal Hocko +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + mm/hugetlb.c | 75 ++++++++++++++++++++++++++++++++++++++++------------------- + 1 file changed, 51 insertions(+), 24 deletions(-) + +--- a/mm/hugetlb.c ++++ b/mm/hugetlb.c +@@ -1580,9 +1580,37 @@ static inline void destroy_compound_giga + unsigned int order) { } + #endif + ++static inline void __clear_hugetlb_destructor(struct hstate *h, ++ struct folio *folio) ++{ ++ lockdep_assert_held(&hugetlb_lock); ++ ++ /* ++ * Very subtle ++ * ++ * For non-gigantic pages set the destructor to the normal compound ++ * page dtor. This is needed in case someone takes an additional ++ * temporary ref to the page, and freeing is delayed until they drop ++ * their reference. ++ * ++ * For gigantic pages set the destructor to the null dtor. This ++ * destructor will never be called. Before freeing the gigantic ++ * page destroy_compound_gigantic_folio will turn the folio into a ++ * simple group of pages. After this the destructor does not ++ * apply. ++ * ++ */ ++ if (hstate_is_gigantic(h)) ++ folio_set_compound_dtor(folio, NULL_COMPOUND_DTOR); ++ else ++ folio_set_compound_dtor(folio, COMPOUND_PAGE_DTOR); ++} ++ + /* +- * Remove hugetlb folio from lists, and update dtor so that the folio appears +- * as just a compound page. ++ * Remove hugetlb folio from lists. ++ * If vmemmap exists for the folio, update dtor so that the folio appears ++ * as just a compound page. Otherwise, wait until after allocating vmemmap ++ * to update dtor. + * + * A reference is held on the folio, except in the case of demote. + * +@@ -1613,31 +1641,19 @@ static void __remove_hugetlb_folio(struc + } + + /* +- * Very subtle +- * +- * For non-gigantic pages set the destructor to the normal compound +- * page dtor. This is needed in case someone takes an additional +- * temporary ref to the page, and freeing is delayed until they drop +- * their reference. +- * +- * For gigantic pages set the destructor to the null dtor. This +- * destructor will never be called. Before freeing the gigantic +- * page destroy_compound_gigantic_folio will turn the folio into a +- * simple group of pages. After this the destructor does not +- * apply. +- * +- * This handles the case where more than one ref is held when and +- * after update_and_free_hugetlb_folio is called. +- * +- * In the case of demote we do not ref count the page as it will soon +- * be turned into a page of smaller size. ++ * We can only clear the hugetlb destructor after allocating vmemmap ++ * pages. Otherwise, someone (memory error handling) may try to write ++ * to tail struct pages. ++ */ ++ if (!folio_test_hugetlb_vmemmap_optimized(folio)) ++ __clear_hugetlb_destructor(h, folio); ++ ++ /* ++ * In the case of demote we do not ref count the page as it will soon ++ * be turned into a page of smaller size. + */ + if (!demote) + folio_ref_unfreeze(folio, 1); +- if (hstate_is_gigantic(h)) +- folio_set_compound_dtor(folio, NULL_COMPOUND_DTOR); +- else +- folio_set_compound_dtor(folio, COMPOUND_PAGE_DTOR); + + h->nr_huge_pages--; + h->nr_huge_pages_node[nid]--; +@@ -1706,6 +1722,7 @@ static void __update_and_free_hugetlb_fo + { + int i; + struct page *subpage; ++ bool clear_dtor = folio_test_hugetlb_vmemmap_optimized(folio); + + if (hstate_is_gigantic(h) && !gigantic_page_runtime_supported()) + return; +@@ -1736,6 +1753,16 @@ static void __update_and_free_hugetlb_fo + if (unlikely(folio_test_hwpoison(folio))) + folio_clear_hugetlb_hwpoison(folio); + ++ /* ++ * If vmemmap pages were allocated above, then we need to clear the ++ * hugetlb destructor under the hugetlb lock. ++ */ ++ if (clear_dtor) { ++ spin_lock_irq(&hugetlb_lock); ++ __clear_hugetlb_destructor(h, folio); ++ spin_unlock_irq(&hugetlb_lock); ++ } ++ + for (i = 0; i < pages_per_huge_page(h); i++) { + subpage = folio_page(folio, i); + subpage->flags &= ~(1 << PG_locked | 1 << PG_error | diff --git a/queue-6.4/hwmon-pmbus-bel-pfe-enable-pmbus_skip_status_check-for-pfe1100.patch b/queue-6.4/hwmon-pmbus-bel-pfe-enable-pmbus_skip_status_check-for-pfe1100.patch new file mode 100644 index 00000000000..2d86b9ea8eb --- /dev/null +++ b/queue-6.4/hwmon-pmbus-bel-pfe-enable-pmbus_skip_status_check-for-pfe1100.patch @@ -0,0 +1,62 @@ +From f38963b9cd0645a336cf30c5da2e89e34e34fec3 Mon Sep 17 00:00:00 2001 +From: Tao Ren +Date: Fri, 4 Aug 2023 15:14:03 -0700 +Subject: hwmon: (pmbus/bel-pfe) Enable PMBUS_SKIP_STATUS_CHECK for pfe1100 + +From: Tao Ren + +commit f38963b9cd0645a336cf30c5da2e89e34e34fec3 upstream. + +Skip status check for both pfe1100 and pfe3000 because the communication +error is also observed on pfe1100 devices. + +Signed-off-by: Tao Ren +Fixes: 626bb2f3fb3c hwmon: (pmbus) add driver for BEL PFE1100 and PFE3000 +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20230804221403.28931-1-rentao.bupt@gmail.com +Signed-off-by: Guenter Roeck +Signed-off-by: Greg Kroah-Hartman +--- + drivers/hwmon/pmbus/bel-pfe.c | 16 ++++++++-------- + 1 file changed, 8 insertions(+), 8 deletions(-) + +--- a/drivers/hwmon/pmbus/bel-pfe.c ++++ b/drivers/hwmon/pmbus/bel-pfe.c +@@ -17,12 +17,13 @@ + enum chips {pfe1100, pfe3000}; + + /* +- * Disable status check for pfe3000 devices, because some devices report +- * communication error (invalid command) for VOUT_MODE command (0x20) +- * although correct VOUT_MODE (0x16) is returned: it leads to incorrect +- * exponent in linear mode. ++ * Disable status check because some devices report communication error ++ * (invalid command) for VOUT_MODE command (0x20) although the correct ++ * VOUT_MODE (0x16) is returned: it leads to incorrect exponent in linear ++ * mode. ++ * This affects both pfe3000 and pfe1100. + */ +-static struct pmbus_platform_data pfe3000_plat_data = { ++static struct pmbus_platform_data pfe_plat_data = { + .flags = PMBUS_SKIP_STATUS_CHECK, + }; + +@@ -94,16 +95,15 @@ static int pfe_pmbus_probe(struct i2c_cl + int model; + + model = (int)i2c_match_id(pfe_device_id, client)->driver_data; ++ client->dev.platform_data = &pfe_plat_data; + + /* + * PFE3000-12-069RA devices may not stay in page 0 during device + * probe which leads to probe failure (read status word failed). + * So let's set the device to page 0 at the beginning. + */ +- if (model == pfe3000) { +- client->dev.platform_data = &pfe3000_plat_data; ++ if (model == pfe3000) + i2c_smbus_write_byte_data(client, PMBUS_PAGE, 0); +- } + + return pmbus_do_probe(client, &pfe_driver_info[model]); + } diff --git a/queue-6.4/io_uring-correct-check-for-o_tmpfile.patch b/queue-6.4/io_uring-correct-check-for-o_tmpfile.patch new file mode 100644 index 00000000000..f0fb2705394 --- /dev/null +++ b/queue-6.4/io_uring-correct-check-for-o_tmpfile.patch @@ -0,0 +1,39 @@ +From 72dbde0f2afbe4af8e8595a89c650ae6b9d9c36f Mon Sep 17 00:00:00 2001 +From: Aleksa Sarai +Date: Mon, 7 Aug 2023 12:24:15 +1000 +Subject: io_uring: correct check for O_TMPFILE + +From: Aleksa Sarai + +commit 72dbde0f2afbe4af8e8595a89c650ae6b9d9c36f upstream. + +O_TMPFILE is actually __O_TMPFILE|O_DIRECTORY. This means that the old +check for whether RESOLVE_CACHED can be used would incorrectly think +that O_DIRECTORY could not be used with RESOLVE_CACHED. + +Cc: stable@vger.kernel.org # v5.12+ +Fixes: 3a81fd02045c ("io_uring: enable LOOKUP_CACHED path resolution for filename lookups") +Signed-off-by: Aleksa Sarai +Link: https://lore.kernel.org/r/20230807-resolve_cached-o_tmpfile-v3-1-e49323e1ef6f@cyphar.com +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + io_uring/openclose.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/io_uring/openclose.c ++++ b/io_uring/openclose.c +@@ -35,9 +35,11 @@ static bool io_openat_force_async(struct + { + /* + * Don't bother trying for O_TRUNC, O_CREAT, or O_TMPFILE open, +- * it'll always -EAGAIN ++ * it'll always -EAGAIN. Note that we test for __O_TMPFILE because ++ * O_TMPFILE includes O_DIRECTORY, which isn't a flag we need to force ++ * async for. + */ +- return open->how.flags & (O_TRUNC | O_CREAT | O_TMPFILE); ++ return open->how.flags & (O_TRUNC | O_CREAT | __O_TMPFILE); + } + + static int __io_openat_prep(struct io_kiocb *req, const struct io_uring_sqe *sqe) diff --git a/queue-6.4/io_uring-parisc-adjust-pgoff-in-io_uring-mmap-for-parisc.patch b/queue-6.4/io_uring-parisc-adjust-pgoff-in-io_uring-mmap-for-parisc.patch new file mode 100644 index 00000000000..c23a102df90 --- /dev/null +++ b/queue-6.4/io_uring-parisc-adjust-pgoff-in-io_uring-mmap-for-parisc.patch @@ -0,0 +1,88 @@ +From 56675f8b9f9b15b024b8e3145fa289b004916ab7 Mon Sep 17 00:00:00 2001 +From: Helge Deller +Date: Mon, 7 Aug 2023 20:04:09 +0200 +Subject: io_uring/parisc: Adjust pgoff in io_uring mmap() for parisc + +From: Helge Deller + +commit 56675f8b9f9b15b024b8e3145fa289b004916ab7 upstream. + +The changes from commit 32832a407a71 ("io_uring: Fix io_uring mmap() by +using architecture-provided get_unmapped_area()") to the parisc +implementation of get_unmapped_area() broke glibc's locale-gen +executable when running on parisc. + +This patch reverts those architecture-specific changes, and instead +adjusts in io_uring_mmu_get_unmapped_area() the pgoff offset which is +then given to parisc's get_unmapped_area() function. This is much +cleaner than the previous approach, and we still will get a coherent +addresss. + +This patch has no effect on other architectures (SHM_COLOUR is only +defined on parisc), and the liburing testcase stil passes on parisc. + +Cc: stable@vger.kernel.org # 6.4 +Signed-off-by: Helge Deller +Reported-by: Christoph Biedl +Fixes: 32832a407a71 ("io_uring: Fix io_uring mmap() by using architecture-provided get_unmapped_area()") +Fixes: d808459b2e31 ("io_uring: Adjust mapping wrt architecture aliasing requirements") +Link: https://lore.kernel.org/r/ZNEyGV0jyI8kOOfz@p100 +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + arch/parisc/kernel/sys_parisc.c | 15 +++++---------- + io_uring/io_uring.c | 3 +++ + 2 files changed, 8 insertions(+), 10 deletions(-) + +--- a/arch/parisc/kernel/sys_parisc.c ++++ b/arch/parisc/kernel/sys_parisc.c +@@ -26,17 +26,12 @@ + #include + + /* +- * Construct an artificial page offset for the mapping based on the virtual ++ * Construct an artificial page offset for the mapping based on the physical + * address of the kernel file mapping variable. +- * If filp is zero the calculated pgoff value aliases the memory of the given +- * address. This is useful for io_uring where the mapping shall alias a kernel +- * address and a userspace adress where both the kernel and the userspace +- * access the same memory region. + */ +-#define GET_FILP_PGOFF(filp, addr) \ +- ((filp ? (((unsigned long) filp->f_mapping) >> 8) \ +- & ((SHM_COLOUR-1) >> PAGE_SHIFT) : 0UL) \ +- + (addr >> PAGE_SHIFT)) ++#define GET_FILP_PGOFF(filp) \ ++ (filp ? (((unsigned long) filp->f_mapping) >> 8) \ ++ & ((SHM_COLOUR-1) >> PAGE_SHIFT) : 0UL) + + static unsigned long shared_align_offset(unsigned long filp_pgoff, + unsigned long pgoff) +@@ -116,7 +111,7 @@ static unsigned long arch_get_unmapped_a + do_color_align = 0; + if (filp || (flags & MAP_SHARED)) + do_color_align = 1; +- filp_pgoff = GET_FILP_PGOFF(filp, addr); ++ filp_pgoff = GET_FILP_PGOFF(filp); + + if (flags & MAP_FIXED) { + /* Even MAP_FIXED mappings must reside within TASK_SIZE */ +--- a/io_uring/io_uring.c ++++ b/io_uring/io_uring.c +@@ -3466,6 +3466,8 @@ static unsigned long io_uring_mmu_get_un + * - use the kernel virtual address of the shared io_uring context + * (instead of the userspace-provided address, which has to be 0UL + * anyway). ++ * - use the same pgoff which the get_unmapped_area() uses to ++ * calculate the page colouring. + * For architectures without such aliasing requirements, the + * architecture will return any suitable mapping because addr is 0. + */ +@@ -3474,6 +3476,7 @@ static unsigned long io_uring_mmu_get_un + pgoff = 0; /* has been translated to ptr above */ + #ifdef SHM_COLOUR + addr = (uintptr_t) ptr; ++ pgoff = addr >> PAGE_SHIFT; + #else + addr = 0UL; + #endif diff --git a/queue-6.4/mm-damon-core-initialize-damo_filter-list-from-damos_new_filter.patch b/queue-6.4/mm-damon-core-initialize-damo_filter-list-from-damos_new_filter.patch new file mode 100644 index 00000000000..1c5e56ca00f --- /dev/null +++ b/queue-6.4/mm-damon-core-initialize-damo_filter-list-from-damos_new_filter.patch @@ -0,0 +1,41 @@ +From 5f1fc67f2cb8d3035d3acd273b48b97835af8afd Mon Sep 17 00:00:00 2001 +From: SeongJae Park +Date: Sat, 29 Jul 2023 20:37:32 +0000 +Subject: mm/damon/core: initialize damo_filter->list from damos_new_filter() + +From: SeongJae Park + +commit 5f1fc67f2cb8d3035d3acd273b48b97835af8afd upstream. + +damos_new_filter() is not initializing the list field of newly allocated +filter object. However, DAMON sysfs interface and DAMON_RECLAIM are not +initializing it after calling damos_new_filter(). As a result, accessing +uninitialized memory is possible. Actually, adding multiple DAMOS filters +via DAMON sysfs interface caused NULL pointer dereferencing. Initialize +the field just after the allocation from damos_new_filter(). + +Link: https://lkml.kernel.org/r/20230729203733.38949-2-sj@kernel.org +Fixes: 98def236f63c ("mm/damon/core: implement damos filter") +Signed-off-by: SeongJae Park +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + mm/damon/core.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/mm/damon/core.c b/mm/damon/core.c +index 91cff7f2997e..eb9580942a5c 100644 +--- a/mm/damon/core.c ++++ b/mm/damon/core.c +@@ -273,6 +273,7 @@ struct damos_filter *damos_new_filter(enum damos_filter_type type, + return NULL; + filter->type = type; + filter->matching = matching; ++ INIT_LIST_HEAD(&filter->list); + return filter; + } + +-- +2.41.0 + diff --git a/queue-6.4/mm-memory-failure-avoid-false-hwpoison-page-mapped-error-info.patch b/queue-6.4/mm-memory-failure-avoid-false-hwpoison-page-mapped-error-info.patch new file mode 100644 index 00000000000..fc9309968ae --- /dev/null +++ b/queue-6.4/mm-memory-failure-avoid-false-hwpoison-page-mapped-error-info.patch @@ -0,0 +1,53 @@ +From faeb2ff2c1c5cb60ce0da193580b256c941f99ca Mon Sep 17 00:00:00 2001 +From: Miaohe Lin +Date: Thu, 27 Jul 2023 19:56:42 +0800 +Subject: mm: memory-failure: avoid false hwpoison page mapped error info + +From: Miaohe Lin + +commit faeb2ff2c1c5cb60ce0da193580b256c941f99ca upstream. + +folio->_mapcount is overloaded in SLAB, so folio_mapped() has to be done +after folio_test_slab() is checked. Otherwise slab folio might be treated +as a mapped folio leading to false 'Someone maps the hwpoison page' error +info. + +Link: https://lkml.kernel.org/r/20230727115643.639741-4-linmiaohe@huawei.com +Fixes: 230ac719c500 ("mm/hwpoison: don't try to unpoison containment-failed pages") +Signed-off-by: Miaohe Lin +Reviewed-by: Matthew Wilcox (Oracle) +Acked-by: Naoya Horiguchi +Cc: Kefeng Wang +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + mm/memory-failure.c | 10 +++++++--- + 1 file changed, 7 insertions(+), 3 deletions(-) + +--- a/mm/memory-failure.c ++++ b/mm/memory-failure.c +@@ -2502,6 +2502,13 @@ int unpoison_memory(unsigned long pfn) + goto unlock_mutex; + } + ++ if (folio_test_slab(folio) || PageTable(&folio->page) || folio_test_reserved(folio)) ++ goto unlock_mutex; ++ ++ /* ++ * Note that folio->_mapcount is overloaded in SLAB, so the simple test ++ * in folio_mapped() has to be done after folio_test_slab() is checked. ++ */ + if (folio_mapped(folio)) { + unpoison_pr_info("Unpoison: Someone maps the hwpoison page %#lx\n", + pfn, &unpoison_rs); +@@ -2514,9 +2521,6 @@ int unpoison_memory(unsigned long pfn) + goto unlock_mutex; + } + +- if (folio_test_slab(folio) || PageTable(&folio->page) || folio_test_reserved(folio)) +- goto unlock_mutex; +- + ghp = get_hwpoison_page(p, MF_UNPOISON); + if (!ghp) { + if (PageHuge(p)) { diff --git a/queue-6.4/mm-memory-failure-fix-potential-unexpected-return-value-from-unpoison_memory.patch b/queue-6.4/mm-memory-failure-fix-potential-unexpected-return-value-from-unpoison_memory.patch new file mode 100644 index 00000000000..6649b0ad444 --- /dev/null +++ b/queue-6.4/mm-memory-failure-fix-potential-unexpected-return-value-from-unpoison_memory.patch @@ -0,0 +1,80 @@ +From f29623e4a599c295cc8f518c8e4bb7848581a14d Mon Sep 17 00:00:00 2001 +From: Miaohe Lin +Date: Thu, 27 Jul 2023 19:56:41 +0800 +Subject: mm: memory-failure: fix potential unexpected return value from unpoison_memory() + +From: Miaohe Lin + +commit f29623e4a599c295cc8f518c8e4bb7848581a14d upstream. + +If unpoison_memory() fails to clear page hwpoisoned flag, return value ret +is expected to be -EBUSY. But when get_hwpoison_page() returns 1 and +fails to clear page hwpoisoned flag due to races, return value will be +unexpected 1 leading to users being confused. And there's a code smell +that the variable "ret" is used not only to save the return value of +unpoison_memory(), but also the return value from get_hwpoison_page(). +Make a further cleanup by using another auto-variable solely to save the +return value of get_hwpoison_page() as suggested by Naoya. + +Link: https://lkml.kernel.org/r/20230727115643.639741-3-linmiaohe@huawei.com +Fixes: bf181c582588 ("mm/hwpoison: fix unpoison_memory()") +Signed-off-by: Miaohe Lin +Cc: Kefeng Wang +Cc: Matthew Wilcox (Oracle) +Cc: Naoya Horiguchi +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + mm/memory-failure.c | 19 +++++++++---------- + 1 file changed, 9 insertions(+), 10 deletions(-) + +--- a/mm/memory-failure.c ++++ b/mm/memory-failure.c +@@ -2469,7 +2469,7 @@ int unpoison_memory(unsigned long pfn) + { + struct folio *folio; + struct page *p; +- int ret = -EBUSY; ++ int ret = -EBUSY, ghp; + unsigned long count = 1; + bool huge = false; + static DEFINE_RATELIMIT_STATE(unpoison_rs, DEFAULT_RATELIMIT_INTERVAL, +@@ -2517,29 +2517,28 @@ int unpoison_memory(unsigned long pfn) + if (folio_test_slab(folio) || PageTable(&folio->page) || folio_test_reserved(folio)) + goto unlock_mutex; + +- ret = get_hwpoison_page(p, MF_UNPOISON); +- if (!ret) { ++ ghp = get_hwpoison_page(p, MF_UNPOISON); ++ if (!ghp) { + if (PageHuge(p)) { + huge = true; + count = folio_free_raw_hwp(folio, false); +- if (count == 0) { +- ret = -EBUSY; ++ if (count == 0) + goto unlock_mutex; +- } + } + ret = folio_test_clear_hwpoison(folio) ? 0 : -EBUSY; +- } else if (ret < 0) { +- if (ret == -EHWPOISON) { ++ } else if (ghp < 0) { ++ if (ghp == -EHWPOISON) { + ret = put_page_back_buddy(p) ? 0 : -EBUSY; +- } else ++ } else { ++ ret = ghp; + unpoison_pr_info("Unpoison: failed to grab page %#lx\n", + pfn, &unpoison_rs); ++ } + } else { + if (PageHuge(p)) { + huge = true; + count = folio_free_raw_hwp(folio, false); + if (count == 0) { +- ret = -EBUSY; + folio_put(folio); + goto unlock_mutex; + } diff --git a/queue-6.4/mptcp-avoid-bogus-reset-on-fallback-close.patch b/queue-6.4/mptcp-avoid-bogus-reset-on-fallback-close.patch new file mode 100644 index 00000000000..da67d95a015 --- /dev/null +++ b/queue-6.4/mptcp-avoid-bogus-reset-on-fallback-close.patch @@ -0,0 +1,41 @@ +From ff18f9ef30ee87740f741b964375d0cfb84e1ec2 Mon Sep 17 00:00:00 2001 +From: Paolo Abeni +Date: Thu, 3 Aug 2023 18:27:29 +0200 +Subject: mptcp: avoid bogus reset on fallback close + +From: Paolo Abeni + +commit ff18f9ef30ee87740f741b964375d0cfb84e1ec2 upstream. + +Since the blamed commit, the MPTCP protocol unconditionally sends +TCP resets on all the subflows on disconnect(). + +That fits full-blown MPTCP sockets - to implement the fastclose +mechanism - but causes unexpected corruption of the data stream, +caught as sporadic self-tests failures. + +Fixes: d21f83485518 ("mptcp: use fastclose on more edge scenarios") +Cc: stable@vger.kernel.org +Tested-by: Matthieu Baerts +Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/419 +Signed-off-by: Paolo Abeni +Reviewed-by: Matthieu Baerts +Signed-off-by: Matthieu Baerts +Link: https://lore.kernel.org/r/20230803-upstream-net-20230803-misc-fixes-6-5-v1-3-6671b1ab11cc@tessares.net +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/mptcp/protocol.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/net/mptcp/protocol.c ++++ b/net/mptcp/protocol.c +@@ -2335,7 +2335,7 @@ static void __mptcp_close_ssk(struct soc + + lock_sock_nested(ssk, SINGLE_DEPTH_NESTING); + +- if (flags & MPTCP_CF_FASTCLOSE) { ++ if ((flags & MPTCP_CF_FASTCLOSE) && !__mptcp_check_fallback(msk)) { + /* be sure to force the tcp_disconnect() path, + * to generate the egress reset + */ diff --git a/queue-6.4/mptcp-fix-disconnect-vs-accept-race.patch b/queue-6.4/mptcp-fix-disconnect-vs-accept-race.patch new file mode 100644 index 00000000000..ee966270834 --- /dev/null +++ b/queue-6.4/mptcp-fix-disconnect-vs-accept-race.patch @@ -0,0 +1,172 @@ +From 511b90e39250135a7f900f1c3afbce25543018a2 Mon Sep 17 00:00:00 2001 +From: Paolo Abeni +Date: Thu, 3 Aug 2023 18:27:30 +0200 +Subject: mptcp: fix disconnect vs accept race + +From: Paolo Abeni + +commit 511b90e39250135a7f900f1c3afbce25543018a2 upstream. + +Despite commit 0ad529d9fd2b ("mptcp: fix possible divide by zero in +recvmsg()"), the mptcp protocol is still prone to a race between +disconnect() (or shutdown) and accept. + +The root cause is that the mentioned commit checks the msk-level +flag, but mptcp_stream_accept() does acquire the msk-level lock, +as it can rely directly on the first subflow lock. + +As reported by Christoph than can lead to a race where an msk +socket is accepted after that mptcp_subflow_queue_clean() releases +the listener socket lock and just before it takes destructive +actions leading to the following splat: + +BUG: kernel NULL pointer dereference, address: 0000000000000012 +PGD 5a4ca067 P4D 5a4ca067 PUD 37d4c067 PMD 0 +Oops: 0000 [#1] PREEMPT SMP +CPU: 2 PID: 10955 Comm: syz-executor.5 Not tainted 6.5.0-rc1-gdc7b257ee5dd #37 +Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 +RIP: 0010:mptcp_stream_accept+0x1ee/0x2f0 include/net/inet_sock.h:330 +Code: 0a 09 00 48 8b 1b 4c 39 e3 74 07 e8 bc 7c 7f fe eb a1 e8 b5 7c 7f fe 4c 8b 6c 24 08 eb 05 e8 a9 7c 7f fe 49 8b 85 d8 09 00 00 <0f> b6 40 12 88 44 24 07 0f b6 6c 24 07 bf 07 00 00 00 89 ee e8 89 +RSP: 0018:ffffc90000d07dc0 EFLAGS: 00010293 +RAX: 0000000000000000 RBX: ffff888037e8d020 RCX: ffff88803b093300 +RDX: 0000000000000000 RSI: ffffffff833822c5 RDI: ffffffff8333896a +RBP: 0000607f82031520 R08: ffff88803b093300 R09: 0000000000000000 +R10: 0000000000000000 R11: 0000000000003e83 R12: ffff888037e8d020 +R13: ffff888037e8c680 R14: ffff888009af7900 R15: ffff888009af6880 +FS: 00007fc26d708640(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000 +CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +CR2: 0000000000000012 CR3: 0000000066bc5001 CR4: 0000000000370ee0 +DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 +Call Trace: + + do_accept+0x1ae/0x260 net/socket.c:1872 + __sys_accept4+0x9b/0x110 net/socket.c:1913 + __do_sys_accept4 net/socket.c:1954 [inline] + __se_sys_accept4 net/socket.c:1951 [inline] + __x64_sys_accept4+0x20/0x30 net/socket.c:1951 + do_syscall_x64 arch/x86/entry/common.c:50 [inline] + do_syscall_64+0x47/0xa0 arch/x86/entry/common.c:80 + entry_SYSCALL_64_after_hwframe+0x6e/0xd8 + +Address the issue by temporary removing the pending request socket +from the accept queue, so that racing accept() can't touch them. + +After depleting the msk - the ssk still exists, as plain TCP sockets, +re-insert them into the accept queue, so that later inet_csk_listen_stop() +will complete the tcp socket disposal. + +Fixes: 2a6a870e44dd ("mptcp: stops worker on unaccepted sockets at listener close") +Cc: stable@vger.kernel.org +Reported-by: Christoph Paasch +Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/423 +Signed-off-by: Paolo Abeni +Reviewed-by: Matthieu Baerts +Signed-off-by: Matthieu Baerts +Link: https://lore.kernel.org/r/20230803-upstream-net-20230803-misc-fixes-6-5-v1-4-6671b1ab11cc@tessares.net +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/mptcp/protocol.h | 1 + net/mptcp/subflow.c | 60 +++++++++++++++++++++++++-------------------------- + 2 files changed, 30 insertions(+), 31 deletions(-) + +--- a/net/mptcp/protocol.h ++++ b/net/mptcp/protocol.h +@@ -320,7 +320,6 @@ struct mptcp_sock { + + u32 setsockopt_seq; + char ca_name[TCP_CA_NAME_MAX]; +- struct mptcp_sock *dl_next; + }; + + #define mptcp_data_lock(sk) spin_lock_bh(&(sk)->sk_lock.slock) +--- a/net/mptcp/subflow.c ++++ b/net/mptcp/subflow.c +@@ -1785,16 +1785,31 @@ static void subflow_state_change(struct + void mptcp_subflow_queue_clean(struct sock *listener_sk, struct sock *listener_ssk) + { + struct request_sock_queue *queue = &inet_csk(listener_ssk)->icsk_accept_queue; +- struct mptcp_sock *msk, *next, *head = NULL; +- struct request_sock *req; +- struct sock *sk; +- +- /* build a list of all unaccepted mptcp sockets */ ++ struct request_sock *req, *head, *tail; ++ struct mptcp_subflow_context *subflow; ++ struct sock *sk, *ssk; ++ ++ /* Due to lock dependencies no relevant lock can be acquired under rskq_lock. ++ * Splice the req list, so that accept() can not reach the pending ssk after ++ * the listener socket is released below. ++ */ + spin_lock_bh(&queue->rskq_lock); +- for (req = queue->rskq_accept_head; req; req = req->dl_next) { +- struct mptcp_subflow_context *subflow; +- struct sock *ssk = req->sk; ++ head = queue->rskq_accept_head; ++ tail = queue->rskq_accept_tail; ++ queue->rskq_accept_head = NULL; ++ queue->rskq_accept_tail = NULL; ++ spin_unlock_bh(&queue->rskq_lock); ++ ++ if (!head) ++ return; ++ ++ /* can't acquire the msk socket lock under the subflow one, ++ * or will cause ABBA deadlock ++ */ ++ release_sock(listener_ssk); + ++ for (req = head; req; req = req->dl_next) { ++ ssk = req->sk; + if (!sk_is_mptcp(ssk)) + continue; + +@@ -1802,32 +1817,10 @@ void mptcp_subflow_queue_clean(struct so + if (!subflow || !subflow->conn) + continue; + +- /* skip if already in list */ + sk = subflow->conn; +- msk = mptcp_sk(sk); +- if (msk->dl_next || msk == head) +- continue; +- + sock_hold(sk); +- msk->dl_next = head; +- head = msk; +- } +- spin_unlock_bh(&queue->rskq_lock); +- if (!head) +- return; +- +- /* can't acquire the msk socket lock under the subflow one, +- * or will cause ABBA deadlock +- */ +- release_sock(listener_ssk); +- +- for (msk = head; msk; msk = next) { +- sk = (struct sock *)msk; + + lock_sock_nested(sk, SINGLE_DEPTH_NESTING); +- next = msk->dl_next; +- msk->dl_next = NULL; +- + __mptcp_unaccepted_force_close(sk); + release_sock(sk); + +@@ -1851,6 +1844,13 @@ void mptcp_subflow_queue_clean(struct so + + /* we are still under the listener msk socket lock */ + lock_sock_nested(listener_ssk, SINGLE_DEPTH_NESTING); ++ ++ /* restore the listener queue, to let the TCP code clean it up */ ++ spin_lock_bh(&queue->rskq_lock); ++ WARN_ON_ONCE(queue->rskq_accept_head); ++ queue->rskq_accept_head = head; ++ queue->rskq_accept_tail = tail; ++ spin_unlock_bh(&queue->rskq_lock); + } + + static int subflow_ulp_init(struct sock *sk) diff --git a/queue-6.4/net-mana-fix-mana-vf-unload-when-hardware-is-unresponsive.patch b/queue-6.4/net-mana-fix-mana-vf-unload-when-hardware-is-unresponsive.patch new file mode 100644 index 00000000000..4670a97a8d7 --- /dev/null +++ b/queue-6.4/net-mana-fix-mana-vf-unload-when-hardware-is-unresponsive.patch @@ -0,0 +1,96 @@ +From a7dfeda6fdeccab4c7c3dce9a72c4262b9530c80 Mon Sep 17 00:00:00 2001 +From: Souradeep Chakrabarti +Date: Wed, 9 Aug 2023 03:22:05 -0700 +Subject: net: mana: Fix MANA VF unload when hardware is unresponsive + +From: Souradeep Chakrabarti + +commit a7dfeda6fdeccab4c7c3dce9a72c4262b9530c80 upstream. + +When unloading the MANA driver, mana_dealloc_queues() waits for the MANA +hardware to complete any inflight packets and set the pending send count +to zero. But if the hardware has failed, mana_dealloc_queues() +could wait forever. + +Fix this by adding a timeout to the wait. Set the timeout to 120 seconds, +which is a somewhat arbitrary value that is more than long enough for +functional hardware to complete any sends. + +Cc: stable@vger.kernel.org +Fixes: ca9c54d2d6a5 ("net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)") +Signed-off-by: Souradeep Chakrabarti +Link: https://lore.kernel.org/r/1691576525-24271-1-git-send-email-schakrabarti@linux.microsoft.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/microsoft/mana/mana_en.c | 37 +++++++++++++++++++++++--- + 1 file changed, 33 insertions(+), 4 deletions(-) + +--- a/drivers/net/ethernet/microsoft/mana/mana_en.c ++++ b/drivers/net/ethernet/microsoft/mana/mana_en.c +@@ -8,6 +8,7 @@ + #include + #include + #include ++#include + + #include + #include +@@ -2328,9 +2329,12 @@ int mana_attach(struct net_device *ndev) + static int mana_dealloc_queues(struct net_device *ndev) + { + struct mana_port_context *apc = netdev_priv(ndev); ++ unsigned long timeout = jiffies + 120 * HZ; + struct gdma_dev *gd = apc->ac->gdma_dev; + struct mana_txq *txq; ++ struct sk_buff *skb; + int i, err; ++ u32 tsleep; + + if (apc->port_is_up) + return -EINVAL; +@@ -2346,15 +2350,40 @@ static int mana_dealloc_queues(struct ne + * to false, but it doesn't matter since mana_start_xmit() drops any + * new packets due to apc->port_is_up being false. + * +- * Drain all the in-flight TX packets ++ * Drain all the in-flight TX packets. ++ * A timeout of 120 seconds for all the queues is used. ++ * This will break the while loop when h/w is not responding. ++ * This value of 120 has been decided here considering max ++ * number of queues. + */ ++ + for (i = 0; i < apc->num_queues; i++) { + txq = &apc->tx_qp[i].txq; +- +- while (atomic_read(&txq->pending_sends) > 0) +- usleep_range(1000, 2000); ++ tsleep = 1000; ++ while (atomic_read(&txq->pending_sends) > 0 && ++ time_before(jiffies, timeout)) { ++ usleep_range(tsleep, tsleep + 1000); ++ tsleep <<= 1; ++ } ++ if (atomic_read(&txq->pending_sends)) { ++ err = pcie_flr(to_pci_dev(gd->gdma_context->dev)); ++ if (err) { ++ netdev_err(ndev, "flr failed %d with %d pkts pending in txq %u\n", ++ err, atomic_read(&txq->pending_sends), ++ txq->gdma_txq_id); ++ } ++ break; ++ } + } + ++ for (i = 0; i < apc->num_queues; i++) { ++ txq = &apc->tx_qp[i].txq; ++ while ((skb = skb_dequeue(&txq->pending_skbs))) { ++ mana_unmap_skb(skb, apc); ++ dev_kfree_skb_any(skb); ++ } ++ atomic_set(&txq->pending_sends, 0); ++ } + /* We're 100% sure the queues can no longer be woken up, because + * we're sure now mana_poll_tx_cq() can't be running. + */ diff --git a/queue-6.4/nilfs2-fix-use-after-free-of-nilfs_root-in-dirtying-inodes-via-iput.patch b/queue-6.4/nilfs2-fix-use-after-free-of-nilfs_root-in-dirtying-inodes-via-iput.patch new file mode 100644 index 00000000000..2cce6355fa4 --- /dev/null +++ b/queue-6.4/nilfs2-fix-use-after-free-of-nilfs_root-in-dirtying-inodes-via-iput.patch @@ -0,0 +1,120 @@ +From f8654743a0e6909dc634cbfad6db6816f10f3399 Mon Sep 17 00:00:00 2001 +From: Ryusuke Konishi +Date: Sat, 29 Jul 2023 04:13:18 +0900 +Subject: nilfs2: fix use-after-free of nilfs_root in dirtying inodes via iput + +From: Ryusuke Konishi + +commit f8654743a0e6909dc634cbfad6db6816f10f3399 upstream. + +During unmount process of nilfs2, nothing holds nilfs_root structure after +nilfs2 detaches its writer in nilfs_detach_log_writer(). Previously, +nilfs_evict_inode() could cause use-after-free read for nilfs_root if +inodes are left in "garbage_list" and released by nilfs_dispose_list at +the end of nilfs_detach_log_writer(), and this bug was fixed by commit +9b5a04ac3ad9 ("nilfs2: fix use-after-free bug of nilfs_root in +nilfs_evict_inode()"). + +However, it turned out that there is another possibility of UAF in the +call path where mark_inode_dirty_sync() is called from iput(): + +nilfs_detach_log_writer() + nilfs_dispose_list() + iput() + mark_inode_dirty_sync() + __mark_inode_dirty() + nilfs_dirty_inode() + __nilfs_mark_inode_dirty() + nilfs_load_inode_block() --> causes UAF of nilfs_root struct + +This can happen after commit 0ae45f63d4ef ("vfs: add support for a +lazytime mount option"), which changed iput() to call +mark_inode_dirty_sync() on its final reference if i_state has I_DIRTY_TIME +flag and i_nlink is non-zero. + +This issue appears after commit 28a65b49eb53 ("nilfs2: do not write dirty +data after degenerating to read-only") when using the syzbot reproducer, +but the issue has potentially existed before. + +Fix this issue by adding a "purging flag" to the nilfs structure, setting +that flag while disposing the "garbage_list" and checking it in +__nilfs_mark_inode_dirty(). + +Unlike commit 9b5a04ac3ad9 ("nilfs2: fix use-after-free bug of nilfs_root +in nilfs_evict_inode()"), this patch does not rely on ns_writer to +determine whether to skip operations, so as not to break recovery on +mount. The nilfs_salvage_orphan_logs routine dirties the buffer of +salvaged data before attaching the log writer, so changing +__nilfs_mark_inode_dirty() to skip the operation when ns_writer is NULL +will cause recovery write to fail. The purpose of using the cleanup-only +flag is to allow for narrowing of such conditions. + +Link: https://lkml.kernel.org/r/20230728191318.33047-1-konishi.ryusuke@gmail.com +Signed-off-by: Ryusuke Konishi +Reported-by: syzbot+74db8b3087f293d3a13a@syzkaller.appspotmail.com +Closes: https://lkml.kernel.org/r/000000000000b4e906060113fd63@google.com +Fixes: 0ae45f63d4ef ("vfs: add support for a lazytime mount option") +Tested-by: Ryusuke Konishi +Cc: # 4.0+ +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + fs/nilfs2/inode.c | 8 ++++++++ + fs/nilfs2/segment.c | 2 ++ + fs/nilfs2/the_nilfs.h | 2 ++ + 3 files changed, 12 insertions(+) + +--- a/fs/nilfs2/inode.c ++++ b/fs/nilfs2/inode.c +@@ -1101,9 +1101,17 @@ int nilfs_set_file_dirty(struct inode *i + + int __nilfs_mark_inode_dirty(struct inode *inode, int flags) + { ++ struct the_nilfs *nilfs = inode->i_sb->s_fs_info; + struct buffer_head *ibh; + int err; + ++ /* ++ * Do not dirty inodes after the log writer has been detached ++ * and its nilfs_root struct has been freed. ++ */ ++ if (unlikely(nilfs_purging(nilfs))) ++ return 0; ++ + err = nilfs_load_inode_block(inode, &ibh); + if (unlikely(err)) { + nilfs_warn(inode->i_sb, +--- a/fs/nilfs2/segment.c ++++ b/fs/nilfs2/segment.c +@@ -2845,6 +2845,7 @@ void nilfs_detach_log_writer(struct supe + nilfs_segctor_destroy(nilfs->ns_writer); + nilfs->ns_writer = NULL; + } ++ set_nilfs_purging(nilfs); + + /* Force to free the list of dirty files */ + spin_lock(&nilfs->ns_inode_lock); +@@ -2857,4 +2858,5 @@ void nilfs_detach_log_writer(struct supe + up_write(&nilfs->ns_segctor_sem); + + nilfs_dispose_list(nilfs, &garbage_list, 1); ++ clear_nilfs_purging(nilfs); + } +--- a/fs/nilfs2/the_nilfs.h ++++ b/fs/nilfs2/the_nilfs.h +@@ -29,6 +29,7 @@ enum { + THE_NILFS_DISCONTINUED, /* 'next' pointer chain has broken */ + THE_NILFS_GC_RUNNING, /* gc process is running */ + THE_NILFS_SB_DIRTY, /* super block is dirty */ ++ THE_NILFS_PURGING, /* disposing dirty files for cleanup */ + }; + + /** +@@ -208,6 +209,7 @@ THE_NILFS_FNS(INIT, init) + THE_NILFS_FNS(DISCONTINUED, discontinued) + THE_NILFS_FNS(GC_RUNNING, gc_running) + THE_NILFS_FNS(SB_DIRTY, sb_dirty) ++THE_NILFS_FNS(PURGING, purging) + + /* + * Mount option operations diff --git a/queue-6.4/nvme-fix-possible-hang-when-removing-a-controller-during-error-recovery.patch b/queue-6.4/nvme-fix-possible-hang-when-removing-a-controller-during-error-recovery.patch new file mode 100644 index 00000000000..4df888d3044 --- /dev/null +++ b/queue-6.4/nvme-fix-possible-hang-when-removing-a-controller-during-error-recovery.patch @@ -0,0 +1,57 @@ +From 1b95e817916069ec45a7f259d088fd1c091a8cc6 Mon Sep 17 00:00:00 2001 +From: Ming Lei +Date: Tue, 11 Jul 2023 17:40:39 +0800 +Subject: nvme: fix possible hang when removing a controller during error recovery + +From: Ming Lei + +commit 1b95e817916069ec45a7f259d088fd1c091a8cc6 upstream. + +Error recovery can be interrupted by controller removal, then the +controller is left as quiesced, and IO hang can be caused. + +Fix the issue by unquiescing controller unconditionally when removing +namespaces. + +This way is reasonable and safe given forward progress can be made +when removing namespaces. + +Reviewed-by: Keith Busch +Reviewed-by: Sagi Grimberg +Reported-by: Chunguang Xu +Closes: https://lore.kernel.org/linux-nvme/cover.1685350577.git.chunguang.xu@shopee.com/ +Cc: stable@vger.kernel.org +Signed-off-by: Ming Lei +Signed-off-by: Keith Busch +Signed-off-by: Greg Kroah-Hartman +--- + drivers/nvme/host/core.c | 10 +++++++--- + 1 file changed, 7 insertions(+), 3 deletions(-) + +--- a/drivers/nvme/host/core.c ++++ b/drivers/nvme/host/core.c +@@ -4728,6 +4728,12 @@ void nvme_remove_namespaces(struct nvme_ + */ + nvme_mpath_clear_ctrl_paths(ctrl); + ++ /* ++ * Unquiesce io queues so any pending IO won't hang, especially ++ * those submitted from scan work ++ */ ++ nvme_unquiesce_io_queues(ctrl); ++ + /* prevent racing with ns scanning */ + flush_work(&ctrl->scan_work); + +@@ -4737,10 +4743,8 @@ void nvme_remove_namespaces(struct nvme_ + * removing the namespaces' disks; fail all the queues now to avoid + * potentially having to clean up the failed sync later. + */ +- if (ctrl->state == NVME_CTRL_DEAD) { ++ if (ctrl->state == NVME_CTRL_DEAD) + nvme_mark_namespaces_dead(ctrl); +- nvme_unquiesce_io_queues(ctrl); +- } + + /* this is a no-op when called from the controller reset handler */ + nvme_change_ctrl_state(ctrl, NVME_CTRL_DELETING_NOIO); diff --git a/queue-6.4/nvme-pci-add-nvme_quirk_bogus_nid-for-samsung-pm9b1-256g-and-512g.patch b/queue-6.4/nvme-pci-add-nvme_quirk_bogus_nid-for-samsung-pm9b1-256g-and-512g.patch new file mode 100644 index 00000000000..3c9b700ac76 --- /dev/null +++ b/queue-6.4/nvme-pci-add-nvme_quirk_bogus_nid-for-samsung-pm9b1-256g-and-512g.patch @@ -0,0 +1,36 @@ +From 688b419c57c13637d95d7879e165fff3dec581eb Mon Sep 17 00:00:00 2001 +From: August Wikerfors +Date: Wed, 16 Nov 2022 18:17:27 +0100 +Subject: nvme-pci: add NVME_QUIRK_BOGUS_NID for Samsung PM9B1 256G and 512G + +From: August Wikerfors + +commit 688b419c57c13637d95d7879e165fff3dec581eb upstream. + +The Samsung PM9B1 512G SSD found in some Lenovo Yoga 7 14ARB7 laptop units +reports eui as 0001000200030004 when resuming from s2idle, causing the +device to be removed with this error in dmesg: + +nvme nvme0: identifiers changed for nsid 1 + +To fix this, add a quirk to ignore namespace identifiers for this device. + +Signed-off-by: August Wikerfors +Signed-off-by: Keith Busch +Signed-off-by: Greg Kroah-Hartman +--- + drivers/nvme/host/pci.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/nvme/host/pci.c ++++ b/drivers/nvme/host/pci.c +@@ -3391,7 +3391,8 @@ static const struct pci_device_id nvme_i + { PCI_DEVICE(0x1d97, 0x2263), /* SPCC */ + .driver_data = NVME_QUIRK_DISABLE_WRITE_ZEROES, }, + { PCI_DEVICE(0x144d, 0xa80b), /* Samsung PM9B1 256G and 512G */ +- .driver_data = NVME_QUIRK_DISABLE_WRITE_ZEROES, }, ++ .driver_data = NVME_QUIRK_DISABLE_WRITE_ZEROES | ++ NVME_QUIRK_BOGUS_NID, }, + { PCI_DEVICE(0x144d, 0xa809), /* Samsung MZALQ256HBJD 256G */ + .driver_data = NVME_QUIRK_DISABLE_WRITE_ZEROES, }, + { PCI_DEVICE(0x1cc4, 0x6303), /* UMIS RPJTJ512MGE1QDY 512G */ diff --git a/queue-6.4/nvme-rdma-fix-potential-unbalanced-freeze-unfreeze.patch b/queue-6.4/nvme-rdma-fix-potential-unbalanced-freeze-unfreeze.patch new file mode 100644 index 00000000000..d7ff47d1c31 --- /dev/null +++ b/queue-6.4/nvme-rdma-fix-potential-unbalanced-freeze-unfreeze.patch @@ -0,0 +1,62 @@ +From 29b434d1e49252b3ad56ad3197e47fafff5356a1 Mon Sep 17 00:00:00 2001 +From: Ming Lei +Date: Tue, 11 Jul 2023 17:40:41 +0800 +Subject: nvme-rdma: fix potential unbalanced freeze & unfreeze + +From: Ming Lei + +commit 29b434d1e49252b3ad56ad3197e47fafff5356a1 upstream. + +Move start_freeze into nvme_rdma_configure_io_queues(), and there is +at least two benefits: + +1) fix unbalanced freeze and unfreeze, since re-connection work may +fail or be broken by removal + +2) IO during error recovery can be failfast quickly because nvme fabrics +unquiesces queues after teardown. + +One side-effect is that !mpath request may timeout during connecting +because of queue topo change, but that looks not one big deal: + +1) same problem exists with current code base + +2) compared with !mpath, mpath use case is dominant + +Fixes: 9f98772ba307 ("nvme-rdma: fix controller reset hang during traffic") +Cc: stable@vger.kernel.org +Signed-off-by: Ming Lei +Tested-by: Yi Zhang +Reviewed-by: Sagi Grimberg +Signed-off-by: Keith Busch +Signed-off-by: Greg Kroah-Hartman +--- + drivers/nvme/host/rdma.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/nvme/host/rdma.c ++++ b/drivers/nvme/host/rdma.c +@@ -918,6 +918,7 @@ static int nvme_rdma_configure_io_queues + goto out_cleanup_tagset; + + if (!new) { ++ nvme_start_freeze(&ctrl->ctrl); + nvme_unquiesce_io_queues(&ctrl->ctrl); + if (!nvme_wait_freeze_timeout(&ctrl->ctrl, NVME_IO_TIMEOUT)) { + /* +@@ -926,6 +927,7 @@ static int nvme_rdma_configure_io_queues + * to be safe. + */ + ret = -ENODEV; ++ nvme_unfreeze(&ctrl->ctrl); + goto out_wait_freeze_timed_out; + } + blk_mq_update_nr_hw_queues(ctrl->ctrl.tagset, +@@ -975,7 +977,6 @@ static void nvme_rdma_teardown_io_queues + bool remove) + { + if (ctrl->ctrl.queue_count > 1) { +- nvme_start_freeze(&ctrl->ctrl); + nvme_quiesce_io_queues(&ctrl->ctrl); + nvme_sync_io_queues(&ctrl->ctrl); + nvme_rdma_stop_io_queues(ctrl); diff --git a/queue-6.4/nvme-tcp-fix-potential-unbalanced-freeze-unfreeze.patch b/queue-6.4/nvme-tcp-fix-potential-unbalanced-freeze-unfreeze.patch new file mode 100644 index 00000000000..67b6a192897 --- /dev/null +++ b/queue-6.4/nvme-tcp-fix-potential-unbalanced-freeze-unfreeze.patch @@ -0,0 +1,62 @@ +From 99dc264014d5aed66ee37ddf136a38b5a2b1b529 Mon Sep 17 00:00:00 2001 +From: Ming Lei +Date: Tue, 11 Jul 2023 17:40:40 +0800 +Subject: nvme-tcp: fix potential unbalanced freeze & unfreeze + +From: Ming Lei + +commit 99dc264014d5aed66ee37ddf136a38b5a2b1b529 upstream. + +Move start_freeze into nvme_tcp_configure_io_queues(), and there is +at least two benefits: + +1) fix unbalanced freeze and unfreeze, since re-connection work may +fail or be broken by removal + +2) IO during error recovery can be failfast quickly because nvme fabrics +unquiesces queues after teardown. + +One side-effect is that !mpath request may timeout during connecting +because of queue topo change, but that looks not one big deal: + +1) same problem exists with current code base + +2) compared with !mpath, mpath use case is dominant + +Fixes: 2875b0aecabe ("nvme-tcp: fix controller reset hang during traffic") +Cc: stable@vger.kernel.org +Signed-off-by: Ming Lei +Tested-by: Yi Zhang +Reviewed-by: Sagi Grimberg +Signed-off-by: Keith Busch +Signed-off-by: Greg Kroah-Hartman +--- + drivers/nvme/host/tcp.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/nvme/host/tcp.c ++++ b/drivers/nvme/host/tcp.c +@@ -1909,6 +1909,7 @@ static int nvme_tcp_configure_io_queues( + goto out_cleanup_connect_q; + + if (!new) { ++ nvme_start_freeze(ctrl); + nvme_unquiesce_io_queues(ctrl); + if (!nvme_wait_freeze_timeout(ctrl, NVME_IO_TIMEOUT)) { + /* +@@ -1917,6 +1918,7 @@ static int nvme_tcp_configure_io_queues( + * to be safe. + */ + ret = -ENODEV; ++ nvme_unfreeze(ctrl); + goto out_wait_freeze_timed_out; + } + blk_mq_update_nr_hw_queues(ctrl->tagset, +@@ -2021,7 +2023,6 @@ static void nvme_tcp_teardown_io_queues( + if (ctrl->queue_count <= 1) + return; + nvme_quiesce_admin_queue(ctrl); +- nvme_start_freeze(ctrl); + nvme_quiesce_io_queues(ctrl); + nvme_sync_io_queues(ctrl); + nvme_tcp_stop_io_queues(ctrl); diff --git a/queue-6.4/parisc-fix-lightweight-spinlock-checks-to-not-break-futexes.patch b/queue-6.4/parisc-fix-lightweight-spinlock-checks-to-not-break-futexes.patch new file mode 100644 index 00000000000..8354673d627 --- /dev/null +++ b/queue-6.4/parisc-fix-lightweight-spinlock-checks-to-not-break-futexes.patch @@ -0,0 +1,178 @@ +From a0f4b7879f2e14986200747d1b545e5daac8c624 Mon Sep 17 00:00:00 2001 +From: Helge Deller +Date: Wed, 9 Aug 2023 09:21:58 +0200 +Subject: parisc: Fix lightweight spinlock checks to not break futexes + +From: Helge Deller + +commit a0f4b7879f2e14986200747d1b545e5daac8c624 upstream. + +The lightweight spinlock checks verify that a spinlock has either value +0 (spinlock locked) and that not any other bits than in +__ARCH_SPIN_LOCK_UNLOCKED_VAL is set. + +This breaks the current LWS code, which writes the address of the lock +into the lock word to unlock it, which was an optimization to save one +assembler instruction. + +Fix it by making spinlock_types.h accessible for asm code, change the +LWS spinlock-unlocking code to write __ARCH_SPIN_LOCK_UNLOCKED_VAL into +the lock word, and add some missing lightweight spinlock checks to the +LWS path. Finally, make the spinlock checks dependend on DEBUG_KERNEL. + +Noticed-by: John David Anglin +Signed-off-by: Helge Deller +Tested-by: John David Anglin +Cc: stable@vger.kernel.org # v6.4+ +Fixes: 15e64ef6520e ("parisc: Add lightweight spinlock checks") +Signed-off-by: Greg Kroah-Hartman +--- + arch/parisc/Kconfig.debug | 2 +- + arch/parisc/include/asm/spinlock.h | 2 -- + arch/parisc/include/asm/spinlock_types.h | 6 ++++++ + arch/parisc/kernel/syscall.S | 23 ++++++++++++++++++++--- + 4 files changed, 27 insertions(+), 6 deletions(-) + +diff --git a/arch/parisc/Kconfig.debug b/arch/parisc/Kconfig.debug +index 1401e4c5fe5f..bf2b21b96f0b 100644 +--- a/arch/parisc/Kconfig.debug ++++ b/arch/parisc/Kconfig.debug +@@ -2,7 +2,7 @@ + # + config LIGHTWEIGHT_SPINLOCK_CHECK + bool "Enable lightweight spinlock checks" +- depends on SMP && !DEBUG_SPINLOCK ++ depends on DEBUG_KERNEL && SMP && !DEBUG_SPINLOCK + default y + help + Add checks with low performance impact to the spinlock functions +diff --git a/arch/parisc/include/asm/spinlock.h b/arch/parisc/include/asm/spinlock.h +index edfcb9858bcb..0b326e52255e 100644 +--- a/arch/parisc/include/asm/spinlock.h ++++ b/arch/parisc/include/asm/spinlock.h +@@ -7,8 +7,6 @@ + #include + #include + +-#define SPINLOCK_BREAK_INSN 0x0000c006 /* break 6,6 */ +- + static inline void arch_spin_val_check(int lock_val) + { + if (IS_ENABLED(CONFIG_LIGHTWEIGHT_SPINLOCK_CHECK)) +diff --git a/arch/parisc/include/asm/spinlock_types.h b/arch/parisc/include/asm/spinlock_types.h +index d65934079ebd..efd06a897c6a 100644 +--- a/arch/parisc/include/asm/spinlock_types.h ++++ b/arch/parisc/include/asm/spinlock_types.h +@@ -4,6 +4,10 @@ + + #define __ARCH_SPIN_LOCK_UNLOCKED_VAL 0x1a46 + ++#define SPINLOCK_BREAK_INSN 0x0000c006 /* break 6,6 */ ++ ++#ifndef __ASSEMBLY__ ++ + typedef struct { + #ifdef CONFIG_PA20 + volatile unsigned int slock; +@@ -27,6 +31,8 @@ typedef struct { + volatile unsigned int counter; + } arch_rwlock_t; + ++#endif /* __ASSEMBLY__ */ ++ + #define __ARCH_RW_LOCK_UNLOCKED__ 0x01000000 + #define __ARCH_RW_LOCK_UNLOCKED { .lock_mutex = __ARCH_SPIN_LOCK_UNLOCKED, \ + .counter = __ARCH_RW_LOCK_UNLOCKED__ } +diff --git a/arch/parisc/kernel/syscall.S b/arch/parisc/kernel/syscall.S +index 1373e5129868..1f51aa9c8230 100644 +--- a/arch/parisc/kernel/syscall.S ++++ b/arch/parisc/kernel/syscall.S +@@ -39,6 +39,7 @@ registers). + #include + #include + #include ++#include + + #include + +@@ -66,6 +67,16 @@ registers). + stw \reg1, 0(%sr2,\reg2) + .endm + ++ /* raise exception if spinlock content is not zero or ++ * __ARCH_SPIN_LOCK_UNLOCKED_VAL */ ++ .macro spinlock_check spin_val,tmpreg ++#ifdef CONFIG_LIGHTWEIGHT_SPINLOCK_CHECK ++ ldi __ARCH_SPIN_LOCK_UNLOCKED_VAL, \tmpreg ++ andcm,= \spin_val, \tmpreg, %r0 ++ .word SPINLOCK_BREAK_INSN ++#endif ++ .endm ++ + .text + + .import syscall_exit,code +@@ -508,7 +519,8 @@ lws_start: + + lws_exit_noerror: + lws_pagefault_enable %r1,%r21 +- stw,ma %r20, 0(%sr2,%r20) ++ ldi __ARCH_SPIN_LOCK_UNLOCKED_VAL, %r21 ++ stw,ma %r21, 0(%sr2,%r20) + ssm PSW_SM_I, %r0 + b lws_exit + copy %r0, %r21 +@@ -521,7 +533,8 @@ lws_wouldblock: + + lws_pagefault: + lws_pagefault_enable %r1,%r21 +- stw,ma %r20, 0(%sr2,%r20) ++ ldi __ARCH_SPIN_LOCK_UNLOCKED_VAL, %r21 ++ stw,ma %r21, 0(%sr2,%r20) + ssm PSW_SM_I, %r0 + ldo 3(%r0),%r28 + b lws_exit +@@ -619,6 +632,7 @@ lws_compare_and_swap: + + /* Try to acquire the lock */ + LDCW 0(%sr2,%r20), %r28 ++ spinlock_check %r28, %r21 + comclr,<> %r0, %r28, %r0 + b,n lws_wouldblock + +@@ -772,6 +786,7 @@ cas2_lock_start: + + /* Try to acquire the lock */ + LDCW 0(%sr2,%r20), %r28 ++ spinlock_check %r28, %r21 + comclr,<> %r0, %r28, %r0 + b,n lws_wouldblock + +@@ -1001,6 +1016,7 @@ atomic_xchg_start: + + /* Try to acquire the lock */ + LDCW 0(%sr2,%r20), %r28 ++ spinlock_check %r28, %r21 + comclr,<> %r0, %r28, %r0 + b,n lws_wouldblock + +@@ -1199,6 +1215,7 @@ atomic_store_start: + + /* Try to acquire the lock */ + LDCW 0(%sr2,%r20), %r28 ++ spinlock_check %r28, %r21 + comclr,<> %r0, %r28, %r0 + b,n lws_wouldblock + +@@ -1330,7 +1347,7 @@ ENTRY(lws_lock_start) + /* lws locks */ + .rept 256 + /* Keep locks aligned at 16-bytes */ +- .word 1 ++ .word __ARCH_SPIN_LOCK_UNLOCKED_VAL + .word 0 + .word 0 + .word 0 +-- +2.41.0 + diff --git a/queue-6.4/radix-tree-test-suite-fix-incorrect-allocation-size-for-pthreads.patch b/queue-6.4/radix-tree-test-suite-fix-incorrect-allocation-size-for-pthreads.patch new file mode 100644 index 00000000000..c9adc2dfbbb --- /dev/null +++ b/queue-6.4/radix-tree-test-suite-fix-incorrect-allocation-size-for-pthreads.patch @@ -0,0 +1,41 @@ +From cac7ea57a06016e4914848b707477fb07ee4ae1c Mon Sep 17 00:00:00 2001 +From: Colin Ian King +Date: Thu, 27 Jul 2023 17:09:30 +0100 +Subject: radix tree test suite: fix incorrect allocation size for pthreads + +From: Colin Ian King + +commit cac7ea57a06016e4914848b707477fb07ee4ae1c upstream. + +Currently the pthread allocation for each array item is based on the size +of a pthread_t pointer and should be the size of the pthread_t structure, +so the allocation is under-allocating the correct size. Fix this by using +the size of each element in the pthreads array. + +Static analysis cppcheck reported: +tools/testing/radix-tree/regression1.c:180:2: warning: Size of pointer +'threads' used instead of size of its data. [pointerSize] + +Link: https://lkml.kernel.org/r/20230727160930.632674-1-colin.i.king@gmail.com +Fixes: 1366c37ed84b ("radix tree test harness") +Signed-off-by: Colin Ian King +Cc: Konstantin Khlebnikov +Cc: Matthew Wilcox (Oracle) +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + tools/testing/radix-tree/regression1.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/tools/testing/radix-tree/regression1.c ++++ b/tools/testing/radix-tree/regression1.c +@@ -177,7 +177,7 @@ void regression1_test(void) + nr_threads = 2; + pthread_barrier_init(&worker_barrier, NULL, nr_threads); + +- threads = malloc(nr_threads * sizeof(pthread_t *)); ++ threads = malloc(nr_threads * sizeof(*threads)); + + for (i = 0; i < nr_threads; i++) { + arg = i; diff --git a/queue-6.4/riscv-kexec-handle-r_riscv_call_plt-relocation-type.patch b/queue-6.4/riscv-kexec-handle-r_riscv_call_plt-relocation-type.patch new file mode 100644 index 00000000000..9d8c94b078d --- /dev/null +++ b/queue-6.4/riscv-kexec-handle-r_riscv_call_plt-relocation-type.patch @@ -0,0 +1,50 @@ +From d0b4f95a51038becce4bdab4789aa7ce59d4ea6e Mon Sep 17 00:00:00 2001 +From: Torsten Duwe +Date: Wed, 26 Jul 2023 11:53:59 +0200 +Subject: riscv/kexec: handle R_RISCV_CALL_PLT relocation type + +From: Torsten Duwe + +commit d0b4f95a51038becce4bdab4789aa7ce59d4ea6e upstream. + +R_RISCV_CALL has been deprecated and replaced by R_RISCV_CALL_PLT. See Enum +18-19 in Table 3. Relocation types here: + +https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-elf.adoc + +It was deprecated in ("Deprecated R_RISCV_CALL, prefer R_RISCV_CALL_PLT"): + +https://github.com/riscv-non-isa/riscv-elf-psabi-doc/commit/a0dced85018d7a0ec17023c9389cbd70b1dbc1b0 + +Recent tools (at least GNU binutils-2.40) already use R_RISCV_CALL_PLT. +Kernels built with such binutils fail kexec_load_file(2) with: + + kexec_image: Unknown rela relocation: 19 + kexec_image: Error loading purgatory ret=-8 + +The binary code at the call site remains the same, so tell +arch_kexec_apply_relocations_add() to handle _PLT alike. + +Fixes: 838b3e28488f ("RISC-V: Load purgatory in kexec_file") +Signed-off-by: Torsten Duwe +Signed-off-by: Petr Tesarik +Cc: Li Zhengyu +Cc: stable@vger.kernel.org +Reviewed-by: Conor Dooley +Link: https://lore.kernel.org/all/b046b164af8efd33bbdb7d4003273bdf9196a5b0.1690365011.git.petr.tesarik.ext@huawei.com/ +Signed-off-by: Palmer Dabbelt +Signed-off-by: Greg Kroah-Hartman +--- + arch/riscv/kernel/elf_kexec.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/arch/riscv/kernel/elf_kexec.c ++++ b/arch/riscv/kernel/elf_kexec.c +@@ -425,6 +425,7 @@ int arch_kexec_apply_relocations_add(str + * sym, instead of searching the whole relsec. + */ + case R_RISCV_PCREL_HI20: ++ case R_RISCV_CALL_PLT: + case R_RISCV_CALL: + *(u64 *)loc = CLEAN_IMM(UITYPE, *(u64 *)loc) | + ENCODE_UJTYPE_IMM(val - addr); diff --git a/queue-6.4/riscv-kexec-load-initrd-high-in-available-memory.patch b/queue-6.4/riscv-kexec-load-initrd-high-in-available-memory.patch new file mode 100644 index 00000000000..6a50b2bc945 --- /dev/null +++ b/queue-6.4/riscv-kexec-load-initrd-high-in-available-memory.patch @@ -0,0 +1,44 @@ +From 49af7a2cd5f678217b8b4f86a29411aebebf3e78 Mon Sep 17 00:00:00 2001 +From: Torsten Duwe +Date: Wed, 26 Jul 2023 11:54:01 +0200 +Subject: riscv/kexec: load initrd high in available memory + +From: Torsten Duwe + +commit 49af7a2cd5f678217b8b4f86a29411aebebf3e78 upstream. + +When initrd is loaded low, the secondary kernel fails like this: + + INITRD: 0xdc581000+0x00eef000 overlaps in-use memory region + +This initrd load address corresponds to the _end symbol, but the +reservation is aligned on PMD_SIZE, as explained by a comment in +setup_bootmem(). + +It is technically possible to align the initrd load address accordingly, +leaving a hole between the end of kernel and the initrd, but it is much +simpler to allocate the initrd top-down. + +Fixes: 838b3e28488f ("RISC-V: Load purgatory in kexec_file") +Signed-off-by: Torsten Duwe +Signed-off-by: Petr Tesarik +Cc: stable@vger.kernel.org +Reviewed-by: Conor Dooley +Link: https://lore.kernel.org/all/67c8eb9eea25717c2c8208d9bfbfaa39e6e2a1c6.1690365011.git.petr.tesarik.ext@huawei.com/ +Signed-off-by: Palmer Dabbelt +Signed-off-by: Greg Kroah-Hartman +--- + arch/riscv/kernel/elf_kexec.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/riscv/kernel/elf_kexec.c ++++ b/arch/riscv/kernel/elf_kexec.c +@@ -281,7 +281,7 @@ static void *elf_kexec_load(struct kimag + kbuf.buffer = initrd; + kbuf.bufsz = kbuf.memsz = initrd_len; + kbuf.buf_align = PAGE_SIZE; +- kbuf.top_down = false; ++ kbuf.top_down = true; + kbuf.mem = KEXEC_BUF_MEM_UNKNOWN; + ret = kexec_add_buffer(&kbuf); + if (ret) diff --git a/queue-6.4/riscv-mm-fix-2-instances-of-wmissing-variable-declarations.patch b/queue-6.4/riscv-mm-fix-2-instances-of-wmissing-variable-declarations.patch new file mode 100644 index 00000000000..f4e22baf0f8 --- /dev/null +++ b/queue-6.4/riscv-mm-fix-2-instances-of-wmissing-variable-declarations.patch @@ -0,0 +1,89 @@ +From d2402048bc8a206a56fde4bc41dd01336c7b5a21 Mon Sep 17 00:00:00 2001 +From: Nick Desaulniers +Date: Tue, 8 Aug 2023 09:35:00 -0700 +Subject: riscv: mm: fix 2 instances of -Wmissing-variable-declarations + +From: Nick Desaulniers + +commit d2402048bc8a206a56fde4bc41dd01336c7b5a21 upstream. + +I'm looking to enable -Wmissing-variable-declarations behind W=1. 0day +bot spotted the following instance in ARCH=riscv builds: + + arch/riscv/mm/init.c:276:7: warning: no previous extern declaration + for non-static variable 'trampoline_pg_dir' + [-Wmissing-variable-declarations] + 276 | pgd_t trampoline_pg_dir[PTRS_PER_PGD] __page_aligned_bss; + | ^ + arch/riscv/mm/init.c:276:1: note: declare 'static' if the variable is + not intended to be used outside of this translation unit + 276 | pgd_t trampoline_pg_dir[PTRS_PER_PGD] __page_aligned_bss; + | ^ + arch/riscv/mm/init.c:279:7: warning: no previous extern declaration + for non-static variable 'early_pg_dir' + [-Wmissing-variable-declarations] + 279 | pgd_t early_pg_dir[PTRS_PER_PGD] __initdata __aligned(PAGE_SIZE); + | ^ + arch/riscv/mm/init.c:279:1: note: declare 'static' if the variable is + not intended to be used outside of this translation unit + 279 | pgd_t early_pg_dir[PTRS_PER_PGD] __initdata __aligned(PAGE_SIZE); + | ^ + +These symbols are referenced by more than one translation unit, so make +sure they're both declared and include the correct header for their +declarations. Finally, sort the list of includes to help keep them tidy. + +Reported-by: kernel test robot +Closes: https://lore.kernel.org/llvm/202308081000.tTL1ElTr-lkp@intel.com/ +Signed-off-by: Nick Desaulniers +Link: https://lore.kernel.org/r/20230808-riscv_static-v2-1-2a1e2d2c7a4f@google.com +Cc: stable@vger.kernel.org +Signed-off-by: Palmer Dabbelt +Signed-off-by: Greg Kroah-Hartman +--- + arch/riscv/include/asm/pgtable.h | 2 ++ + arch/riscv/mm/init.c | 9 +++++---- + arch/riscv/mm/kasan_init.c | 1 - + 3 files changed, 7 insertions(+), 5 deletions(-) + +--- a/arch/riscv/include/asm/pgtable.h ++++ b/arch/riscv/include/asm/pgtable.h +@@ -188,6 +188,8 @@ extern struct pt_alloc_ops pt_ops __init + #define PAGE_KERNEL_IO __pgprot(_PAGE_IOREMAP) + + extern pgd_t swapper_pg_dir[]; ++extern pgd_t trampoline_pg_dir[]; ++extern pgd_t early_pg_dir[]; + + #ifdef CONFIG_TRANSPARENT_HUGEPAGE + static inline int pmd_present(pmd_t pmd) +--- a/arch/riscv/mm/init.c ++++ b/arch/riscv/mm/init.c +@@ -26,12 +26,13 @@ + #include + + #include +-#include +-#include +-#include + #include +-#include + #include ++#include ++#include ++#include ++#include ++#include + + #include "../kernel/head.h" + +--- a/arch/riscv/mm/kasan_init.c ++++ b/arch/riscv/mm/kasan_init.c +@@ -22,7 +22,6 @@ + * region is not and then we have to go down to the PUD level. + */ + +-extern pgd_t early_pg_dir[PTRS_PER_PGD]; + pgd_t tmp_pg_dir[PTRS_PER_PGD] __page_aligned_bss; + p4d_t tmp_p4d[PTRS_PER_P4D] __page_aligned_bss; + pud_t tmp_pud[PTRS_PER_PUD] __page_aligned_bss; diff --git a/queue-6.4/riscv-mmio-fix-readx-to-delay-ordering.patch b/queue-6.4/riscv-mmio-fix-readx-to-delay-ordering.patch new file mode 100644 index 00000000000..20ebf6d3f49 --- /dev/null +++ b/queue-6.4/riscv-mmio-fix-readx-to-delay-ordering.patch @@ -0,0 +1,68 @@ +From 4eb2eb1b4c0eb07793c240744843498564a67b83 Mon Sep 17 00:00:00 2001 +From: Andrea Parri +Date: Thu, 3 Aug 2023 06:27:38 +0200 +Subject: riscv,mmio: Fix readX()-to-delay() ordering + +From: Andrea Parri + +commit 4eb2eb1b4c0eb07793c240744843498564a67b83 upstream. + +Section 2.1 of the Platform Specification [1] states: + + Unless otherwise specified by a given I/O device, I/O devices are on + ordering channel 0 (i.e., they are point-to-point strongly ordered). + +which is not sufficient to guarantee that a readX() by a hart completes +before a subsequent delay() on the same hart (cf. memory-barriers.txt, +"Kernel I/O barrier effects"). + +Set the I(nput) bit in __io_ar() to restore the ordering, align inline +comments. + +[1] https://github.com/riscv/riscv-platform-specs + +Signed-off-by: Andrea Parri +Link: https://lore.kernel.org/r/20230803042738.5937-1-parri.andrea@gmail.com +Fixes: fab957c11efe ("RISC-V: Atomic and Locking Code") +Cc: stable@vger.kernel.org +Signed-off-by: Palmer Dabbelt +Signed-off-by: Greg Kroah-Hartman +--- + arch/riscv/include/asm/mmio.h | 16 ++++++++-------- + 1 file changed, 8 insertions(+), 8 deletions(-) + +--- a/arch/riscv/include/asm/mmio.h ++++ b/arch/riscv/include/asm/mmio.h +@@ -101,9 +101,9 @@ static inline u64 __raw_readq(const vola + * Relaxed I/O memory access primitives. These follow the Device memory + * ordering rules but do not guarantee any ordering relative to Normal memory + * accesses. These are defined to order the indicated access (either a read or +- * write) with all other I/O memory accesses. Since the platform specification +- * defines that all I/O regions are strongly ordered on channel 2, no explicit +- * fences are required to enforce this ordering. ++ * write) with all other I/O memory accesses to the same peripheral. Since the ++ * platform specification defines that all I/O regions are strongly ordered on ++ * channel 0, no explicit fences are required to enforce this ordering. + */ + /* FIXME: These are now the same as asm-generic */ + #define __io_rbr() do {} while (0) +@@ -125,14 +125,14 @@ static inline u64 __raw_readq(const vola + #endif + + /* +- * I/O memory access primitives. Reads are ordered relative to any +- * following Normal memory access. Writes are ordered relative to any prior +- * Normal memory access. The memory barriers here are necessary as RISC-V ++ * I/O memory access primitives. Reads are ordered relative to any following ++ * Normal memory read and delay() loop. Writes are ordered relative to any ++ * prior Normal memory write. The memory barriers here are necessary as RISC-V + * doesn't define any ordering between the memory space and the I/O space. + */ + #define __io_br() do {} while (0) +-#define __io_ar(v) __asm__ __volatile__ ("fence i,r" : : : "memory") +-#define __io_bw() __asm__ __volatile__ ("fence w,o" : : : "memory") ++#define __io_ar(v) ({ __asm__ __volatile__ ("fence i,ir" : : : "memory"); }) ++#define __io_bw() ({ __asm__ __volatile__ ("fence w,o" : : : "memory"); }) + #define __io_aw() mmiowb_set_pending() + + #define readb(c) ({ u8 __v; __io_br(); __v = readb_cpu(c); __io_ar(__v); __v; }) diff --git a/queue-6.4/riscv-start-of-dram-should-at-least-be-aligned-on-pmd-size-for-the-direct-mapping.patch b/queue-6.4/riscv-start-of-dram-should-at-least-be-aligned-on-pmd-size-for-the-direct-mapping.patch new file mode 100644 index 00000000000..da26eee7b3a --- /dev/null +++ b/queue-6.4/riscv-start-of-dram-should-at-least-be-aligned-on-pmd-size-for-the-direct-mapping.patch @@ -0,0 +1,48 @@ +From c3bcc65d4d2e8292c435322cbc34c318d06b8b6c Mon Sep 17 00:00:00 2001 +From: Alexandre Ghiti +Date: Tue, 4 Jul 2023 14:18:37 +0200 +Subject: riscv: Start of DRAM should at least be aligned on PMD size for the direct mapping + +From: Alexandre Ghiti + +commit c3bcc65d4d2e8292c435322cbc34c318d06b8b6c upstream. + +So that we do not end up mapping the whole linear mapping using 4K +pages, which is slow at boot time, and also very likely at runtime. + +So make sure we align the start of DRAM on a PMD boundary. + +Signed-off-by: Alexandre Ghiti +Reported-by: Song Shuai +Fixes: 3335068f8721 ("riscv: Use PUD/P4D/PGD pages for the linear mapping") +Tested-by: Song Shuai +Link: https://lore.kernel.org/r/20230704121837.248976-1-alexghiti@rivosinc.com +Cc: stable@vger.kernel.org +Signed-off-by: Palmer Dabbelt +Signed-off-by: Greg Kroah-Hartman +--- + arch/riscv/mm/init.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c +index 9ce504737d18..ad845c3aa9b2 100644 +--- a/arch/riscv/mm/init.c ++++ b/arch/riscv/mm/init.c +@@ -214,8 +214,13 @@ static void __init setup_bootmem(void) + memblock_reserve(vmlinux_start, vmlinux_end - vmlinux_start); + + phys_ram_end = memblock_end_of_DRAM(); ++ ++ /* ++ * Make sure we align the start of the memory on a PMD boundary so that ++ * at worst, we map the linear mapping with PMD mappings. ++ */ + if (!IS_ENABLED(CONFIG_XIP_KERNEL)) +- phys_ram_base = memblock_start_of_DRAM(); ++ phys_ram_base = memblock_start_of_DRAM() & PMD_MASK; + + /* + * In 64-bit, any use of __va/__pa before this point is wrong as we +-- +2.41.0 + diff --git a/queue-6.4/selftests-mm-ksm-fix-incorrect-evaluation-of-parameter.patch b/queue-6.4/selftests-mm-ksm-fix-incorrect-evaluation-of-parameter.patch new file mode 100644 index 00000000000..c45d00d08a0 --- /dev/null +++ b/queue-6.4/selftests-mm-ksm-fix-incorrect-evaluation-of-parameter.patch @@ -0,0 +1,61 @@ +From 65294de30cb8bc7659e445f7be2846af9ed35499 Mon Sep 17 00:00:00 2001 +From: Ayush Jain +Date: Fri, 28 Jul 2023 22:09:51 +0530 +Subject: selftests: mm: ksm: fix incorrect evaluation of parameter + +From: Ayush Jain + +commit 65294de30cb8bc7659e445f7be2846af9ed35499 upstream. + +A missing break in kms_tests leads to kselftest hang when the parameter -s +is used. + +In current code flow because of missing break in -s, -t parses args +spilled from -s and as -t accepts only valid values as 0,1 so any arg in +-s >1 or <0, gets in ksm_test failure + +This went undetected since, before the addition of option -t, the next +case -M would immediately break out of the switch statement but that is no +longer the case + +Add the missing break statement. + +----Before---- +./ksm_tests -H -s 100 +Invalid merge type + +----After---- +./ksm_tests -H -s 100 +Number of normal pages: 0 +Number of huge pages: 50 +Total size: 100 MiB +Total time: 0.401732682 s +Average speed: 248.922 MiB/s + +Link: https://lkml.kernel.org/r/20230728163952.4634-1-ayush.jain3@amd.com +Fixes: 07115fcc15b4 ("selftests/mm: add new selftests for KSM") +Signed-off-by: Ayush Jain +Reviewed-by: David Hildenbrand +Cc: Stefan Roesch +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + tools/testing/selftests/mm/ksm_tests.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/tools/testing/selftests/mm/ksm_tests.c b/tools/testing/selftests/mm/ksm_tests.c +index 435acebdc325..380b691d3eb9 100644 +--- a/tools/testing/selftests/mm/ksm_tests.c ++++ b/tools/testing/selftests/mm/ksm_tests.c +@@ -831,6 +831,7 @@ int main(int argc, char *argv[]) + printf("Size must be greater than 0\n"); + return KSFT_FAIL; + } ++ break; + case 't': + { + int tmp = atoi(optarg); +-- +2.41.0 + diff --git a/queue-6.4/selftests-mptcp-join-fix-delete-and-re-add-test.patch b/queue-6.4/selftests-mptcp-join-fix-delete-and-re-add-test.patch new file mode 100644 index 00000000000..90f46b95fc8 --- /dev/null +++ b/queue-6.4/selftests-mptcp-join-fix-delete-and-re-add-test.patch @@ -0,0 +1,49 @@ +From aaf2123a5cf46dbd97f84b6eee80269758064d93 Mon Sep 17 00:00:00 2001 +From: Andrea Claudi +Date: Thu, 3 Aug 2023 18:27:27 +0200 +Subject: selftests: mptcp: join: fix 'delete and re-add' test + +From: Andrea Claudi + +commit aaf2123a5cf46dbd97f84b6eee80269758064d93 upstream. + +mptcp_join 'delete and re-add' test fails when using ip mptcp: + + $ ./mptcp_join.sh -iI + + 002 delete and re-add before delete[ ok ] + mptcp_info subflows=1 [ ok ] + Error: argument "ADDRESS" is wrong: invalid for non-zero id address + after delete[fail] got 2:2 subflows expected 1 + +This happens because endpoint delete includes an ip address while id is +not 0, contrary to what is indicated in the ip mptcp man page: + +"When used with the delete id operation, an IFADDR is only included when +the ID is 0." + +This fixes the issue using the $addr variable in pm_nl_del_endpoint() +only when id is 0. + +Fixes: 34aa6e3bccd8 ("selftests: mptcp: add ip mptcp wrappers") +Cc: stable@vger.kernel.org +Signed-off-by: Andrea Claudi +Reviewed-by: Matthieu Baerts +Signed-off-by: Matthieu Baerts +Link: https://lore.kernel.org/r/20230803-upstream-net-20230803-misc-fixes-6-5-v1-1-6671b1ab11cc@tessares.net +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + tools/testing/selftests/net/mptcp/mptcp_join.sh | 1 + + 1 file changed, 1 insertion(+) + +--- a/tools/testing/selftests/net/mptcp/mptcp_join.sh ++++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh +@@ -676,6 +676,7 @@ pm_nl_del_endpoint() + local addr=$3 + + if [ $ip_mptcp -eq 1 ]; then ++ [ $id -ne 0 ] && addr='' + ip -n $ns mptcp endpoint delete id $id $addr + else + ip netns exec $ns ./pm_nl_ctl del $id $addr diff --git a/queue-6.4/selftests-mptcp-join-fix-implicit-ep-test.patch b/queue-6.4/selftests-mptcp-join-fix-implicit-ep-test.patch new file mode 100644 index 00000000000..f4d72c9d225 --- /dev/null +++ b/queue-6.4/selftests-mptcp-join-fix-implicit-ep-test.patch @@ -0,0 +1,57 @@ +From c8c101ae390a3e817369e94a6f12a1ddea420702 Mon Sep 17 00:00:00 2001 +From: Andrea Claudi +Date: Thu, 3 Aug 2023 18:27:28 +0200 +Subject: selftests: mptcp: join: fix 'implicit EP' test + +From: Andrea Claudi + +commit c8c101ae390a3e817369e94a6f12a1ddea420702 upstream. + +mptcp_join 'implicit EP' test currently fails when using ip mptcp: + + $ ./mptcp_join.sh -iI + + 001 implicit EP creation[fail] expected '10.0.2.2 10.0.2.2 id 1 implicit' found '10.0.2.2 id 1 rawflags 10 ' + Error: too many addresses or duplicate one: -22. + ID change is prevented[fail] expected '10.0.2.2 10.0.2.2 id 1 implicit' found '10.0.2.2 id 1 rawflags 10 ' + modif is allowed[fail] expected '10.0.2.2 10.0.2.2 id 1 signal' found '10.0.2.2 id 1 signal ' + +This happens because of two reasons: +- iproute v6.3.0 does not support the implicit flag, fixed with + iproute2-next commit 3a2535a41854 ("mptcp: add support for implicit + flag") +- pm_nl_check_endpoint wrongly expects the ip address to be repeated two + times in iproute output, and does not account for a final whitespace + in it. + +This fixes the issue trimming the whitespace in the output string and +removing the double address in the expected string. + +Fixes: 69c6ce7b6eca ("selftests: mptcp: add implicit endpoint test case") +Cc: stable@vger.kernel.org +Signed-off-by: Andrea Claudi +Reviewed-by: Matthieu Baerts +Signed-off-by: Matthieu Baerts +Link: https://lore.kernel.org/r/20230803-upstream-net-20230803-misc-fixes-6-5-v1-2-6671b1ab11cc@tessares.net +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + tools/testing/selftests/net/mptcp/mptcp_join.sh | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/tools/testing/selftests/net/mptcp/mptcp_join.sh ++++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh +@@ -767,10 +767,11 @@ pm_nl_check_endpoint() + fi + + if [ $ip_mptcp -eq 1 ]; then ++ # get line and trim trailing whitespace + line=$(ip -n $ns mptcp endpoint show $id) ++ line="${line% }" + # the dump order is: address id flags port dev +- expected_line="$addr" +- [ -n "$addr" ] && expected_line="$expected_line $addr" ++ [ -n "$addr" ] && expected_line="$addr" + expected_line="$expected_line $id" + [ -n "$_flags" ] && expected_line="$expected_line ${_flags//","/" "}" + [ -n "$dev" ] && expected_line="$expected_line $dev" diff --git a/queue-6.4/series b/queue-6.4/series index 272fd0a6a0a..8d74d07c0c9 100644 --- a/queue-6.4/series +++ b/queue-6.4/series @@ -13,3 +13,51 @@ wireguard-allowedips-expand-maximum-node-depth.patch mmc-moxart-read-scr-register-without-changing-byte-order.patch mmc-sdhci-f-sdh30-replace-with-sdhci_pltfm.patch ipv6-adjust-ndisc_is_useropt-to-also-return-true-for-pio.patch +selftests-mptcp-join-fix-delete-and-re-add-test.patch +selftests-mptcp-join-fix-implicit-ep-test.patch +mptcp-avoid-bogus-reset-on-fallback-close.patch +mptcp-fix-disconnect-vs-accept-race.patch +dmaengine-pl330-return-dma_paused-when-transaction-is-paused.patch +dmaengine-xilinx-xdma-fix-interrupt-vector-setting.patch +net-mana-fix-mana-vf-unload-when-hardware-is-unresponsive.patch +acpi-resource-revert-remove-zen-specific-match-and-quirks.patch +acpi-resource-always-use-madt-override-irq-settings-for-all-legacy-non-i8042-irqs.patch +acpi-resource-honor-madt-int_src_ovr-settings-for-irq1-on-amd-zen.patch +acpi-resource-add-irq-override-quirk-for-pcspecialist-elimina-pro-16-m.patch +zram-take-device-and-not-only-bvec-offset-into-account.patch +io_uring-parisc-adjust-pgoff-in-io_uring-mmap-for-parisc.patch +parisc-fix-lightweight-spinlock-checks-to-not-break-futexes.patch +riscv-start-of-dram-should-at-least-be-aligned-on-pmd-size-for-the-direct-mapping.patch +riscv-kexec-load-initrd-high-in-available-memory.patch +riscv-mmio-fix-readx-to-delay-ordering.patch +riscv-kexec-handle-r_riscv_call_plt-relocation-type.patch +riscv-mm-fix-2-instances-of-wmissing-variable-declarations.patch +nvme-fix-possible-hang-when-removing-a-controller-during-error-recovery.patch +nvme-tcp-fix-potential-unbalanced-freeze-unfreeze.patch +nvme-rdma-fix-potential-unbalanced-freeze-unfreeze.patch +nvme-pci-add-nvme_quirk_bogus_nid-for-samsung-pm9b1-256g-and-512g.patch +drm-nouveau-gr-enable-memory-loads-on-helper-invocation-on-all-channels.patch +drm-nouveau-nvkm-dp-add-workaround-to-fix-dp-1.3-dpcd-issues.patch +drm-shmem-helper-reset-vma-vm_ops-before-calling-dma_buf_mmap.patch +drm-amdgpu-fix-possible-uaf-in-amdgpu_cs_pass1.patch +drm-amd-pm-correct-the-pcie-width-for-smu-13.0.0.patch +drm-amd-display-fix-a-regression-on-polaris-cards.patch +drm-amd-display-check-attr-flag-before-set-cursor-degamma-on-dcn3.patch +drm-amd-disable-s-g-for-apus-when-64gb-or-more-host-memory.patch +tpm-tpm_tis-fix-upx-i11-dmi_match-condition.patch +tpm_tis-opt-in-interrupts.patch +cpuidle-dt_idle_genpd-add-helper-function-to-remove-genpd-topology.patch +cpuidle-psci-move-enabling-osi-mode-after-power-domains-creation.patch +io_uring-correct-check-for-o_tmpfile.patch +zsmalloc-fix-races-between-modifications-of-fullness-and-isolated.patch +hwmon-pmbus-bel-pfe-enable-pmbus_skip_status_check-for-pfe1100.patch +radix-tree-test-suite-fix-incorrect-allocation-size-for-pthreads.patch +cpufreq-amd-pstate-fix-global-sysfs-attribute-type.patch +fs-proc-kcore-reinstate-bounce-buffer-for-kcore_text-regions.patch +nilfs2-fix-use-after-free-of-nilfs_root-in-dirtying-inodes-via-iput.patch +accel-ivpu-add-set_pages_array_wc-uc-for-internal-buffers.patch +hugetlb-do-not-clear-hugetlb-dtor-until-allocating-vmemmap.patch +mm-damon-core-initialize-damo_filter-list-from-damos_new_filter.patch +selftests-mm-ksm-fix-incorrect-evaluation-of-parameter.patch +mm-memory-failure-fix-potential-unexpected-return-value-from-unpoison_memory.patch +mm-memory-failure-avoid-false-hwpoison-page-mapped-error-info.patch diff --git a/queue-6.4/tpm-tpm_tis-fix-upx-i11-dmi_match-condition.patch b/queue-6.4/tpm-tpm_tis-fix-upx-i11-dmi_match-condition.patch new file mode 100644 index 00000000000..33c624bb4c2 --- /dev/null +++ b/queue-6.4/tpm-tpm_tis-fix-upx-i11-dmi_match-condition.patch @@ -0,0 +1,44 @@ +From 51e5e551af53259e0274b0cd4ff83d8351fb8c40 Mon Sep 17 00:00:00 2001 +From: Peter Ujfalusi +Date: Tue, 8 Aug 2023 12:48:36 +0300 +Subject: tpm: tpm_tis: Fix UPX-i11 DMI_MATCH condition + +From: Peter Ujfalusi + +commit 51e5e551af53259e0274b0cd4ff83d8351fb8c40 upstream. + +The patch which made it to the kernel somehow changed the +match condition from +DMI_MATCH(DMI_PRODUCT_NAME, "UPX-TGL01") +to +DMI_MATCH(DMI_PRODUCT_VERSION, "UPX-TGL") + +Revert back to the correct match condition to disable the +interrupt mode on the board. + +Cc: stable@vger.kernel.org # v6.4+ +Fixes: edb13d7bb034 ("tpm: tpm_tis: Disable interrupts *only* for AEON UPX-i11") +Link: https://lore.kernel.org/lkml/20230524085844.11580-1-peter.ujfalusi@linux.intel.com/ +Signed-off-by: Peter Ujfalusi +Signed-off-by: Jarkko Sakkinen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/char/tpm/tpm_tis.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c +index ac4daaf294a3..3c0f68b9e44f 100644 +--- a/drivers/char/tpm/tpm_tis.c ++++ b/drivers/char/tpm/tpm_tis.c +@@ -183,7 +183,7 @@ static const struct dmi_system_id tpm_tis_dmi_table[] = { + .ident = "UPX-TGL", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "AAEON"), +- DMI_MATCH(DMI_PRODUCT_VERSION, "UPX-TGL"), ++ DMI_MATCH(DMI_PRODUCT_NAME, "UPX-TGL01"), + }, + }, + {} +-- +2.41.0 + diff --git a/queue-6.4/tpm_tis-opt-in-interrupts.patch b/queue-6.4/tpm_tis-opt-in-interrupts.patch new file mode 100644 index 00000000000..674dfb7f0f0 --- /dev/null +++ b/queue-6.4/tpm_tis-opt-in-interrupts.patch @@ -0,0 +1,34 @@ +From 6aaf663ee04a80b445f8f5abff53cb92cb583c88 Mon Sep 17 00:00:00 2001 +From: Jarkko Sakkinen +Date: Sat, 12 Aug 2023 02:07:10 +0300 +Subject: tpm_tis: Opt-in interrupts + +From: Jarkko Sakkinen + +commit 6aaf663ee04a80b445f8f5abff53cb92cb583c88 upstream. + +Cc: stable@vger.kernel.org # v6.4+ +Link: https://lore.kernel.org/linux-integrity/CAHk-=whRVp4h8uWOX1YO+Y99+44u4s=XxMK4v00B6F1mOfqPLg@mail.gmail.com/ +Fixes: e644b2f498d2 ("tpm, tpm_tis: Enable interrupt test") +Signed-off-by: Jarkko Sakkinen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/char/tpm/tpm_tis.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c +index 3c0f68b9e44f..7fa3d91042b2 100644 +--- a/drivers/char/tpm/tpm_tis.c ++++ b/drivers/char/tpm/tpm_tis.c +@@ -89,7 +89,7 @@ static inline void tpm_tis_iowrite32(u32 b, void __iomem *iobase, u32 addr) + tpm_tis_flush(iobase); + } + +-static int interrupts = -1; ++static int interrupts; + module_param(interrupts, int, 0444); + MODULE_PARM_DESC(interrupts, "Enable interrupts"); + +-- +2.41.0 + diff --git a/queue-6.4/zram-take-device-and-not-only-bvec-offset-into-account.patch b/queue-6.4/zram-take-device-and-not-only-bvec-offset-into-account.patch new file mode 100644 index 00000000000..f08a8de278d --- /dev/null +++ b/queue-6.4/zram-take-device-and-not-only-bvec-offset-into-account.patch @@ -0,0 +1,103 @@ +From 95848dcb9d676738411a8ff70a9704039f1b3982 Mon Sep 17 00:00:00 2001 +From: Christoph Hellwig +Date: Sat, 5 Aug 2023 07:55:37 +0200 +Subject: zram: take device and not only bvec offset into account + +From: Christoph Hellwig + +commit 95848dcb9d676738411a8ff70a9704039f1b3982 upstream. + +Commit af8b04c63708 ("zram: simplify bvec iteration in +__zram_make_request") changed the bio iteration in zram to rely on the +implicit capping to page boundaries in bio_for_each_segment. But it +failed to care for the fact zram not only care about the page alignment +of the bio payload, but also the page alignment into the device. For +buffered I/O and swap those are the same, but for direct I/O or kernel +internal I/O like XFS log buffer writes they can differ. + +Fix this by open coding bio_for_each_segment and limiting the bvec len +so that it never crosses over a page alignment boundary in the device +in addition to the payload boundary already taken care of by +bio_iter_iovec. + +Cc: stable@vger.kernel.org +Fixes: af8b04c63708 ("zram: simplify bvec iteration in __zram_make_request") +Reported-by: Dusty Mabe +Signed-off-by: Christoph Hellwig +Acked-by: Sergey Senozhatsky +Link: https://lore.kernel.org/r/20230805055537.147835-1-hch@lst.de +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + drivers/block/zram/zram_drv.c | 32 ++++++++++++++++++++------------ + 1 file changed, 20 insertions(+), 12 deletions(-) + +--- a/drivers/block/zram/zram_drv.c ++++ b/drivers/block/zram/zram_drv.c +@@ -1870,15 +1870,16 @@ static void zram_bio_discard(struct zram + + static void zram_bio_read(struct zram *zram, struct bio *bio) + { +- struct bvec_iter iter; +- struct bio_vec bv; +- unsigned long start_time; ++ unsigned long start_time = bio_start_io_acct(bio); ++ struct bvec_iter iter = bio->bi_iter; + +- start_time = bio_start_io_acct(bio); +- bio_for_each_segment(bv, bio, iter) { ++ do { + u32 index = iter.bi_sector >> SECTORS_PER_PAGE_SHIFT; + u32 offset = (iter.bi_sector & (SECTORS_PER_PAGE - 1)) << + SECTOR_SHIFT; ++ struct bio_vec bv = bio_iter_iovec(bio, iter); ++ ++ bv.bv_len = min_t(u32, bv.bv_len, PAGE_SIZE - offset); + + if (zram_bvec_read(zram, &bv, index, offset, bio) < 0) { + atomic64_inc(&zram->stats.failed_reads); +@@ -1890,22 +1891,26 @@ static void zram_bio_read(struct zram *z + zram_slot_lock(zram, index); + zram_accessed(zram, index); + zram_slot_unlock(zram, index); +- } ++ ++ bio_advance_iter_single(bio, &iter, bv.bv_len); ++ } while (iter.bi_size); ++ + bio_end_io_acct(bio, start_time); + bio_endio(bio); + } + + static void zram_bio_write(struct zram *zram, struct bio *bio) + { +- struct bvec_iter iter; +- struct bio_vec bv; +- unsigned long start_time; ++ unsigned long start_time = bio_start_io_acct(bio); ++ struct bvec_iter iter = bio->bi_iter; + +- start_time = bio_start_io_acct(bio); +- bio_for_each_segment(bv, bio, iter) { ++ do { + u32 index = iter.bi_sector >> SECTORS_PER_PAGE_SHIFT; + u32 offset = (iter.bi_sector & (SECTORS_PER_PAGE - 1)) << + SECTOR_SHIFT; ++ struct bio_vec bv = bio_iter_iovec(bio, iter); ++ ++ bv.bv_len = min_t(u32, bv.bv_len, PAGE_SIZE - offset); + + if (zram_bvec_write(zram, &bv, index, offset, bio) < 0) { + atomic64_inc(&zram->stats.failed_writes); +@@ -1916,7 +1921,10 @@ static void zram_bio_write(struct zram * + zram_slot_lock(zram, index); + zram_accessed(zram, index); + zram_slot_unlock(zram, index); +- } ++ ++ bio_advance_iter_single(bio, &iter, bv.bv_len); ++ } while (iter.bi_size); ++ + bio_end_io_acct(bio, start_time); + bio_endio(bio); + } diff --git a/queue-6.4/zsmalloc-fix-races-between-modifications-of-fullness-and-isolated.patch b/queue-6.4/zsmalloc-fix-races-between-modifications-of-fullness-and-isolated.patch new file mode 100644 index 00000000000..f5e67186bdc --- /dev/null +++ b/queue-6.4/zsmalloc-fix-races-between-modifications-of-fullness-and-isolated.patch @@ -0,0 +1,95 @@ +From 4b5d1e47b69426c0f7491d97d73ad0152d02d437 Mon Sep 17 00:00:00 2001 +From: Andrew Yang +Date: Fri, 21 Jul 2023 14:37:01 +0800 +Subject: zsmalloc: fix races between modifications of fullness and isolated + +From: Andrew Yang + +commit 4b5d1e47b69426c0f7491d97d73ad0152d02d437 upstream. + +We encountered many kernel exceptions of VM_BUG_ON(zspage->isolated == +0) in dec_zspage_isolation() and BUG_ON(!pages[1]) in zs_unmap_object() +lately. This issue only occurs when migration and reclamation occur at +the same time. + +With our memory stress test, we can reproduce this issue several times +a day. We have no idea why no one else encountered this issue. BTW, +we switched to the new kernel version with this defect a few months +ago. + +Since fullness and isolated share the same unsigned int, modifications of +them should be protected by the same lock. + +[andrew.yang@mediatek.com: move comment] + Link: https://lkml.kernel.org/r/20230727062910.6337-1-andrew.yang@mediatek.com +Link: https://lkml.kernel.org/r/20230721063705.11455-1-andrew.yang@mediatek.com +Fixes: c4549b871102 ("zsmalloc: remove zspage isolation for migration") +Signed-off-by: Andrew Yang +Reviewed-by: Sergey Senozhatsky +Cc: AngeloGioacchino Del Regno +Cc: Matthias Brugger +Cc: Minchan Kim +Cc: Sebastian Andrzej Siewior +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + mm/zsmalloc.c | 14 +++++++++----- + 1 file changed, 9 insertions(+), 5 deletions(-) + +--- a/mm/zsmalloc.c ++++ b/mm/zsmalloc.c +@@ -1977,6 +1977,7 @@ static void replace_sub_page(struct size + + static bool zs_page_isolate(struct page *page, isolate_mode_t mode) + { ++ struct zs_pool *pool; + struct zspage *zspage; + + /* +@@ -1986,9 +1987,10 @@ static bool zs_page_isolate(struct page + VM_BUG_ON_PAGE(PageIsolated(page), page); + + zspage = get_zspage(page); +- migrate_write_lock(zspage); ++ pool = zspage->pool; ++ spin_lock(&pool->lock); + inc_zspage_isolation(zspage); +- migrate_write_unlock(zspage); ++ spin_unlock(&pool->lock); + + return true; + } +@@ -2054,12 +2056,12 @@ static int zs_page_migrate(struct page * + kunmap_atomic(s_addr); + + replace_sub_page(class, zspage, newpage, page); ++ dec_zspage_isolation(zspage); + /* + * Since we complete the data copy and set up new zspage structure, + * it's okay to release the pool's lock. + */ + spin_unlock(&pool->lock); +- dec_zspage_isolation(zspage); + migrate_write_unlock(zspage); + + get_page(newpage); +@@ -2076,14 +2078,16 @@ static int zs_page_migrate(struct page * + + static void zs_page_putback(struct page *page) + { ++ struct zs_pool *pool; + struct zspage *zspage; + + VM_BUG_ON_PAGE(!PageIsolated(page), page); + + zspage = get_zspage(page); +- migrate_write_lock(zspage); ++ pool = zspage->pool; ++ spin_lock(&pool->lock); + dec_zspage_isolation(zspage); +- migrate_write_unlock(zspage); ++ spin_unlock(&pool->lock); + } + + static const struct movable_operations zsmalloc_mops = { -- 2.47.3