--- /dev/null
+From 1963546390ed8b649f529993a755eba0fdeb7aaa Mon Sep 17 00:00:00 2001
+From: Karol Wachowski <karol.wachowski@linux.intel.com>
+Date: Wed, 2 Aug 2023 08:37:35 +0200
+Subject: accel/ivpu: Add set_pages_array_wc/uc for internal buffers
+
+From: Karol Wachowski <karol.wachowski@linux.intel.com>
+
+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 <karol.wachowski@linux.intel.com>
+Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
+Signed-off-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20230802063735.3005291-1-stanislaw.gruszka@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+
--- /dev/null
+From 56fec0051a69ace182ca3fba47be9c13038b4e3f Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+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 <hdegoede@redhat.com>
+
+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 <stable@vger.kernel.org>
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+
--- /dev/null
+From 9728ac221160c5ea111879125a7694bb81364720 Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+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 <hdegoede@redhat.com>
+
+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 <stable@vger.kernel.org>
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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.
--- /dev/null
+From c6a1fd910d1bf8a0e3db7aebb229e3c81bc305c4 Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+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 <hdegoede@redhat.com>
+
+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 <stable@vger.kernel.org>
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 <asm/mpspec.h>
+ #include <asm/x86_init.h>
+ #include <asm/cpufeature.h>
++#include <asm/irq_vectors.h>
+
+ #ifdef CONFIG_ACPI_APEI
+ # include <asm/pgtable_types.h>
+@@ -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
+
--- /dev/null
+From 2d331a6ac4815e2e2fe5f2d80d908566e57797cc Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Wed, 9 Aug 2023 10:55:23 +0200
+Subject: ACPI: resource: revert "Remove "Zen" specific match and quirks"
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+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 <stable@vger.kernel.org>
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+
--- /dev/null
+From 5e720f8c8c9d959283c3908bbf32a91a01a86547 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Thomas=20Wei=C3=9Fschuh?= <linux@weissschuh.net>
+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 <linux@weissschuh.net>
+
+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] <TASK>
+[ 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 <jannik.glueckert@gmail.com>
+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 <stable@vger.kernel.org>
+Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
+Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Reviewed-by: Nathan Chancellor <nathan@kernel.org>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+ };
+
--- /dev/null
+From 9a8fa00dad3c7b260071f2f220cfb00505372c40 Mon Sep 17 00:00:00 2001
+From: Maulik Shah <quic_mkshah@quicinc.com>
+Date: Mon, 3 Jul 2023 14:25:53 +0530
+Subject: cpuidle: dt_idle_genpd: Add helper function to remove genpd topology
+
+From: Maulik Shah <quic_mkshah@quicinc.com>
+
+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 <ulf.hansson@linaro.org>
+Signed-off-by: Maulik Shah <quic_mkshah@quicinc.com>
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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)
+ {
--- /dev/null
+From 12acb348fa4528a4203edf1cce7a3be2c9af2279 Mon Sep 17 00:00:00 2001
+From: Maulik Shah <quic_mkshah@quicinc.com>
+Date: Mon, 3 Jul 2023 14:25:54 +0530
+Subject: cpuidle: psci: Move enabling OSI mode after power domains creation
+
+From: Maulik Shah <quic_mkshah@quicinc.com>
+
+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 <quic_mkshah@quicinc.com>
+Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
+
--- /dev/null
+From 8cda3ececf07d374774f6a13e5a94bc2dc04c26c Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= <ilpo.jarvinen@linux.intel.com>
+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 <ilpo.jarvinen@linux.intel.com>
+
+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 <rtresidd@electromag.com.au>
+Tested-by: Richard Tresidder <rtresidd@electromag.com.au>
+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 <ilpo.jarvinen@linux.intel.com>
+Link: https://lore.kernel.org/r/20230526105434.14959-1-ilpo.jarvinen@linux.intel.com
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From 96891e90d1256b569b1c183e7c9a0cfc568fa3b0 Mon Sep 17 00:00:00 2001
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+Date: Mon, 31 Jul 2023 12:14:39 +0200
+Subject: dmaengine: xilinx: xdma: Fix interrupt vector setting
+
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+
+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 <miquel.raynal@bootlin.com>
+Acked-by: Lizhi Hou <lizhi.hou@amd.com>
+Link: https://lore.kernel.org/r/20230731101442.792514-2-miquel.raynal@bootlin.com
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+
--- /dev/null
+From 08fffa74d9772d9538338be3f304006c94dde6f0 Mon Sep 17 00:00:00 2001
+From: Mario Limonciello <mario.limonciello@amd.com>
+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 <mario.limonciello@amd.com>
+
+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 <Hamza.Mahfooz@amd.com>
+Cc: Roman Li <roman.li@amd.com>
+Cc: <stable@vger.kernel.org> # 6.1.y: bf0207e172703 ("drm/amdgpu: add S/G display parameter")
+Cc: <stable@vger.kernel.org> # 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 <mario.limonciello@amd.com>
+Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/amdgpu/amdgpu.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;
--- /dev/null
+From 96b020e2163fb2197266b2f71b1007495206e6bb Mon Sep 17 00:00:00 2001
+From: Melissa Wen <mwen@igalia.com>
+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 <mwen@igalia.com>
+
+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 <mwen@igalia.com>
+Reviewed-by: Harry Wentland <harry.wentland@amd.com>
+Tested-by: Alex Hung <alex.hung@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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,
--- /dev/null
+From 3bb575572bf498a9d39e9d1ca5c06cc3152928a1 Mon Sep 17 00:00:00 2001
+From: Mario Limonciello <mario.limonciello@amd.com>
+Date: Fri, 28 Jul 2023 17:04:01 -0500
+Subject: drm/amd/display: Fix a regression on Polaris cards
+
+From: Mario Limonciello <mario.limonciello@amd.com>
+
+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 <Harry.Wentland@amd.com>
+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 <mario.limonciello@amd.com>
+Reviewed-by: Harry Wentland <harry.wentland@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+
--- /dev/null
+From bd60e2eafd8fb053948b6e23e8167baf7a159750 Mon Sep 17 00:00:00 2001
+From: Kenneth Feng <kenneth.feng@amd.com>
+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 <kenneth.feng@amd.com>
+
+commit bd60e2eafd8fb053948b6e23e8167baf7a159750 upstream.
+
+correct the pcie width value in pp_dpm_pcie for smu 13.0.0
+
+Signed-off-by: Kenneth Feng <kenneth.feng@amd.com>
+Reviewed-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com>
+Acked-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+
--- /dev/null
+From 90e065677e0362a777b9db97ea21d43a39211399 Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+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 <alexander.deucher@amd.com>
+
+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 <guchun.chen@amd.com>
+Reviewed-by: Christian König <christian.koenig@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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) {
--- /dev/null
+From 1cb9e2ef66d53b020842b18762e30d0eb4384de8 Mon Sep 17 00:00:00 2001
+From: Karol Herbst <kherbst@redhat.com>
+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 <kherbst@redhat.com>
+
+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 <bskeggs@redhat.com>
+Cc: David Airlie <airlied@gmail.com>
+Cc: nouveau@lists.freedesktop.org
+Cc: stable@vger.kernel.org # 4.19+
+Signed-off-by: Karol Herbst <kherbst@redhat.com>
+Reviewed-by: Dave Airlie <airlied@redhat.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20230622152017.2512101-1-kherbst@redhat.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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,
+ };
--- /dev/null
+From e4060dad253352382b20420d8ef98daab24dbc17 Mon Sep 17 00:00:00 2001
+From: Lyude Paul <lyude@redhat.com>
+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 <lyude@redhat.com>
+
+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 <lyude@redhat.com>
+Reviewed-by: Karol Herbst <kherbst@redhat.com>
+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: <stable@vger.kernel.org> # 6.3+
+Signed-off-by: Karol Herbst <kherbst@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 <drm/display/drm_dp.h>
++
+ #include <subdev/bios.h>
+ #include <subdev/bios/init.h>
+ #include <subdev/gpio.h>
+@@ -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;
--- /dev/null
+From 07dd476f6116966cb2006e25fdcf48f0715115ff Mon Sep 17 00:00:00 2001
+From: Boris Brezillon <boris.brezillon@collabora.com>
+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 <boris.brezillon@collabora.com>
+
+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: <stable@vger.kernel.org>
+Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
+Reported-by: Roman Stratiienko <r.stratiienko@gmail.com>
+Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
+Tested-by: Roman Stratiienko <r.stratiienko@gmail.com>
+Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
+Link: https://patchwork.freedesktop.org/patch/msgid/20230724112610.60974-1-boris.brezillon@collabora.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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.*/
--- /dev/null
+From 17457784004c84178798432a029ab20e14f728b1 Mon Sep 17 00:00:00 2001
+From: Lorenzo Stoakes <lstoakes@gmail.com>
+Date: Mon, 31 Jul 2023 22:50:21 +0100
+Subject: fs/proc/kcore: reinstate bounce buffer for KCORE_TEXT regions
+
+From: Lorenzo Stoakes <lstoakes@gmail.com>
+
+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 <lstoakes@gmail.com>
+Reported-by: Jiri Olsa <olsajiri@gmail.com>
+Closes: https://lore.kernel.org/all/ZHc2fm+9daF6cgCE@krava
+Tested-by: Jiri Olsa <jolsa@kernel.org>
+Tested-by: Will Deacon <will@kernel.org>
+Cc: Alexander Viro <viro@zeniv.linux.org.uk>
+Cc: Ard Biesheuvel <ardb@kernel.org>
+Cc: Baoquan He <bhe@redhat.com>
+Cc: Catalin Marinas <catalin.marinas@arm.com>
+Cc: David Hildenbrand <david@redhat.com>
+Cc: Jens Axboe <axboe@kernel.dk>
+Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
+Cc: Liu Shixin <liushixin2@huawei.com>
+Cc: Matthew Wilcox <willy@infradead.org>
+Cc: Mike Galbraith <efault@gmx.de>
+Cc: Thorsten Leemhuis <regressions@leemhuis.info>
+Cc: Uladzislau Rezki (Sony) <urezki@gmail.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+
--- /dev/null
+From 32c877191e022b55fe3a374f3d7e9fb5741c514d Mon Sep 17 00:00:00 2001
+From: Mike Kravetz <mike.kravetz@oracle.com>
+Date: Tue, 11 Jul 2023 15:09:41 -0700
+Subject: hugetlb: do not clear hugetlb dtor until allocating vmemmap
+
+From: Mike Kravetz <mike.kravetz@oracle.com>
+
+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 <mike.kravetz@oracle.com>
+Reviewed-by: Muchun Song <songmuchun@bytedance.com>
+Tested-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
+Cc: Axel Rasmussen <axelrasmussen@google.com>
+Cc: James Houghton <jthoughton@google.com>
+Cc: Jiaqi Yan <jiaqiyan@google.com>
+Cc: Miaohe Lin <linmiaohe@huawei.com>
+Cc: Michal Hocko <mhocko@suse.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 |
--- /dev/null
+From f38963b9cd0645a336cf30c5da2e89e34e34fec3 Mon Sep 17 00:00:00 2001
+From: Tao Ren <rentao.bupt@gmail.com>
+Date: Fri, 4 Aug 2023 15:14:03 -0700
+Subject: hwmon: (pmbus/bel-pfe) Enable PMBUS_SKIP_STATUS_CHECK for pfe1100
+
+From: Tao Ren <rentao.bupt@gmail.com>
+
+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 <rentao.bupt@gmail.com>
+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 <linux@roeck-us.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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]);
+ }
--- /dev/null
+From 72dbde0f2afbe4af8e8595a89c650ae6b9d9c36f Mon Sep 17 00:00:00 2001
+From: Aleksa Sarai <cyphar@cyphar.com>
+Date: Mon, 7 Aug 2023 12:24:15 +1000
+Subject: io_uring: correct check for O_TMPFILE
+
+From: Aleksa Sarai <cyphar@cyphar.com>
+
+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 <cyphar@cyphar.com>
+Link: https://lore.kernel.org/r/20230807-resolve_cached-o_tmpfile-v3-1-e49323e1ef6f@cyphar.com
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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)
--- /dev/null
+From 56675f8b9f9b15b024b8e3145fa289b004916ab7 Mon Sep 17 00:00:00 2001
+From: Helge Deller <deller@gmx.de>
+Date: Mon, 7 Aug 2023 20:04:09 +0200
+Subject: io_uring/parisc: Adjust pgoff in io_uring mmap() for parisc
+
+From: Helge Deller <deller@gmx.de>
+
+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 <deller@gmx.de>
+Reported-by: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>
+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 <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 <linux/compat.h>
+
+ /*
+- * 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
--- /dev/null
+From 5f1fc67f2cb8d3035d3acd273b48b97835af8afd Mon Sep 17 00:00:00 2001
+From: SeongJae Park <sj@kernel.org>
+Date: Sat, 29 Jul 2023 20:37:32 +0000
+Subject: mm/damon/core: initialize damo_filter->list from damos_new_filter()
+
+From: SeongJae Park <sj@kernel.org>
+
+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 <sj@kernel.org>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+
--- /dev/null
+From faeb2ff2c1c5cb60ce0da193580b256c941f99ca Mon Sep 17 00:00:00 2001
+From: Miaohe Lin <linmiaohe@huawei.com>
+Date: Thu, 27 Jul 2023 19:56:42 +0800
+Subject: mm: memory-failure: avoid false hwpoison page mapped error info
+
+From: Miaohe Lin <linmiaohe@huawei.com>
+
+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 <linmiaohe@huawei.com>
+Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>
+Acked-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
+Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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)) {
--- /dev/null
+From f29623e4a599c295cc8f518c8e4bb7848581a14d Mon Sep 17 00:00:00 2001
+From: Miaohe Lin <linmiaohe@huawei.com>
+Date: Thu, 27 Jul 2023 19:56:41 +0800
+Subject: mm: memory-failure: fix potential unexpected return value from unpoison_memory()
+
+From: Miaohe Lin <linmiaohe@huawei.com>
+
+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 <linmiaohe@huawei.com>
+Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
+Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
+Cc: Naoya Horiguchi <naoya.horiguchi@nec.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
--- /dev/null
+From ff18f9ef30ee87740f741b964375d0cfb84e1ec2 Mon Sep 17 00:00:00 2001
+From: Paolo Abeni <pabeni@redhat.com>
+Date: Thu, 3 Aug 2023 18:27:29 +0200
+Subject: mptcp: avoid bogus reset on fallback close
+
+From: Paolo Abeni <pabeni@redhat.com>
+
+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 <matthieu.baerts@tessares.net>
+Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/419
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net>
+Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
+Link: https://lore.kernel.org/r/20230803-upstream-net-20230803-misc-fixes-6-5-v1-3-6671b1ab11cc@tessares.net
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+ */
--- /dev/null
+From 511b90e39250135a7f900f1c3afbce25543018a2 Mon Sep 17 00:00:00 2001
+From: Paolo Abeni <pabeni@redhat.com>
+Date: Thu, 3 Aug 2023 18:27:30 +0200
+Subject: mptcp: fix disconnect vs accept race
+
+From: Paolo Abeni <pabeni@redhat.com>
+
+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:
+ <TASK>
+ 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 <cpaasch@apple.com>
+Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/423
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net>
+Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
+Link: https://lore.kernel.org/r/20230803-upstream-net-20230803-misc-fixes-6-5-v1-4-6671b1ab11cc@tessares.net
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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)
--- /dev/null
+From a7dfeda6fdeccab4c7c3dce9a72c4262b9530c80 Mon Sep 17 00:00:00 2001
+From: Souradeep Chakrabarti <schakrabarti@linux.microsoft.com>
+Date: Wed, 9 Aug 2023 03:22:05 -0700
+Subject: net: mana: Fix MANA VF unload when hardware is unresponsive
+
+From: Souradeep Chakrabarti <schakrabarti@linux.microsoft.com>
+
+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 <schakrabarti@linux.microsoft.com>
+Link: https://lore.kernel.org/r/1691576525-24271-1-git-send-email-schakrabarti@linux.microsoft.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 <linux/ethtool.h>
+ #include <linux/filter.h>
+ #include <linux/mm.h>
++#include <linux/pci.h>
+
+ #include <net/checksum.h>
+ #include <net/ip6_checksum.h>
+@@ -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.
+ */
--- /dev/null
+From f8654743a0e6909dc634cbfad6db6816f10f3399 Mon Sep 17 00:00:00 2001
+From: Ryusuke Konishi <konishi.ryusuke@gmail.com>
+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 <konishi.ryusuke@gmail.com>
+
+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 <konishi.ryusuke@gmail.com>
+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 <konishi.ryusuke@gmail.com>
+Cc: <stable@vger.kernel.org> # 4.0+
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
--- /dev/null
+From 1b95e817916069ec45a7f259d088fd1c091a8cc6 Mon Sep 17 00:00:00 2001
+From: Ming Lei <ming.lei@redhat.com>
+Date: Tue, 11 Jul 2023 17:40:39 +0800
+Subject: nvme: fix possible hang when removing a controller during error recovery
+
+From: Ming Lei <ming.lei@redhat.com>
+
+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 <kbusch@kernel.org>
+Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
+Reported-by: Chunguang Xu <brookxu.cn@gmail.com>
+Closes: https://lore.kernel.org/linux-nvme/cover.1685350577.git.chunguang.xu@shopee.com/
+Cc: stable@vger.kernel.org
+Signed-off-by: Ming Lei <ming.lei@redhat.com>
+Signed-off-by: Keith Busch <kbusch@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From 688b419c57c13637d95d7879e165fff3dec581eb Mon Sep 17 00:00:00 2001
+From: August Wikerfors <git@augustwikerfors.se>
+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 <git@augustwikerfors.se>
+
+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 <git@augustwikerfors.se>
+Signed-off-by: Keith Busch <kbusch@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 */
--- /dev/null
+From 29b434d1e49252b3ad56ad3197e47fafff5356a1 Mon Sep 17 00:00:00 2001
+From: Ming Lei <ming.lei@redhat.com>
+Date: Tue, 11 Jul 2023 17:40:41 +0800
+Subject: nvme-rdma: fix potential unbalanced freeze & unfreeze
+
+From: Ming Lei <ming.lei@redhat.com>
+
+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 <ming.lei@redhat.com>
+Tested-by: Yi Zhang <yi.zhang@redhat.com>
+Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
+Signed-off-by: Keith Busch <kbusch@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From 99dc264014d5aed66ee37ddf136a38b5a2b1b529 Mon Sep 17 00:00:00 2001
+From: Ming Lei <ming.lei@redhat.com>
+Date: Tue, 11 Jul 2023 17:40:40 +0800
+Subject: nvme-tcp: fix potential unbalanced freeze & unfreeze
+
+From: Ming Lei <ming.lei@redhat.com>
+
+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 <ming.lei@redhat.com>
+Tested-by: Yi Zhang <yi.zhang@redhat.com>
+Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
+Signed-off-by: Keith Busch <kbusch@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From a0f4b7879f2e14986200747d1b545e5daac8c624 Mon Sep 17 00:00:00 2001
+From: Helge Deller <deller@gmx.de>
+Date: Wed, 9 Aug 2023 09:21:58 +0200
+Subject: parisc: Fix lightweight spinlock checks to not break futexes
+
+From: Helge Deller <deller@gmx.de>
+
+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 <dave.anglin@bell.net>
+Signed-off-by: Helge Deller <deller@gmx.de>
+Tested-by: John David Anglin <dave.anglin@bell.net>
+Cc: stable@vger.kernel.org # v6.4+
+Fixes: 15e64ef6520e ("parisc: Add lightweight spinlock checks")
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 <asm/processor.h>
+ #include <asm/spinlock_types.h>
+
+-#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 <asm/assembly.h>
+ #include <asm/processor.h>
+ #include <asm/cache.h>
++#include <asm/spinlock_types.h>
+
+ #include <linux/linkage.h>
+
+@@ -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
+
--- /dev/null
+From cac7ea57a06016e4914848b707477fb07ee4ae1c Mon Sep 17 00:00:00 2001
+From: Colin Ian King <colin.i.king@gmail.com>
+Date: Thu, 27 Jul 2023 17:09:30 +0100
+Subject: radix tree test suite: fix incorrect allocation size for pthreads
+
+From: Colin Ian King <colin.i.king@gmail.com>
+
+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 <colin.i.king@gmail.com>
+Cc: Konstantin Khlebnikov <koct9i@gmail.com>
+Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From d0b4f95a51038becce4bdab4789aa7ce59d4ea6e Mon Sep 17 00:00:00 2001
+From: Torsten Duwe <duwe@suse.de>
+Date: Wed, 26 Jul 2023 11:53:59 +0200
+Subject: riscv/kexec: handle R_RISCV_CALL_PLT relocation type
+
+From: Torsten Duwe <duwe@suse.de>
+
+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 <duwe@suse.de>
+Signed-off-by: Petr Tesarik <petr.tesarik.ext@huawei.com>
+Cc: Li Zhengyu <lizhengyu3@huawei.com>
+Cc: stable@vger.kernel.org
+Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
+Link: https://lore.kernel.org/all/b046b164af8efd33bbdb7d4003273bdf9196a5b0.1690365011.git.petr.tesarik.ext@huawei.com/
+Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From 49af7a2cd5f678217b8b4f86a29411aebebf3e78 Mon Sep 17 00:00:00 2001
+From: Torsten Duwe <duwe@suse.de>
+Date: Wed, 26 Jul 2023 11:54:01 +0200
+Subject: riscv/kexec: load initrd high in available memory
+
+From: Torsten Duwe <duwe@suse.de>
+
+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 <duwe@suse.de>
+Signed-off-by: Petr Tesarik <petr.tesarik.ext@huawei.com>
+Cc: stable@vger.kernel.org
+Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
+Link: https://lore.kernel.org/all/67c8eb9eea25717c2c8208d9bfbfaa39e6e2a1c6.1690365011.git.petr.tesarik.ext@huawei.com/
+Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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)
--- /dev/null
+From d2402048bc8a206a56fde4bc41dd01336c7b5a21 Mon Sep 17 00:00:00 2001
+From: Nick Desaulniers <ndesaulniers@google.com>
+Date: Tue, 8 Aug 2023 09:35:00 -0700
+Subject: riscv: mm: fix 2 instances of -Wmissing-variable-declarations
+
+From: Nick Desaulniers <ndesaulniers@google.com>
+
+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 <lkp@intel.com>
+Closes: https://lore.kernel.org/llvm/202308081000.tTL1ElTr-lkp@intel.com/
+Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
+Link: https://lore.kernel.org/r/20230808-riscv_static-v2-1-2a1e2d2c7a4f@google.com
+Cc: stable@vger.kernel.org
+Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 <linux/kfence.h>
+
+ #include <asm/fixmap.h>
+-#include <asm/tlbflush.h>
+-#include <asm/sections.h>
+-#include <asm/soc.h>
+ #include <asm/io.h>
+-#include <asm/ptdump.h>
+ #include <asm/numa.h>
++#include <asm/pgtable.h>
++#include <asm/ptdump.h>
++#include <asm/sections.h>
++#include <asm/soc.h>
++#include <asm/tlbflush.h>
+
+ #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;
--- /dev/null
+From 4eb2eb1b4c0eb07793c240744843498564a67b83 Mon Sep 17 00:00:00 2001
+From: Andrea Parri <parri.andrea@gmail.com>
+Date: Thu, 3 Aug 2023 06:27:38 +0200
+Subject: riscv,mmio: Fix readX()-to-delay() ordering
+
+From: Andrea Parri <parri.andrea@gmail.com>
+
+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 <parri.andrea@gmail.com>
+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 <palmer@rivosinc.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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; })
--- /dev/null
+From c3bcc65d4d2e8292c435322cbc34c318d06b8b6c Mon Sep 17 00:00:00 2001
+From: Alexandre Ghiti <alexghiti@rivosinc.com>
+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 <alexghiti@rivosinc.com>
+
+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 <alexghiti@rivosinc.com>
+Reported-by: Song Shuai <suagrfillet@gmail.com>
+Fixes: 3335068f8721 ("riscv: Use PUD/P4D/PGD pages for the linear mapping")
+Tested-by: Song Shuai <suagrfillet@gmail.com>
+Link: https://lore.kernel.org/r/20230704121837.248976-1-alexghiti@rivosinc.com
+Cc: stable@vger.kernel.org
+Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+
--- /dev/null
+From 65294de30cb8bc7659e445f7be2846af9ed35499 Mon Sep 17 00:00:00 2001
+From: Ayush Jain <ayush.jain3@amd.com>
+Date: Fri, 28 Jul 2023 22:09:51 +0530
+Subject: selftests: mm: ksm: fix incorrect evaluation of parameter
+
+From: Ayush Jain <ayush.jain3@amd.com>
+
+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 <ayush.jain3@amd.com>
+Reviewed-by: David Hildenbrand <david@redhat.com>
+Cc: Stefan Roesch <shr@devkernel.io>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+
--- /dev/null
+From aaf2123a5cf46dbd97f84b6eee80269758064d93 Mon Sep 17 00:00:00 2001
+From: Andrea Claudi <aclaudi@redhat.com>
+Date: Thu, 3 Aug 2023 18:27:27 +0200
+Subject: selftests: mptcp: join: fix 'delete and re-add' test
+
+From: Andrea Claudi <aclaudi@redhat.com>
+
+commit aaf2123a5cf46dbd97f84b6eee80269758064d93 upstream.
+
+mptcp_join 'delete and re-add' test fails when using ip mptcp:
+
+ $ ./mptcp_join.sh -iI
+ <snip>
+ 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 <aclaudi@redhat.com>
+Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net>
+Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
+Link: https://lore.kernel.org/r/20230803-upstream-net-20230803-misc-fixes-6-5-v1-1-6671b1ab11cc@tessares.net
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
--- /dev/null
+From c8c101ae390a3e817369e94a6f12a1ddea420702 Mon Sep 17 00:00:00 2001
+From: Andrea Claudi <aclaudi@redhat.com>
+Date: Thu, 3 Aug 2023 18:27:28 +0200
+Subject: selftests: mptcp: join: fix 'implicit EP' test
+
+From: Andrea Claudi <aclaudi@redhat.com>
+
+commit c8c101ae390a3e817369e94a6f12a1ddea420702 upstream.
+
+mptcp_join 'implicit EP' test currently fails when using ip mptcp:
+
+ $ ./mptcp_join.sh -iI
+ <snip>
+ 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 <aclaudi@redhat.com>
+Reviewed-by: Matthieu Baerts <matthieu.baerts@tessares.net>
+Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
+Link: https://lore.kernel.org/r/20230803-upstream-net-20230803-misc-fixes-6-5-v1-2-6671b1ab11cc@tessares.net
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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"
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
--- /dev/null
+From 51e5e551af53259e0274b0cd4ff83d8351fb8c40 Mon Sep 17 00:00:00 2001
+From: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
+Date: Tue, 8 Aug 2023 12:48:36 +0300
+Subject: tpm: tpm_tis: Fix UPX-i11 DMI_MATCH condition
+
+From: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
+
+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 <peter.ujfalusi@linux.intel.com>
+Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+
--- /dev/null
+From 6aaf663ee04a80b445f8f5abff53cb92cb583c88 Mon Sep 17 00:00:00 2001
+From: Jarkko Sakkinen <jarkko@kernel.org>
+Date: Sat, 12 Aug 2023 02:07:10 +0300
+Subject: tpm_tis: Opt-in interrupts
+
+From: Jarkko Sakkinen <jarkko@kernel.org>
+
+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 <jarkko@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+
--- /dev/null
+From 95848dcb9d676738411a8ff70a9704039f1b3982 Mon Sep 17 00:00:00 2001
+From: Christoph Hellwig <hch@lst.de>
+Date: Sat, 5 Aug 2023 07:55:37 +0200
+Subject: zram: take device and not only bvec offset into account
+
+From: Christoph Hellwig <hch@lst.de>
+
+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 <dusty@dustymabe.com>
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Acked-by: Sergey Senozhatsky <senozhatsky@chromium.org>
+Link: https://lore.kernel.org/r/20230805055537.147835-1-hch@lst.de
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+ }
--- /dev/null
+From 4b5d1e47b69426c0f7491d97d73ad0152d02d437 Mon Sep 17 00:00:00 2001
+From: Andrew Yang <andrew.yang@mediatek.com>
+Date: Fri, 21 Jul 2023 14:37:01 +0800
+Subject: zsmalloc: fix races between modifications of fullness and isolated
+
+From: Andrew Yang <andrew.yang@mediatek.com>
+
+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 <andrew.yang@mediatek.com>
+Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org>
+Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+Cc: Matthias Brugger <matthias.bgg@gmail.com>
+Cc: Minchan Kim <minchan@kernel.org>
+Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 = {
projects / thirdparty / kernel / stable-queue.git / commitdiff
