--- /dev/null
+From 977a3009547dad4a5bc95d91be4a58c9f7eedac0 Mon Sep 17 00:00:00 2001
+From: Al Viro <viro@zeniv.linux.org.uk>
+Date: Fri, 6 Jan 2023 19:25:59 -0500
+Subject: alpha: fix FEN fault handling
+
+From: Al Viro <viro@zeniv.linux.org.uk>
+
+commit 977a3009547dad4a5bc95d91be4a58c9f7eedac0 upstream.
+
+Type 3 instruction fault (FPU insn with FPU disabled) is handled
+by quietly enabling FPU and returning. Which is fine, except that
+we need to do that both for fault in userland and in the kernel;
+the latter *can* legitimately happen - all it takes is this:
+
+.global _start
+_start:
+ call_pal 0xae
+ lda $0, 0
+ ldq $0, 0($0)
+
+- call_pal CLRFEN to clear "FPU enabled" flag and arrange for
+a signal delivery (SIGSEGV in this case).
+
+Fixed by moving the handling of type 3 into the common part of
+do_entIF(), before we check for kernel vs. user mode.
+
+Incidentally, the check for kernel mode is unidiomatic; the normal
+way to do that is !user_mode(regs). The difference is that
+the open-coded variant treats any of bits 63..3 of regs->ps being
+set as "it's user mode" while the normal approach is to check just
+the bit 3. PS is a 4-bit register and regs->ps always will have
+bits 63..4 clear, so the open-coded variant here is actually equivalent
+to !user_mode(regs). Harder to follow, though...
+
+Cc: stable@vger.kernel.org
+Reviewed-by: Richard Henderson <rth@twiddle.net>
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/alpha/kernel/traps.c | 30 +++++++++++++++---------------
+ 1 file changed, 15 insertions(+), 15 deletions(-)
+
+--- a/arch/alpha/kernel/traps.c
++++ b/arch/alpha/kernel/traps.c
+@@ -235,7 +235,21 @@ do_entIF(unsigned long type, struct pt_r
+ {
+ int signo, code;
+
+- if ((regs->ps & ~IPL_MAX) == 0) {
++ if (type == 3) { /* FEN fault */
++ /* Irritating users can call PAL_clrfen to disable the
++ FPU for the process. The kernel will then trap in
++ do_switch_stack and undo_switch_stack when we try
++ to save and restore the FP registers.
++
++ Given that GCC by default generates code that uses the
++ FP registers, PAL_clrfen is not useful except for DoS
++ attacks. So turn the bleeding FPU back on and be done
++ with it. */
++ current_thread_info()->pcb.flags |= 1;
++ __reload_thread(¤t_thread_info()->pcb);
++ return;
++ }
++ if (!user_mode(regs)) {
+ if (type == 1) {
+ const unsigned int *data
+ = (const unsigned int *) regs->pc;
+@@ -368,20 +382,6 @@ do_entIF(unsigned long type, struct pt_r
+ }
+ break;
+
+- case 3: /* FEN fault */
+- /* Irritating users can call PAL_clrfen to disable the
+- FPU for the process. The kernel will then trap in
+- do_switch_stack and undo_switch_stack when we try
+- to save and restore the FP registers.
+-
+- Given that GCC by default generates code that uses the
+- FP registers, PAL_clrfen is not useful except for DoS
+- attacks. So turn the bleeding FPU back on and be done
+- with it. */
+- current_thread_info()->pcb.flags |= 1;
+- __reload_thread(¤t_thread_info()->pcb);
+- return;
+-
+ case 5: /* illoc */
+ default: /* unexpected instruction-fault type */
+ ;
--- /dev/null
+From ea24b9953bcd3889f77a66e7f1d7e86e995dd9c3 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?=C5=81ukasz=20Stelmach?= <l.stelmach@samsung.com>
+Date: Thu, 23 Feb 2023 08:47:48 +0100
+Subject: ALSA: hda/realtek: Add quirk for HP EliteDesk 800 G6 Tower PC
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Łukasz Stelmach <l.stelmach@samsung.com>
+
+commit ea24b9953bcd3889f77a66e7f1d7e86e995dd9c3 upstream.
+
+HP EliteDesk 800 G6 Tower PC (103c:870c) requires a quirk for enabling
+headset-mic.
+
+Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
+Cc: <stable@vger.kernel.org>
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=217008
+Link: https://lore.kernel.org/r/20230223074749.1026060-1-l.stelmach@samsung.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/pci/hda/patch_realtek.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -11153,6 +11153,7 @@ static const struct snd_pci_quirk alc662
+ SND_PCI_QUIRK(0x1028, 0x0698, "Dell", ALC668_FIXUP_DELL_MIC_NO_PRESENCE),
+ SND_PCI_QUIRK(0x1028, 0x069f, "Dell", ALC668_FIXUP_DELL_MIC_NO_PRESENCE),
+ SND_PCI_QUIRK(0x103c, 0x1632, "HP RP5800", ALC662_FIXUP_HP_RP5800),
++ SND_PCI_QUIRK(0x103c, 0x870c, "HP", ALC897_FIXUP_HP_HSMIC_VERB),
+ SND_PCI_QUIRK(0x103c, 0x8719, "HP", ALC897_FIXUP_HP_HSMIC_VERB),
+ SND_PCI_QUIRK(0x103c, 0x873e, "HP", ALC671_FIXUP_HP_HEADSET_MIC2),
+ SND_PCI_QUIRK(0x103c, 0x877e, "HP 288 Pro G6", ALC671_FIXUP_HP_HEADSET_MIC2),
--- /dev/null
+From 951606a14a8901e3551fe4d8d3cedd73fe954ce1 Mon Sep 17 00:00:00 2001
+From: Dmitry Fomin <fomindmitriyfoma@mail.ru>
+Date: Sat, 25 Feb 2023 21:43:21 +0300
+Subject: ALSA: ice1712: Do not left ice->gpio_mutex locked in aureon_add_controls()
+
+From: Dmitry Fomin <fomindmitriyfoma@mail.ru>
+
+commit 951606a14a8901e3551fe4d8d3cedd73fe954ce1 upstream.
+
+If snd_ctl_add() fails in aureon_add_controls(), it immediately returns
+and leaves ice->gpio_mutex locked. ice->gpio_mutex locks in
+snd_ice1712_save_gpio_status and unlocks in
+snd_ice1712_restore_gpio_status(ice).
+
+It seems that the mutex is required only for aureon_cs8415_get(),
+so snd_ice1712_restore_gpio_status(ice) can be placed
+just after that. Compile tested only.
+
+Found by Linux Verification Center (linuxtesting.org) with SVACE.
+
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Signed-off-by: Dmitry Fomin <fomindmitriyfoma@mail.ru>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20230225184322.6286-1-fomindmitriyfoma@mail.ru
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/pci/ice1712/aureon.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/sound/pci/ice1712/aureon.c
++++ b/sound/pci/ice1712/aureon.c
+@@ -1892,6 +1892,7 @@ static int aureon_add_controls(struct sn
+ unsigned char id;
+ snd_ice1712_save_gpio_status(ice);
+ id = aureon_cs8415_get(ice, CS8415_ID);
++ snd_ice1712_restore_gpio_status(ice);
+ if (id != 0x41)
+ dev_info(ice->card->dev,
+ "No CS8415 chip. Skipping CS8415 controls.\n");
+@@ -1909,7 +1910,6 @@ static int aureon_add_controls(struct sn
+ kctl->id.device = ice->pcm->device;
+ }
+ }
+- snd_ice1712_restore_gpio_status(ice);
+ }
+
+ return 0;
--- /dev/null
+From 8e4505e617a80f601e2f53a917611777f128f925 Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Thu, 9 Feb 2023 11:58:36 +0100
+Subject: ARM: dts: exynos: correct TMU phandle in Exynos4
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit 8e4505e617a80f601e2f53a917611777f128f925 upstream.
+
+TMU node uses 0 as thermal-sensor-cells, thus thermal zone referencing
+it must not have an argument to phandle.
+
+Fixes: 328829a6ad70 ("ARM: dts: define default thermal-zones for exynos4")
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20230209105841.779596-1-krzysztof.kozlowski@linaro.org
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm/boot/dts/exynos4-cpu-thermal.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm/boot/dts/exynos4-cpu-thermal.dtsi
++++ b/arch/arm/boot/dts/exynos4-cpu-thermal.dtsi
+@@ -10,7 +10,7 @@
+ / {
+ thermal-zones {
+ cpu_thermal: cpu-thermal {
+- thermal-sensors = <&tmu 0>;
++ thermal-sensors = <&tmu>;
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+ trips {
--- /dev/null
+From 408ab6786dbf6dd696488054c9559681112ef994 Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Thu, 9 Feb 2023 11:58:37 +0100
+Subject: ARM: dts: exynos: correct TMU phandle in Exynos4210
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit 408ab6786dbf6dd696488054c9559681112ef994 upstream.
+
+TMU node uses 0 as thermal-sensor-cells, thus thermal zone referencing
+it must not have an argument to phandle. Since thermal-sensors property is
+already defined in included exynos4-cpu-thermal.dtsi, drop it from
+exynos4210.dtsi to fix the error and remoev redundancy.
+
+Fixes: 9843a2236003 ("ARM: dts: Provide dt bindings identical for Exynos TMU")
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20230209105841.779596-2-krzysztof.kozlowski@linaro.org
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm/boot/dts/exynos4210.dtsi | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/arch/arm/boot/dts/exynos4210.dtsi
++++ b/arch/arm/boot/dts/exynos4210.dtsi
+@@ -382,7 +382,6 @@
+ &cpu_thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+- thermal-sensors = <&tmu 0>;
+ };
+
+ &gic {
--- /dev/null
+From 33e2c595e2e4016991ead44933a29d1ef93d5f26 Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Thu, 9 Feb 2023 11:58:38 +0100
+Subject: ARM: dts: exynos: correct TMU phandle in Exynos5250
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit 33e2c595e2e4016991ead44933a29d1ef93d5f26 upstream.
+
+TMU node uses 0 as thermal-sensor-cells, thus thermal zone referencing
+it must not have an argument to phandle.
+
+Cc: <stable@vger.kernel.org>
+Fixes: 9843a2236003 ("ARM: dts: Provide dt bindings identical for Exynos TMU")
+Link: https://lore.kernel.org/r/20230209105841.779596-3-krzysztof.kozlowski@linaro.org
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm/boot/dts/exynos5250.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm/boot/dts/exynos5250.dtsi
++++ b/arch/arm/boot/dts/exynos5250.dtsi
+@@ -1109,7 +1109,7 @@
+ &cpu_thermal {
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+- thermal-sensors = <&tmu 0>;
++ thermal-sensors = <&tmu>;
+
+ cooling-maps {
+ map0 {
--- /dev/null
+From 2e3d0e20d8456f876607a8af61fdb83dfbf98cb6 Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Thu, 9 Feb 2023 11:58:40 +0100
+Subject: ARM: dts: exynos: correct TMU phandle in Odroid HC1
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit 2e3d0e20d8456f876607a8af61fdb83dfbf98cb6 upstream.
+
+TMU node uses 0 as thermal-sensor-cells, thus thermal zone referencing
+it must not have an argument to phandle. This was not critical before,
+but since rework of thermal Devicetree initialization in the
+commit 3fd6d6e2b4e8 ("thermal/of: Rework the thermal device tree
+initialization"), this leads to errors registering thermal zones other
+than first one:
+
+ thermal_sys: cpu0-thermal: Failed to read thermal-sensors cells: -2
+ thermal_sys: Failed to find thermal zone for tmu id=0
+ exynos-tmu 10064000.tmu: Failed to register sensor: -2
+ exynos-tmu: probe of 10064000.tmu failed with error -2
+
+Fixes: 1ac49427b566 ("ARM: dts: exynos: Add support for Hardkernel's Odroid HC1 board")
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20230209105841.779596-5-krzysztof.kozlowski@linaro.org
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm/boot/dts/exynos5422-odroidhc1.dts | 10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+--- a/arch/arm/boot/dts/exynos5422-odroidhc1.dts
++++ b/arch/arm/boot/dts/exynos5422-odroidhc1.dts
+@@ -29,7 +29,7 @@
+
+ thermal-zones {
+ cpu0_thermal: cpu0-thermal {
+- thermal-sensors = <&tmu_cpu0 0>;
++ thermal-sensors = <&tmu_cpu0>;
+ trips {
+ cpu0_alert0: cpu-alert-0 {
+ temperature = <70000>; /* millicelsius */
+@@ -84,7 +84,7 @@
+ };
+ };
+ cpu1_thermal: cpu1-thermal {
+- thermal-sensors = <&tmu_cpu1 0>;
++ thermal-sensors = <&tmu_cpu1>;
+ trips {
+ cpu1_alert0: cpu-alert-0 {
+ temperature = <70000>;
+@@ -128,7 +128,7 @@
+ };
+ };
+ cpu2_thermal: cpu2-thermal {
+- thermal-sensors = <&tmu_cpu2 0>;
++ thermal-sensors = <&tmu_cpu2>;
+ trips {
+ cpu2_alert0: cpu-alert-0 {
+ temperature = <70000>;
+@@ -172,7 +172,7 @@
+ };
+ };
+ cpu3_thermal: cpu3-thermal {
+- thermal-sensors = <&tmu_cpu3 0>;
++ thermal-sensors = <&tmu_cpu3>;
+ trips {
+ cpu3_alert0: cpu-alert-0 {
+ temperature = <70000>;
+@@ -216,7 +216,7 @@
+ };
+ };
+ gpu_thermal: gpu-thermal {
+- thermal-sensors = <&tmu_gpu 0>;
++ thermal-sensors = <&tmu_gpu>;
+ trips {
+ gpu_alert0: gpu-alert-0 {
+ temperature = <70000>;
--- /dev/null
+From 9372eca505e7a19934d750b4b4c89a3652738e66 Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Thu, 9 Feb 2023 11:58:39 +0100
+Subject: ARM: dts: exynos: correct TMU phandle in Odroid XU
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit 9372eca505e7a19934d750b4b4c89a3652738e66 upstream.
+
+TMU node uses 0 as thermal-sensor-cells, thus thermal zone referencing
+it must not have an argument to phandle. Since thermal-sensors property
+is already defined in included exynosi5410.dtsi, drop it from
+exynos5410-odroidxu.dts to fix the error and remoev redundancy.
+
+Fixes: 88644b4c750b ("ARM: dts: exynos: Configure PWM, usb3503, PMIC and thermal on Odroid XU board")
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20230209105841.779596-4-krzysztof.kozlowski@linaro.org
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm/boot/dts/exynos5410-odroidxu.dts | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/arch/arm/boot/dts/exynos5410-odroidxu.dts
++++ b/arch/arm/boot/dts/exynos5410-odroidxu.dts
+@@ -116,7 +116,6 @@
+ };
+
+ &cpu0_thermal {
+- thermal-sensors = <&tmu_cpu0 0>;
+ polling-delay-passive = <0>;
+ polling-delay = <0>;
+
--- /dev/null
+From a3583e92d188ec6c58c7f603ac5e72dd8a11c21a Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Date: Thu, 9 Feb 2023 11:58:41 +0100
+Subject: ARM: dts: exynos: correct TMU phandle in Odroid XU3 family
+
+From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+commit a3583e92d188ec6c58c7f603ac5e72dd8a11c21a upstream.
+
+TMU node uses 0 as thermal-sensor-cells, thus thermal zone referencing
+it must not have an argument to phandle. This was not critical before,
+but since rework of thermal Devicetree initialization in the
+commit 3fd6d6e2b4e8 ("thermal/of: Rework the thermal device tree
+initialization"), this leads to errors registering thermal zones other
+than first one:
+
+ thermal_sys: cpu0-thermal: Failed to read thermal-sensors cells: -2
+ thermal_sys: Failed to find thermal zone for tmu id=0
+ exynos-tmu 10064000.tmu: Failed to register sensor: -2
+ exynos-tmu: probe of 10064000.tmu failed with error -2
+
+Fixes: f1722d7dd8b8 ("ARM: dts: Define default thermal-zones for exynos5422")
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20230209105841.779596-6-krzysztof.kozlowski@linaro.org
+Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
++++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+@@ -50,7 +50,7 @@
+
+ thermal-zones {
+ cpu0_thermal: cpu0-thermal {
+- thermal-sensors = <&tmu_cpu0 0>;
++ thermal-sensors = <&tmu_cpu0>;
+ polling-delay-passive = <250>;
+ polling-delay = <0>;
+ trips {
+@@ -139,7 +139,7 @@
+ };
+ };
+ cpu1_thermal: cpu1-thermal {
+- thermal-sensors = <&tmu_cpu1 0>;
++ thermal-sensors = <&tmu_cpu1>;
+ polling-delay-passive = <250>;
+ polling-delay = <0>;
+ trips {
+@@ -212,7 +212,7 @@
+ };
+ };
+ cpu2_thermal: cpu2-thermal {
+- thermal-sensors = <&tmu_cpu2 0>;
++ thermal-sensors = <&tmu_cpu2>;
+ polling-delay-passive = <250>;
+ polling-delay = <0>;
+ trips {
+@@ -285,7 +285,7 @@
+ };
+ };
+ cpu3_thermal: cpu3-thermal {
+- thermal-sensors = <&tmu_cpu3 0>;
++ thermal-sensors = <&tmu_cpu3>;
+ polling-delay-passive = <250>;
+ polling-delay = <0>;
+ trips {
+@@ -358,7 +358,7 @@
+ };
+ };
+ gpu_thermal: gpu-thermal {
+- thermal-sensors = <&tmu_gpu 0>;
++ thermal-sensors = <&tmu_gpu>;
+ polling-delay-passive = <250>;
+ polling-delay = <0>;
+ trips {
--- /dev/null
+From e686c32590f40bffc45f105c04c836ffad3e531a Mon Sep 17 00:00:00 2001
+From: Dan Williams <dan.j.williams@intel.com>
+Date: Thu, 16 Feb 2023 00:36:02 -0800
+Subject: dax/kmem: Fix leak of memory-hotplug resources
+
+From: Dan Williams <dan.j.williams@intel.com>
+
+commit e686c32590f40bffc45f105c04c836ffad3e531a upstream.
+
+While experimenting with CXL region removal the following corruption of
+/proc/iomem appeared.
+
+Before:
+f010000000-f04fffffff : CXL Window 0
+ f010000000-f02fffffff : region4
+ f010000000-f02fffffff : dax4.0
+ f010000000-f02fffffff : System RAM (kmem)
+
+After (modprobe -r cxl_test):
+f010000000-f02fffffff : **redacted binary garbage**
+ f010000000-f02fffffff : System RAM (kmem)
+
+...and testing further the same is visible with persistent memory
+assigned to kmem:
+
+Before:
+480000000-243fffffff : Persistent Memory
+ 480000000-57e1fffff : namespace3.0
+ 580000000-243fffffff : dax3.0
+ 580000000-243fffffff : System RAM (kmem)
+
+After (ndctl disable-region all):
+480000000-243fffffff : Persistent Memory
+ 580000000-243fffffff : ***redacted binary garbage***
+ 580000000-243fffffff : System RAM (kmem)
+
+The corrupted data is from a use-after-free of the "dax4.0" and "dax3.0"
+resources, and it also shows that the "System RAM (kmem)" resource is
+not being removed. The bug does not appear after "modprobe -r kmem", it
+requires the parent of "dax4.0" and "dax3.0" to be removed which
+re-parents the leaked "System RAM (kmem)" instances. Those in turn
+reference the freed resource as a parent.
+
+First up for the fix is release_mem_region_adjustable() needs to
+reliably delete the resource inserted by add_memory_driver_managed().
+That is thwarted by a check for IORESOURCE_SYSRAM that predates the
+dax/kmem driver, from commit:
+
+65c78784135f ("kernel, resource: check for IORESOURCE_SYSRAM in release_mem_region_adjustable")
+
+That appears to be working around the behavior of HMM's
+"MEMORY_DEVICE_PUBLIC" facility that has since been deleted. With that
+check removed the "System RAM (kmem)" resource gets removed, but
+corruption still occurs occasionally because the "dax" resource is not
+reliably removed.
+
+The dax range information is freed before the device is unregistered, so
+the driver can not reliably recall (another use after free) what it is
+meant to release. Lastly if that use after free got lucky, the driver
+was covering up the leak of "System RAM (kmem)" due to its use of
+release_resource() which detaches, but does not free, child resources.
+The switch to remove_resource() forces remove_memory() to be responsible
+for the deletion of the resource added by add_memory_driver_managed().
+
+Fixes: c2f3011ee697 ("device-dax: add an allocation interface for device-dax instances")
+Cc: <stable@vger.kernel.org>
+Cc: Oscar Salvador <osalvador@suse.de>
+Cc: David Hildenbrand <david@redhat.com>
+Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
+Reviewed-by: Vishal Verma <vishal.l.verma@intel.com>
+Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com>
+Reviewed-by: Dave Jiang <dave.jiang@intel.com>
+Link: https://lore.kernel.org/r/167653656244.3147810.5705900882794040229.stgit@dwillia2-xfh.jf.intel.com
+Signed-off-by: Dan Williams <dan.j.williams@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/dax/bus.c | 2 +-
+ drivers/dax/kmem.c | 4 ++--
+ kernel/resource.c | 14 --------------
+ 3 files changed, 3 insertions(+), 17 deletions(-)
+
+--- a/drivers/dax/bus.c
++++ b/drivers/dax/bus.c
+@@ -398,8 +398,8 @@ static void unregister_dev_dax(void *dev
+ dev_dbg(dev, "%s\n", __func__);
+
+ kill_dev_dax(dev_dax);
+- free_dev_dax_ranges(dev_dax);
+ device_del(dev);
++ free_dev_dax_ranges(dev_dax);
+ put_device(dev);
+ }
+
+--- a/drivers/dax/kmem.c
++++ b/drivers/dax/kmem.c
+@@ -114,7 +114,7 @@ static int dev_dax_kmem_probe(struct dev
+ if (rc) {
+ dev_warn(dev, "mapping%d: %#llx-%#llx memory add failed\n",
+ i, range.start, range.end);
+- release_resource(res);
++ remove_resource(res);
+ kfree(res);
+ data->res[i] = NULL;
+ if (mapped)
+@@ -159,7 +159,7 @@ static int dev_dax_kmem_remove(struct de
+ rc = remove_memory(dev_dax->target_node, range.start,
+ range_len(&range));
+ if (rc == 0) {
+- release_resource(data->res[i]);
++ remove_resource(data->res[i]);
+ kfree(data->res[i]);
+ data->res[i] = NULL;
+ success++;
+--- a/kernel/resource.c
++++ b/kernel/resource.c
+@@ -1293,20 +1293,6 @@ retry:
+ continue;
+ }
+
+- /*
+- * All memory regions added from memory-hotplug path have the
+- * flag IORESOURCE_SYSTEM_RAM. If the resource does not have
+- * this flag, we know that we are dealing with a resource coming
+- * from HMM/devm. HMM/devm use another mechanism to add/release
+- * a resource. This goes via devm_request_mem_region and
+- * devm_release_mem_region.
+- * HMM/devm take care to release their resources when they want,
+- * so if we are dealing with them, let us just back off here.
+- */
+- if (!(res->flags & IORESOURCE_SYSRAM)) {
+- break;
+- }
+-
+ if (!(res->flags & IORESOURCE_MEM))
+ break;
+
--- /dev/null
+From 0ca44fcef241768fd25ee763b3d203b9852f269b Mon Sep 17 00:00:00 2001
+From: Pingfan Liu <piliu@redhat.com>
+Date: Wed, 15 Feb 2023 19:23:40 +0800
+Subject: dm: add cond_resched() to dm_wq_work()
+
+From: Pingfan Liu <piliu@redhat.com>
+
+commit 0ca44fcef241768fd25ee763b3d203b9852f269b upstream.
+
+Otherwise the while() loop in dm_wq_work() can result in a "dead
+loop" on systems that have preemption disabled. This is particularly
+problematic on single cpu systems.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Pingfan Liu <piliu@redhat.com>
+Acked-by: Ming Lei <ming.lei@redhat.com>
+Signed-off-by: Mike Snitzer <snitzer@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/md/dm.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/md/dm.c
++++ b/drivers/md/dm.c
+@@ -2393,6 +2393,7 @@ static void dm_wq_work(struct work_struc
+ break;
+
+ submit_bio_noacct(bio);
++ cond_resched();
+ }
+ }
+
--- /dev/null
+From f50714b57aecb6b3dc81d578e295f86d9c73f078 Mon Sep 17 00:00:00 2001
+From: Mikulas Patocka <mpatocka@redhat.com>
+Date: Sun, 22 Jan 2023 14:02:57 -0500
+Subject: dm flakey: don't corrupt the zero page
+
+From: Mikulas Patocka <mpatocka@redhat.com>
+
+commit f50714b57aecb6b3dc81d578e295f86d9c73f078 upstream.
+
+When we need to zero some range on a block device, the function
+__blkdev_issue_zero_pages submits a write bio with the bio vector pointing
+to the zero page. If we use dm-flakey with corrupt bio writes option, it
+will corrupt the content of the zero page which results in crashes of
+various userspace programs. Glibc assumes that memory returned by mmap is
+zeroed and it uses it for calloc implementation; if the newly mapped
+memory is not zeroed, calloc will return non-zeroed memory.
+
+Fix this bug by testing if the page is equal to ZERO_PAGE(0) and
+avoiding the corruption in this case.
+
+Cc: stable@vger.kernel.org
+Fixes: a00f5276e266 ("dm flakey: Properly corrupt multi-page bios.")
+Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
+Reviewed-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
+Signed-off-by: Mike Snitzer <snitzer@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/md/dm-flakey.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/drivers/md/dm-flakey.c
++++ b/drivers/md/dm-flakey.c
+@@ -301,8 +301,11 @@ static void corrupt_bio_data(struct bio
+ */
+ bio_for_each_segment(bvec, bio, iter) {
+ if (bio_iter_len(bio, iter) > corrupt_bio_byte) {
+- char *segment = (page_address(bio_iter_page(bio, iter))
+- + bio_iter_offset(bio, iter));
++ char *segment;
++ struct page *page = bio_iter_page(bio, iter);
++ if (unlikely(page == ZERO_PAGE(0)))
++ break;
++ segment = (page_address(page) + bio_iter_offset(bio, iter));
+ segment[corrupt_bio_byte] = fc->corrupt_bio_value;
+ DMDEBUG("Corrupting data bio=%p by writing %u to byte %u "
+ "(rw=%c bi_opf=%u bi_sector=%llu size=%u)\n",
--- /dev/null
+From 8eb29c4fbf9661e6bd4dd86197a37ffe0ecc9d50 Mon Sep 17 00:00:00 2001
+From: Mikulas Patocka <mpatocka@redhat.com>
+Date: Sun, 22 Jan 2023 14:03:31 -0500
+Subject: dm flakey: fix a bug with 32-bit highmem systems
+
+From: Mikulas Patocka <mpatocka@redhat.com>
+
+commit 8eb29c4fbf9661e6bd4dd86197a37ffe0ecc9d50 upstream.
+
+The function page_address does not work with 32-bit systems with high
+memory. Use bvec_kmap_local/kunmap_local instead.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
+Reviewed-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
+Signed-off-by: Mike Snitzer <snitzer@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/md/dm-flakey.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/md/dm-flakey.c
++++ b/drivers/md/dm-flakey.c
+@@ -305,8 +305,9 @@ static void corrupt_bio_data(struct bio
+ struct page *page = bio_iter_page(bio, iter);
+ if (unlikely(page == ZERO_PAGE(0)))
+ break;
+- segment = (page_address(page) + bio_iter_offset(bio, iter));
++ segment = bvec_kmap_local(&bvec);
+ segment[corrupt_bio_byte] = fc->corrupt_bio_value;
++ kunmap_local(segment);
+ DMDEBUG("Corrupting data bio=%p by writing %u to byte %u "
+ "(rw=%c bi_opf=%u bi_sector=%llu size=%u)\n",
+ bio, fc->corrupt_bio_value, fc->corrupt_bio_byte,
--- /dev/null
+From aa56b9b75996ff4c76a0a4181c2fa0206c3d91cc Mon Sep 17 00:00:00 2001
+From: Mikulas Patocka <mpatocka@redhat.com>
+Date: Sun, 22 Jan 2023 14:03:56 -0500
+Subject: dm flakey: fix logic when corrupting a bio
+
+From: Mikulas Patocka <mpatocka@redhat.com>
+
+commit aa56b9b75996ff4c76a0a4181c2fa0206c3d91cc upstream.
+
+If "corrupt_bio_byte" is set to corrupt reads and corrupt_bio_flags is
+used, dm-flakey would erroneously return all writes as errors. Likewise,
+if "corrupt_bio_byte" is set to corrupt writes, dm-flakey would return
+errors for all reads.
+
+Fix the logic so that if fc->corrupt_bio_byte is non-zero, dm-flakey
+will not abort reads on writes with an error.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
+Reviewed-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
+Signed-off-by: Mike Snitzer <snitzer@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/md/dm-flakey.c | 23 +++++++++++++----------
+ 1 file changed, 13 insertions(+), 10 deletions(-)
+
+--- a/drivers/md/dm-flakey.c
++++ b/drivers/md/dm-flakey.c
+@@ -359,9 +359,11 @@ static int flakey_map(struct dm_target *
+ /*
+ * Corrupt matching writes.
+ */
+- if (fc->corrupt_bio_byte && (fc->corrupt_bio_rw == WRITE)) {
+- if (all_corrupt_bio_flags_match(bio, fc))
+- corrupt_bio_data(bio, fc);
++ if (fc->corrupt_bio_byte) {
++ if (fc->corrupt_bio_rw == WRITE) {
++ if (all_corrupt_bio_flags_match(bio, fc))
++ corrupt_bio_data(bio, fc);
++ }
+ goto map_bio;
+ }
+
+@@ -387,13 +389,14 @@ static int flakey_end_io(struct dm_targe
+ return DM_ENDIO_DONE;
+
+ if (!*error && pb->bio_submitted && (bio_data_dir(bio) == READ)) {
+- if (fc->corrupt_bio_byte && (fc->corrupt_bio_rw == READ) &&
+- all_corrupt_bio_flags_match(bio, fc)) {
+- /*
+- * Corrupt successful matching READs while in down state.
+- */
+- corrupt_bio_data(bio, fc);
+-
++ if (fc->corrupt_bio_byte) {
++ if ((fc->corrupt_bio_rw == READ) &&
++ all_corrupt_bio_flags_match(bio, fc)) {
++ /*
++ * Corrupt successful matching READs while in down state.
++ */
++ corrupt_bio_data(bio, fc);
++ }
+ } else if (!test_bit(DROP_WRITES, &fc->flags) &&
+ !test_bit(ERROR_WRITES, &fc->flags)) {
+ /*
--- /dev/null
+From f2e4cca2f670c8e52fbb551a295f2afc9aa2bd72 Mon Sep 17 00:00:00 2001
+From: John Ogness <john.ogness@linutronix.de>
+Date: Thu, 29 Dec 2022 14:49:39 +0106
+Subject: docs: gdbmacros: print newest record
+
+From: John Ogness <john.ogness@linutronix.de>
+
+commit f2e4cca2f670c8e52fbb551a295f2afc9aa2bd72 upstream.
+
+@head_id points to the newest record, but the printing loop
+exits when it increments to this value (before printing).
+
+Exit the printing loop after the newest record has been printed.
+
+The python-based function in scripts/gdb/linux/dmesg.py already
+does this correctly.
+
+Fixes: e60768311af8 ("scripts/gdb: update for lockless printk ringbuffer")
+Cc: stable@vger.kernel.org
+Signed-off-by: John Ogness <john.ogness@linutronix.de>
+Reviewed-by: Petr Mladek <pmladek@suse.com>
+Signed-off-by: Petr Mladek <pmladek@suse.com>
+Link: https://lore.kernel.org/r/20221229134339.197627-1-john.ogness@linutronix.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ Documentation/admin-guide/kdump/gdbmacros.txt | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/Documentation/admin-guide/kdump/gdbmacros.txt
++++ b/Documentation/admin-guide/kdump/gdbmacros.txt
+@@ -312,10 +312,10 @@ define dmesg
+ set var $prev_flags = $info->flags
+ end
+
+- set var $id = ($id + 1) & $id_mask
+ if ($id == $end_id)
+ loop_break
+ end
++ set var $id = ($id + 1) & $id_mask
+ end
+ end
+ document dmesg
--- /dev/null
+From 0813299c586b175d7edb25f56412c54b812d0379 Mon Sep 17 00:00:00 2001
+From: Jan Kara <jack@suse.cz>
+Date: Thu, 26 Jan 2023 12:22:21 +0100
+Subject: ext4: Fix possible corruption when moving a directory
+
+From: Jan Kara <jack@suse.cz>
+
+commit 0813299c586b175d7edb25f56412c54b812d0379 upstream.
+
+When we are renaming a directory to a different directory, we need to
+update '..' entry in the moved directory. However nothing prevents moved
+directory from being modified and even converted from the inline format
+to the normal format. When such race happens the rename code gets
+confused and we crash. Fix the problem by locking the moved directory.
+
+CC: stable@vger.kernel.org
+Fixes: 32f7f22c0b52 ("ext4: let ext4_rename handle inline dir")
+Signed-off-by: Jan Kara <jack@suse.cz>
+Link: https://lore.kernel.org/r/20230126112221.11866-1-jack@suse.cz
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ext4/namei.c | 11 ++++++++++-
+ 1 file changed, 10 insertions(+), 1 deletion(-)
+
+--- a/fs/ext4/namei.c
++++ b/fs/ext4/namei.c
+@@ -3922,9 +3922,16 @@ static int ext4_rename(struct inode *old
+ if (new.dir != old.dir && EXT4_DIR_LINK_MAX(new.dir))
+ goto end_rename;
+ }
++ /*
++ * We need to protect against old.inode directory getting
++ * converted from inline directory format into a normal one.
++ */
++ inode_lock_nested(old.inode, I_MUTEX_NONDIR2);
+ retval = ext4_rename_dir_prepare(handle, &old);
+- if (retval)
++ if (retval) {
++ inode_unlock(old.inode);
+ goto end_rename;
++ }
+ }
+ /*
+ * If we're renaming a file within an inline_data dir and adding or
+@@ -4049,6 +4056,8 @@ end_rename:
+ } else {
+ ext4_journal_stop(handle);
+ }
++ if (old.dir_bh)
++ inode_unlock(old.inode);
+ release_bh:
+ brelse(old.dir_bh);
+ brelse(old.bh);
--- /dev/null
+From 1e9d62d252812575ded7c620d8fc67c32ff06c16 Mon Sep 17 00:00:00 2001
+From: Jun Nie <jun.nie@linaro.org>
+Date: Tue, 3 Jan 2023 09:45:16 +0800
+Subject: ext4: optimize ea_inode block expansion
+
+From: Jun Nie <jun.nie@linaro.org>
+
+commit 1e9d62d252812575ded7c620d8fc67c32ff06c16 upstream.
+
+Copy ea data from inode entry when expanding ea block if possible.
+Then remove the ea entry if expansion success. Thus memcpy to a
+temporary buffer may be avoided.
+
+If the expansion fails, we do not need to recovery the removed ea
+entry neither in this way.
+
+Reported-by: syzbot+2dacb8f015bf1420155f@syzkaller.appspotmail.com
+Link: https://syzkaller.appspot.com/bug?id=3613786cb88c93aa1c6a279b1df6a7b201347d08
+Link: https://lore.kernel.org/r/20230103014517.495275-2-jun.nie@linaro.org
+Cc: stable@kernel.org
+Signed-off-by: Jun Nie <jun.nie@linaro.org>
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ext4/xattr.c | 28 +++++++++++++++++-----------
+ 1 file changed, 17 insertions(+), 11 deletions(-)
+
+--- a/fs/ext4/xattr.c
++++ b/fs/ext4/xattr.c
+@@ -2564,9 +2564,8 @@ static int ext4_xattr_move_to_block(hand
+
+ is = kzalloc(sizeof(struct ext4_xattr_ibody_find), GFP_NOFS);
+ bs = kzalloc(sizeof(struct ext4_xattr_block_find), GFP_NOFS);
+- buffer = kvmalloc(value_size, GFP_NOFS);
+ b_entry_name = kmalloc(entry->e_name_len + 1, GFP_NOFS);
+- if (!is || !bs || !buffer || !b_entry_name) {
++ if (!is || !bs || !b_entry_name) {
+ error = -ENOMEM;
+ goto out;
+ }
+@@ -2578,12 +2577,18 @@ static int ext4_xattr_move_to_block(hand
+
+ /* Save the entry name and the entry value */
+ if (entry->e_value_inum) {
++ buffer = kvmalloc(value_size, GFP_NOFS);
++ if (!buffer) {
++ error = -ENOMEM;
++ goto out;
++ }
++
+ error = ext4_xattr_inode_get(inode, entry, buffer, value_size);
+ if (error)
+ goto out;
+ } else {
+ size_t value_offs = le16_to_cpu(entry->e_value_offs);
+- memcpy(buffer, (void *)IFIRST(header) + value_offs, value_size);
++ buffer = (void *)IFIRST(header) + value_offs;
+ }
+
+ memcpy(b_entry_name, entry->e_name, entry->e_name_len);
+@@ -2598,25 +2603,26 @@ static int ext4_xattr_move_to_block(hand
+ if (error)
+ goto out;
+
+- /* Remove the chosen entry from the inode */
+- error = ext4_xattr_ibody_set(handle, inode, &i, is);
+- if (error)
+- goto out;
+-
+ i.value = buffer;
+ i.value_len = value_size;
+ error = ext4_xattr_block_find(inode, &i, bs);
+ if (error)
+ goto out;
+
+- /* Add entry which was removed from the inode into the block */
++ /* Move ea entry from the inode into the block */
+ error = ext4_xattr_block_set(handle, inode, &i, bs);
+ if (error)
+ goto out;
+- error = 0;
++
++ /* Remove the chosen entry from the inode */
++ i.value = NULL;
++ i.value_len = 0;
++ error = ext4_xattr_ibody_set(handle, inode, &i, is);
++
+ out:
+ kfree(b_entry_name);
+- kvfree(buffer);
++ if (entry->e_value_inum && buffer)
++ kvfree(buffer);
+ if (is)
+ brelse(is->iloc.bh);
+ if (bs)
--- /dev/null
+From f31173c19901a96bb2ebf6bcfec8a08df7095c91 Mon Sep 17 00:00:00 2001
+From: Jun Nie <jun.nie@linaro.org>
+Date: Tue, 3 Jan 2023 09:45:17 +0800
+Subject: ext4: refuse to create ea block when umounted
+
+From: Jun Nie <jun.nie@linaro.org>
+
+commit f31173c19901a96bb2ebf6bcfec8a08df7095c91 upstream.
+
+The ea block expansion need to access s_root while it is
+already set as NULL when umount is triggered. Refuse this
+request to avoid panic.
+
+Reported-by: syzbot+2dacb8f015bf1420155f@syzkaller.appspotmail.com
+Link: https://syzkaller.appspot.com/bug?id=3613786cb88c93aa1c6a279b1df6a7b201347d08
+Link: https://lore.kernel.org/r/20230103014517.495275-3-jun.nie@linaro.org
+Cc: stable@kernel.org
+Signed-off-by: Jun Nie <jun.nie@linaro.org>
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ext4/xattr.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/fs/ext4/xattr.c
++++ b/fs/ext4/xattr.c
+@@ -1415,6 +1415,13 @@ static struct inode *ext4_xattr_inode_cr
+ uid_t owner[2] = { i_uid_read(inode), i_gid_read(inode) };
+ int err;
+
++ if (inode->i_sb->s_root == NULL) {
++ ext4_warning(inode->i_sb,
++ "refuse to create EA inode when umounting");
++ WARN_ON(1);
++ return ERR_PTR(-EINVAL);
++ }
++
+ /*
+ * Let the next inode be the goal, so we try and allocate the EA inode
+ * in the same group, or nearby one.
--- /dev/null
+From e6b9bd7290d334451ce054e98e752abc055e0034 Mon Sep 17 00:00:00 2001
+From: Zhihao Cheng <chengzhihao1@huawei.com>
+Date: Tue, 10 Jan 2023 09:53:27 +0800
+Subject: jbd2: fix data missing when reusing bh which is ready to be checkpointed
+
+From: Zhihao Cheng <chengzhihao1@huawei.com>
+
+commit e6b9bd7290d334451ce054e98e752abc055e0034 upstream.
+
+Following process will make data lost and could lead to a filesystem
+corrupted problem:
+
+1. jh(bh) is inserted into T1->t_checkpoint_list, bh is dirty, and
+ jh->b_transaction = NULL
+2. T1 is added into journal->j_checkpoint_transactions.
+3. Get bh prepare to write while doing checkpoing:
+ PA PB
+ do_get_write_access jbd2_log_do_checkpoint
+ spin_lock(&jh->b_state_lock)
+ if (buffer_dirty(bh))
+ clear_buffer_dirty(bh) // clear buffer dirty
+ set_buffer_jbddirty(bh)
+ transaction =
+ journal->j_checkpoint_transactions
+ jh = transaction->t_checkpoint_list
+ if (!buffer_dirty(bh))
+ __jbd2_journal_remove_checkpoint(jh)
+ // bh won't be flushed
+ jbd2_cleanup_journal_tail
+ __jbd2_journal_file_buffer(jh, transaction, BJ_Reserved)
+4. Aborting journal/Power-cut before writing latest bh on journal area.
+
+In this way we get a corrupted filesystem with bh's data lost.
+
+Fix it by moving the clearing of buffer_dirty bit just before the call
+to __jbd2_journal_file_buffer(), both bit clearing and jh->b_transaction
+assignment are under journal->j_list_lock locked, so that
+jbd2_log_do_checkpoint() will wait until jh's new transaction fininshed
+even bh is currently not dirty. And journal_shrink_one_cp_list() won't
+remove jh from checkpoint list if the buffer head is reused in
+do_get_write_access().
+
+Fetch a reproducer in [Link].
+
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=216898
+Cc: <stable@kernel.org>
+Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
+Signed-off-by: zhanchengbin <zhanchengbin1@huawei.com>
+Suggested-by: Jan Kara <jack@suse.cz>
+Reviewed-by: Jan Kara <jack@suse.cz>
+Link: https://lore.kernel.org/r/20230110015327.1181863-1-chengzhihao1@huawei.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/jbd2/transaction.c | 50 +++++++++++++++++++++++++++++---------------------
+ 1 file changed, 29 insertions(+), 21 deletions(-)
+
+--- a/fs/jbd2/transaction.c
++++ b/fs/jbd2/transaction.c
+@@ -984,36 +984,28 @@ repeat:
+ * ie. locked but not dirty) or tune2fs (which may actually have
+ * the buffer dirtied, ugh.) */
+
+- if (buffer_dirty(bh)) {
++ if (buffer_dirty(bh) && jh->b_transaction) {
++ warn_dirty_buffer(bh);
+ /*
+- * First question: is this buffer already part of the current
+- * transaction or the existing committing transaction?
+- */
+- if (jh->b_transaction) {
+- J_ASSERT_JH(jh,
+- jh->b_transaction == transaction ||
+- jh->b_transaction ==
+- journal->j_committing_transaction);
+- if (jh->b_next_transaction)
+- J_ASSERT_JH(jh, jh->b_next_transaction ==
+- transaction);
+- warn_dirty_buffer(bh);
+- }
+- /*
+- * In any case we need to clean the dirty flag and we must
+- * do it under the buffer lock to be sure we don't race
+- * with running write-out.
++ * We need to clean the dirty flag and we must do it under the
++ * buffer lock to be sure we don't race with running write-out.
+ */
+ JBUFFER_TRACE(jh, "Journalling dirty buffer");
+ clear_buffer_dirty(bh);
++ /*
++ * The buffer is going to be added to BJ_Reserved list now and
++ * nothing guarantees jbd2_journal_dirty_metadata() will be
++ * ever called for it. So we need to set jbddirty bit here to
++ * make sure the buffer is dirtied and written out when the
++ * journaling machinery is done with it.
++ */
+ set_buffer_jbddirty(bh);
+ }
+
+- unlock_buffer(bh);
+-
+ error = -EROFS;
+ if (is_handle_aborted(handle)) {
+ spin_unlock(&jh->b_state_lock);
++ unlock_buffer(bh);
+ goto out;
+ }
+ error = 0;
+@@ -1023,8 +1015,10 @@ repeat:
+ * b_next_transaction points to it
+ */
+ if (jh->b_transaction == transaction ||
+- jh->b_next_transaction == transaction)
++ jh->b_next_transaction == transaction) {
++ unlock_buffer(bh);
+ goto done;
++ }
+
+ /*
+ * this is the first time this transaction is touching this buffer,
+@@ -1048,10 +1042,24 @@ repeat:
+ */
+ smp_wmb();
+ spin_lock(&journal->j_list_lock);
++ if (test_clear_buffer_dirty(bh)) {
++ /*
++ * Execute buffer dirty clearing and jh->b_transaction
++ * assignment under journal->j_list_lock locked to
++ * prevent bh being removed from checkpoint list if
++ * the buffer is in an intermediate state (not dirty
++ * and jh->b_transaction is NULL).
++ */
++ JBUFFER_TRACE(jh, "Journalling dirty buffer");
++ set_buffer_jbddirty(bh);
++ }
+ __jbd2_journal_file_buffer(jh, transaction, BJ_Reserved);
+ spin_unlock(&journal->j_list_lock);
++ unlock_buffer(bh);
+ goto done;
+ }
++ unlock_buffer(bh);
++
+ /*
+ * If there is already a copy-out version of this buffer, then we don't
+ * need to make another one
--- /dev/null
+From 4e7d2a8f0b52abf23b1dc13b3d88bc0923383cd5 Mon Sep 17 00:00:00 2001
+From: Steven Rostedt <rostedt@goodmis.org>
+Date: Wed, 18 Jan 2023 16:37:25 -0500
+Subject: ktest.pl: Add RUN_TIMEOUT option with default unlimited
+
+From: Steven Rostedt <rostedt@goodmis.org>
+
+commit 4e7d2a8f0b52abf23b1dc13b3d88bc0923383cd5 upstream.
+
+There is a disconnect between the run_command function and the
+wait_for_input. The wait_for_input has a default timeout of 2 minutes. But
+if that happens, the run_command loop will exit out to the waitpid() of
+the executing command. This fails in that it no longer monitors the
+command, and also, the ssh to the test box can hang when its finished, as
+it's waiting for the pipe it's writing to to flush, but the loop that
+reads that pipe has already exited, leaving the command stuck, and the
+test hangs.
+
+Instead, make the default "wait_for_input" of the run_command infinite,
+and allow the user to override it if they want with a default timeout
+option "RUN_TIMEOUT".
+
+But this fixes the hang that happens when the pipe is full and the ssh
+session never exits.
+
+Cc: stable@vger.kernel.org
+Fixes: 6e98d1b4415fe ("ktest: Add timeout to ssh command")
+Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ tools/testing/ktest/ktest.pl | 20 ++++++++++++++++----
+ tools/testing/ktest/sample.conf | 5 +++++
+ 2 files changed, 21 insertions(+), 4 deletions(-)
+
+--- a/tools/testing/ktest/ktest.pl
++++ b/tools/testing/ktest/ktest.pl
+@@ -178,6 +178,7 @@ my $store_failures;
+ my $store_successes;
+ my $test_name;
+ my $timeout;
++my $run_timeout;
+ my $connect_timeout;
+ my $config_bisect_exec;
+ my $booted_timeout;
+@@ -340,6 +341,7 @@ my %option_map = (
+ "STORE_SUCCESSES" => \$store_successes,
+ "TEST_NAME" => \$test_name,
+ "TIMEOUT" => \$timeout,
++ "RUN_TIMEOUT" => \$run_timeout,
+ "CONNECT_TIMEOUT" => \$connect_timeout,
+ "CONFIG_BISECT_EXEC" => \$config_bisect_exec,
+ "BOOTED_TIMEOUT" => \$booted_timeout,
+@@ -1800,6 +1802,14 @@ sub run_command {
+ $command =~ s/\$SSH_USER/$ssh_user/g;
+ $command =~ s/\$MACHINE/$machine/g;
+
++ if (!defined($timeout)) {
++ $timeout = $run_timeout;
++ }
++
++ if (!defined($timeout)) {
++ $timeout = -1; # tell wait_for_input to wait indefinitely
++ }
++
+ doprint("$command ... ");
+ $start_time = time;
+
+@@ -1826,13 +1836,10 @@ sub run_command {
+
+ while (1) {
+ my $fp = \*CMD;
+- if (defined($timeout)) {
+- doprint "timeout = $timeout\n";
+- }
+ my $line = wait_for_input($fp, $timeout);
+ if (!defined($line)) {
+ my $now = time;
+- if (defined($timeout) && (($now - $start_time) >= $timeout)) {
++ if ($timeout >= 0 && (($now - $start_time) >= $timeout)) {
+ doprint "Hit timeout of $timeout, killing process\n";
+ $hit_timeout = 1;
+ kill 9, $pid;
+@@ -2005,6 +2012,11 @@ sub wait_for_input
+ $time = $timeout;
+ }
+
++ if ($time < 0) {
++ # Negative number means wait indefinitely
++ undef $time;
++ }
++
+ $rin = '';
+ vec($rin, fileno($fp), 1) = 1;
+ vec($rin, fileno(\*STDIN), 1) = 1;
+--- a/tools/testing/ktest/sample.conf
++++ b/tools/testing/ktest/sample.conf
+@@ -809,6 +809,11 @@
+ # is issued instead of a reboot.
+ # CONNECT_TIMEOUT = 25
+
++# The timeout in seconds for how long to wait for any running command
++# to timeout. If not defined, it will let it go indefinitely.
++# (default undefined)
++#RUN_TIMEOUT = 600
++
+ # In between tests, a reboot of the box may occur, and this
+ # is the time to wait for the console after it stops producing
+ # output. Some machines may not produce a large lag on reboot
--- /dev/null
+From e8bf9b98d40dbdf4e39362e3b85a70c61da68cb7 Mon Sep 17 00:00:00 2001
+From: Steven Rostedt <rostedt@goodmis.org>
+Date: Wed, 18 Jan 2023 11:31:25 -0500
+Subject: ktest.pl: Fix missing "end_monitor" when machine check fails
+
+From: Steven Rostedt <rostedt@goodmis.org>
+
+commit e8bf9b98d40dbdf4e39362e3b85a70c61da68cb7 upstream.
+
+In the "reboot" command, it does a check of the machine to see if it is
+still alive with a simple "ssh echo" command. If it fails, it will assume
+that a normal "ssh reboot" is not possible and force a power cycle.
+
+In this case, the "start_monitor" is executed, but the "end_monitor" is
+not, and this causes the screen will not be given back to the console. That
+is, after the test, a "reset" command needs to be performed, as "echo" is
+turned off.
+
+Cc: stable@vger.kernel.org
+Fixes: 6474ace999edd ("ktest.pl: Powercycle the box on reboot if no connection can be made")
+Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ tools/testing/ktest/ktest.pl | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/tools/testing/ktest/ktest.pl
++++ b/tools/testing/ktest/ktest.pl
+@@ -1433,7 +1433,8 @@ sub reboot {
+
+ # Still need to wait for the reboot to finish
+ wait_for_monitor($time, $reboot_success_line);
+-
++ }
++ if ($powercycle || $time) {
+ end_monitor;
+ }
+ }
--- /dev/null
+From 83d29d439cd3ef23041570d55841f814af2ecac0 Mon Sep 17 00:00:00 2001
+From: Steven Rostedt <rostedt@goodmis.org>
+Date: Wed, 18 Jan 2023 16:32:13 -0500
+Subject: ktest.pl: Give back console on Ctrt^C on monitor
+
+From: Steven Rostedt <rostedt@goodmis.org>
+
+commit 83d29d439cd3ef23041570d55841f814af2ecac0 upstream.
+
+When monitoring the console output, the stdout is being redirected to do
+so. If Ctrl^C is hit during this mode, the stdout is not back to the
+console, the user does not see anything they type (no echo).
+
+Add "end_monitor" to the SIGINT interrupt handler to give back the console
+on Ctrl^C.
+
+Cc: stable@vger.kernel.org
+Fixes: 9f2cdcbbb90e7 ("ktest: Give console process a dedicated tty")
+Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ tools/testing/ktest/ktest.pl | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/tools/testing/ktest/ktest.pl
++++ b/tools/testing/ktest/ktest.pl
+@@ -4283,6 +4283,9 @@ sub send_email {
+ }
+
+ sub cancel_test {
++ if ($monitor_cnt) {
++ end_monitor;
++ }
+ if ($email_when_canceled) {
+ my $name = get_test_name;
+ send_email("KTEST: Your [$name] test was cancelled",
--- /dev/null
+From 909d3096ac99fa2289f9b8945a3eab2269947a0a Mon Sep 17 00:00:00 2001
+From: Sakari Ailus <sakari.ailus@linux.intel.com>
+Date: Wed, 21 Dec 2022 09:30:11 +0100
+Subject: media: ipu3-cio2: Fix PM runtime usage_count in driver unbind
+
+From: Sakari Ailus <sakari.ailus@linux.intel.com>
+
+commit 909d3096ac99fa2289f9b8945a3eab2269947a0a upstream.
+
+Get the PM runtime usage_count and forbid PM runtime at driver unbind. The
+opposite is being done in probe() already.
+
+Fixes: commit c2a6a07afe4a ("media: intel-ipu3: cio2: add new MIPI-CSI2 driver")
+Cc: stable@vger.kernel.org # for >= 4.16
+Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
+Reviewed-by: Bingbu Cao <bingbu.cao@intel.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/pci/intel/ipu3/ipu3-cio2.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/media/pci/intel/ipu3/ipu3-cio2.c
++++ b/drivers/media/pci/intel/ipu3/ipu3-cio2.c
+@@ -1831,6 +1831,9 @@ static void cio2_pci_remove(struct pci_d
+ v4l2_device_unregister(&cio2->v4l2_dev);
+ media_device_cleanup(&cio2->media_dev);
+ mutex_destroy(&cio2->lock);
++
++ pm_runtime_forbid(&pci_dev->dev);
++ pm_runtime_get_noresume(&pci_dev->dev);
+ }
+
+ static int __maybe_unused cio2_runtime_suspend(struct device *dev)
--- /dev/null
+From 85cc91e2ba4262a602ec65e2b76c4391a9e60d3d Mon Sep 17 00:00:00 2001
+From: Elvira Khabirova <lineprinter0@gmail.com>
+Date: Sat, 18 Feb 2023 23:43:59 +0100
+Subject: mips: fix syscall_get_nr
+
+From: Elvira Khabirova <lineprinter0@gmail.com>
+
+commit 85cc91e2ba4262a602ec65e2b76c4391a9e60d3d upstream.
+
+The implementation of syscall_get_nr on mips used to ignore the task
+argument and return the syscall number of the calling thread instead of
+the target thread.
+
+The bug was exposed to user space by commit 201766a20e30f ("ptrace: add
+PTRACE_GET_SYSCALL_INFO request") and detected by strace test suite.
+
+Link: https://github.com/strace/strace/issues/235
+Fixes: c2d9f1775731 ("MIPS: Fix syscall_get_nr for the syscall exit tracing.")
+Cc: <stable@vger.kernel.org> # v3.19+
+Co-developed-by: Dmitry V. Levin <ldv@strace.io>
+Signed-off-by: Dmitry V. Levin <ldv@strace.io>
+Signed-off-by: Elvira Khabirova <lineprinter0@gmail.com>
+Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/mips/include/asm/syscall.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/mips/include/asm/syscall.h
++++ b/arch/mips/include/asm/syscall.h
+@@ -38,7 +38,7 @@ static inline bool mips_syscall_is_indir
+ static inline long syscall_get_nr(struct task_struct *task,
+ struct pt_regs *regs)
+ {
+- return current_thread_info()->syscall;
++ return task_thread_info(task)->syscall;
+ }
+
+ static inline void mips_syscall_update_nr(struct task_struct *task,
--- /dev/null
+From da34a8484d162585e22ed8c1e4114aa2f60e3567 Mon Sep 17 00:00:00 2001
+From: Johannes Weiner <hannes@cmpxchg.org>
+Date: Wed, 7 Dec 2022 14:00:39 +0100
+Subject: mm: memcontrol: deprecate charge moving
+
+From: Johannes Weiner <hannes@cmpxchg.org>
+
+commit da34a8484d162585e22ed8c1e4114aa2f60e3567 upstream.
+
+Charge moving mode in cgroup1 allows memory to follow tasks as they
+migrate between cgroups. This is, and always has been, a questionable
+thing to do - for several reasons.
+
+First, it's expensive. Pages need to be identified, locked and isolated
+from various MM operations, and reassigned, one by one.
+
+Second, it's unreliable. Once pages are charged to a cgroup, there isn't
+always a clear owner task anymore. Cache isn't moved at all, for example.
+Mapped memory is moved - but if trylocking or isolating a page fails,
+it's arbitrarily left behind. Frequent moving between domains may leave a
+task's memory scattered all over the place.
+
+Third, it isn't really needed. Launcher tasks can kick off workload tasks
+directly in their target cgroup. Using dedicated per-workload groups
+allows fine-grained policy adjustments - no need to move tasks and their
+physical pages between control domains. The feature was never
+forward-ported to cgroup2, and it hasn't been missed.
+
+Despite it being a niche usecase, the maintenance overhead of supporting
+it is enormous. Because pages are moved while they are live and subject
+to various MM operations, the synchronization rules are complicated.
+There are lock_page_memcg() in MM and FS code, which non-cgroup people
+don't understand. In some cases we've been able to shift code and cgroup
+API calls around such that we can rely on native locking as much as
+possible. But that's fragile, and sometimes we need to hold MM locks for
+longer than we otherwise would (pte lock e.g.).
+
+Mark the feature deprecated. Hopefully we can remove it soon.
+
+And backport into -stable kernels so that people who develop against
+earlier kernels are warned about this deprecation as early as possible.
+
+[akpm@linux-foundation.org: fix memory.rst underlining]
+Link: https://lkml.kernel.org/r/Y5COd+qXwk/S+n8N@cmpxchg.org
+Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
+Acked-by: Shakeel Butt <shakeelb@google.com>
+Acked-by: Hugh Dickins <hughd@google.com>
+Acked-by: Michal Hocko <mhocko@suse.com>
+Cc: Muchun Song <songmuchun@bytedance.com>
+Cc: Roman Gushchin <roman.gushchin@linux.dev>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ Documentation/admin-guide/cgroup-v1/memory.rst | 13 +++++++++++--
+ mm/memcontrol.c | 4 ++++
+ 2 files changed, 15 insertions(+), 2 deletions(-)
+
+--- a/Documentation/admin-guide/cgroup-v1/memory.rst
++++ b/Documentation/admin-guide/cgroup-v1/memory.rst
+@@ -82,6 +82,8 @@ Brief summary of control files.
+ memory.swappiness set/show swappiness parameter of vmscan
+ (See sysctl's vm.swappiness)
+ memory.move_charge_at_immigrate set/show controls of moving charges
++ This knob is deprecated and shouldn't be
++ used.
+ memory.oom_control set/show oom controls.
+ memory.numa_stat show the number of memory usage per numa
+ node
+@@ -740,8 +742,15 @@ NOTE2:
+ It is recommended to set the soft limit always below the hard limit,
+ otherwise the hard limit will take precedence.
+
+-8. Move charges at task migration
+-=================================
++8. Move charges at task migration (DEPRECATED!)
++===============================================
++
++THIS IS DEPRECATED!
++
++It's expensive and unreliable! It's better practice to launch workload
++tasks directly from inside their target cgroup. Use dedicated workload
++cgroups to allow fine-grained policy adjustments without having to
++move physical pages between control domains.
+
+ Users can move charges associated with a task along with task migration, that
+ is, uncharge task's pages from the old cgroup and charge them to the new cgroup.
+--- a/mm/memcontrol.c
++++ b/mm/memcontrol.c
+@@ -3930,6 +3930,10 @@ static int mem_cgroup_move_charge_write(
+ {
+ struct mem_cgroup *memcg = mem_cgroup_from_css(css);
+
++ pr_warn_once("Cgroup memory moving (move_charge_at_immigrate) is deprecated. "
++ "Please report your usecase to linux-mm@kvack.org if you "
++ "depend on this functionality.\n");
++
+ if (val & ~MOVE_MASK)
+ return -EINVAL;
+
--- /dev/null
+From 81e506bec9be1eceaf5a2c654e28ba5176ef48d8 Mon Sep 17 00:00:00 2001
+From: Yin Fengwei <fengwei.yin@intel.com>
+Date: Fri, 23 Dec 2022 21:52:07 +0800
+Subject: mm/thp: check and bail out if page in deferred queue already
+
+From: Yin Fengwei <fengwei.yin@intel.com>
+
+commit 81e506bec9be1eceaf5a2c654e28ba5176ef48d8 upstream.
+
+Kernel build regression with LLVM was reported here:
+https://lore.kernel.org/all/Y1GCYXGtEVZbcv%2F5@dev-arch.thelio-3990X/ with
+commit f35b5d7d676e ("mm: align larger anonymous mappings on THP
+boundaries"). And the commit f35b5d7d676e was reverted.
+
+It turned out the regression is related with madvise(MADV_DONTNEED)
+was used by ld.lld. But with none PMD_SIZE aligned parameter len.
+trace-bpfcc captured:
+531607 531732 ld.lld do_madvise.part.0 start: 0x7feca9000000, len: 0x7fb000, behavior: 0x4
+531607 531793 ld.lld do_madvise.part.0 start: 0x7fec86a00000, len: 0x7fb000, behavior: 0x4
+
+If the underneath physical page is THP, the madvise(MADV_DONTNEED) can
+trigger split_queue_lock contention raised significantly. perf showed
+following data:
+ 14.85% 0.00% ld.lld [kernel.kallsyms] [k]
+ entry_SYSCALL_64_after_hwframe
+ 11.52%
+ entry_SYSCALL_64_after_hwframe
+ do_syscall_64
+ __x64_sys_madvise
+ do_madvise.part.0
+ zap_page_range
+ unmap_single_vma
+ unmap_page_range
+ page_remove_rmap
+ deferred_split_huge_page
+ __lock_text_start
+ native_queued_spin_lock_slowpath
+
+If THP can't be removed from rmap as whole THP, partial THP will be
+removed from rmap by removing sub-pages from rmap. Even the THP head page
+is added to deferred queue already, the split_queue_lock will be acquired
+and check whether the THP head page is in the queue already. Thus, the
+contention of split_queue_lock is raised.
+
+Before acquire split_queue_lock, check and bail out early if the THP
+head page is in the queue already. The checking without holding
+split_queue_lock could race with deferred_split_scan, but it doesn't
+impact the correctness here.
+
+Test result of building kernel with ld.lld:
+commit 7b5a0b664ebe (parent commit of f35b5d7d676e):
+time -f "\t%E real,\t%U user,\t%S sys" make LD=ld.lld -skj96 allmodconfig all
+ 6:07.99 real, 26367.77 user, 5063.35 sys
+
+commit f35b5d7d676e:
+time -f "\t%E real,\t%U user,\t%S sys" make LD=ld.lld -skj96 allmodconfig all
+ 7:22.15 real, 26235.03 user, 12504.55 sys
+
+commit f35b5d7d676e with the fixing patch:
+time -f "\t%E real,\t%U user,\t%S sys" make LD=ld.lld -skj96 allmodconfig all
+ 6:08.49 real, 26520.15 user, 5047.91 sys
+
+Link: https://lkml.kernel.org/r/20221223135207.2275317-1-fengwei.yin@intel.com
+Signed-off-by: Yin Fengwei <fengwei.yin@intel.com>
+Tested-by: Nathan Chancellor <nathan@kernel.org>
+Acked-by: David Rientjes <rientjes@google.com>
+Reviewed-by: "Huang, Ying" <ying.huang@intel.com>
+Cc: Feng Tang <feng.tang@intel.com>
+Cc: Matthew Wilcox <willy@infradead.org>
+Cc: Rik van Riel <riel@surriel.com>
+Cc: Xing Zhengjun <zhengjun.xing@linux.intel.com>
+Cc: Yang Shi <shy828301@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>
+---
+ mm/huge_memory.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/mm/huge_memory.c
++++ b/mm/huge_memory.c
+@@ -2803,6 +2803,9 @@ void deferred_split_huge_page(struct pag
+ if (PageSwapCache(page))
+ return;
+
++ if (!list_empty(page_deferred_list(page)))
++ return;
++
+ spin_lock_irqsave(&ds_queue->split_queue_lock, flags);
+ if (list_empty(page_deferred_list(page))) {
+ count_vm_event(THP_DEFERRED_SPLIT_PAGE);
--- /dev/null
+From f0f0cfdc3a024e21161714f2e05f0df3b84d42ad Mon Sep 17 00:00:00 2001
+From: Louis Rannou <lrannou@baylibre.com>
+Date: Fri, 3 Feb 2023 09:07:54 +0200
+Subject: mtd: spi-nor: Fix shift-out-of-bounds in spi_nor_set_erase_type
+
+From: Louis Rannou <lrannou@baylibre.com>
+
+commit f0f0cfdc3a024e21161714f2e05f0df3b84d42ad upstream.
+
+spi_nor_set_erase_type() was used either to set or to mask out an erase
+type. When we used it to mask out an erase type a shift-out-of-bounds
+was hit:
+UBSAN: shift-out-of-bounds in drivers/mtd/spi-nor/core.c:2237:24
+shift exponent 4294967295 is too large for 32-bit type 'int'
+
+The setting of the size_{shift, mask} and of the opcode are unnecessary
+when the erase size is zero, as throughout the code just the erase size
+is considered to determine whether an erase type is supported or not.
+Setting the opcode to 0xFF was wrong too as nobody guarantees that 0xFF
+is an unused opcode. Thus when masking out an erase type, just set the
+erase size to zero. This will fix the shift-out-of-bounds.
+
+Fixes: 5390a8df769e ("mtd: spi-nor: add support to non-uniform SFDP SPI NOR flash memories")
+Cc: stable@vger.kernel.org
+Reported-by: Alexander Stein <Alexander.Stein@tq-group.com>
+Signed-off-by: Louis Rannou <lrannou@baylibre.com>
+Tested-by: Alexander Stein <Alexander.Stein@tq-group.com>
+Link: https://lore.kernel.org/r/20230203070754.50677-1-tudor.ambarus@linaro.org
+[ta: refine changes, new commit message, fix compilation error]
+Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mtd/spi-nor/core.c | 9 +++++++++
+ drivers/mtd/spi-nor/core.h | 1 +
+ drivers/mtd/spi-nor/sfdp.c | 4 ++--
+ 3 files changed, 12 insertions(+), 2 deletions(-)
+
+--- a/drivers/mtd/spi-nor/core.c
++++ b/drivers/mtd/spi-nor/core.c
+@@ -2425,6 +2425,15 @@ void spi_nor_set_erase_type(struct spi_n
+ }
+
+ /**
++ * spi_nor_mask_erase_type() - mask out a SPI NOR erase type
++ * @erase: pointer to a structure that describes a SPI NOR erase type
++ */
++void spi_nor_mask_erase_type(struct spi_nor_erase_type *erase)
++{
++ erase->size = 0;
++}
++
++/**
+ * spi_nor_init_uniform_erase_map() - Initialize uniform erase map
+ * @map: the erase map of the SPI NOR
+ * @erase_mask: bitmask encoding erase types that can erase the entire
+--- a/drivers/mtd/spi-nor/core.h
++++ b/drivers/mtd/spi-nor/core.h
+@@ -424,6 +424,7 @@ void spi_nor_set_pp_settings(struct spi_
+
+ void spi_nor_set_erase_type(struct spi_nor_erase_type *erase, u32 size,
+ u8 opcode);
++void spi_nor_mask_erase_type(struct spi_nor_erase_type *erase);
+ struct spi_nor_erase_region *
+ spi_nor_region_next(struct spi_nor_erase_region *region);
+ void spi_nor_init_uniform_erase_map(struct spi_nor_erase_map *map,
+--- a/drivers/mtd/spi-nor/sfdp.c
++++ b/drivers/mtd/spi-nor/sfdp.c
+@@ -852,7 +852,7 @@ spi_nor_init_non_uniform_erase_map(struc
+ */
+ for (i = 0; i < SNOR_ERASE_TYPE_MAX; i++)
+ if (!(regions_erase_type & BIT(erase[i].idx)))
+- spi_nor_set_erase_type(&erase[i], 0, 0xFF);
++ spi_nor_mask_erase_type(&erase[i]);
+
+ return 0;
+ }
+@@ -1063,7 +1063,7 @@ static int spi_nor_parse_4bait(struct sp
+ erase_type[i].opcode = (dwords[1] >>
+ erase_type[i].idx * 8) & 0xFF;
+ else
+- spi_nor_set_erase_type(&erase_type[i], 0u, 0xFF);
++ spi_nor_mask_erase_type(&erase_type[i]);
+ }
+
+ /*
--- /dev/null
+From f7c4d9b133c7a04ca619355574e96b6abf209fba Mon Sep 17 00:00:00 2001
+From: Ilya Dryomov <idryomov@gmail.com>
+Date: Fri, 24 Feb 2023 18:48:54 +0100
+Subject: rbd: avoid use-after-free in do_rbd_add() when rbd_dev_create() fails
+
+From: Ilya Dryomov <idryomov@gmail.com>
+
+commit f7c4d9b133c7a04ca619355574e96b6abf209fba upstream.
+
+If getting an ID or setting up a work queue in rbd_dev_create() fails,
+use-after-free on rbd_dev->rbd_client, rbd_dev->spec and rbd_dev->opts
+is triggered in do_rbd_add(). The root cause is that the ownership of
+these structures is transfered to rbd_dev prematurely and they all end
+up getting freed when rbd_dev_create() calls rbd_dev_free() prior to
+returning to do_rbd_add().
+
+Found by Linux Verification Center (linuxtesting.org) with SVACE, an
+incomplete patch submitted by Natalia Petrova <n.petrova@fintech.ru>.
+
+Cc: stable@vger.kernel.org
+Fixes: 1643dfa4c2c8 ("rbd: introduce a per-device ordered workqueue")
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/block/rbd.c | 20 +++++++++-----------
+ 1 file changed, 9 insertions(+), 11 deletions(-)
+
+--- a/drivers/block/rbd.c
++++ b/drivers/block/rbd.c
+@@ -5369,8 +5369,7 @@ static void rbd_dev_release(struct devic
+ module_put(THIS_MODULE);
+ }
+
+-static struct rbd_device *__rbd_dev_create(struct rbd_client *rbdc,
+- struct rbd_spec *spec)
++static struct rbd_device *__rbd_dev_create(struct rbd_spec *spec)
+ {
+ struct rbd_device *rbd_dev;
+
+@@ -5415,9 +5414,6 @@ static struct rbd_device *__rbd_dev_crea
+ rbd_dev->dev.parent = &rbd_root_dev;
+ device_initialize(&rbd_dev->dev);
+
+- rbd_dev->rbd_client = rbdc;
+- rbd_dev->spec = spec;
+-
+ return rbd_dev;
+ }
+
+@@ -5430,12 +5426,10 @@ static struct rbd_device *rbd_dev_create
+ {
+ struct rbd_device *rbd_dev;
+
+- rbd_dev = __rbd_dev_create(rbdc, spec);
++ rbd_dev = __rbd_dev_create(spec);
+ if (!rbd_dev)
+ return NULL;
+
+- rbd_dev->opts = opts;
+-
+ /* get an id and fill in device name */
+ rbd_dev->dev_id = ida_simple_get(&rbd_dev_id_ida, 0,
+ minor_to_rbd_dev_id(1 << MINORBITS),
+@@ -5452,6 +5446,10 @@ static struct rbd_device *rbd_dev_create
+ /* we have a ref from do_rbd_add() */
+ __module_get(THIS_MODULE);
+
++ rbd_dev->rbd_client = rbdc;
++ rbd_dev->spec = spec;
++ rbd_dev->opts = opts;
++
+ dout("%s rbd_dev %p dev_id %d\n", __func__, rbd_dev, rbd_dev->dev_id);
+ return rbd_dev;
+
+@@ -6812,7 +6810,7 @@ static int rbd_dev_probe_parent(struct r
+ goto out_err;
+ }
+
+- parent = __rbd_dev_create(rbd_dev->rbd_client, rbd_dev->parent_spec);
++ parent = __rbd_dev_create(rbd_dev->parent_spec);
+ if (!parent) {
+ ret = -ENOMEM;
+ goto out_err;
+@@ -6822,8 +6820,8 @@ static int rbd_dev_probe_parent(struct r
+ * Images related by parent/child relationships always share
+ * rbd_client and spec/parent_spec, so bump their refcounts.
+ */
+- __rbd_get_client(rbd_dev->rbd_client);
+- rbd_spec_get(rbd_dev->parent_spec);
++ parent->rbd_client = __rbd_get_client(rbd_dev->rbd_client);
++ parent->spec = rbd_spec_get(rbd_dev->parent_spec);
+
+ __set_bit(RBD_DEV_FLAG_READONLY, &parent->flags);
+
--- /dev/null
+From e46ceea3148163166ef9b7bcac578e72dd30c064 Mon Sep 17 00:00:00 2001
+From: Chen-Yu Tsai <wenst@chromium.org>
+Date: Wed, 4 Jan 2023 16:31:10 +0800
+Subject: remoteproc/mtk_scp: Move clk ops outside send_lock
+
+From: Chen-Yu Tsai <wenst@chromium.org>
+
+commit e46ceea3148163166ef9b7bcac578e72dd30c064 upstream.
+
+Clocks are properly reference counted and do not need to be inside the
+lock range.
+
+Right now this triggers a false-positive lockdep warning on MT8192 based
+Chromebooks, through a combination of mtk-scp that has a cros-ec-rpmsg
+sub-device, the (actual) cros-ec I2C adapter registration, I2C client
+(not on cros-ec) probe doing i2c transfers and enabling clocks.
+
+This is a false positive because the cros-ec-rpmsg under mtk-scp does
+not have an I2C adapter, and also each I2C adapter and cros-ec instance
+have their own mutex.
+
+Move the clk operations outside of the send_lock range.
+
+Fixes: 63c13d61eafe ("remoteproc/mediatek: add SCP support for mt8183")
+Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
+Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20230104083110.736377-1-wenst@chromium.org
+[Fixed "Fixes:" tag line]
+Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/remoteproc/mtk_scp_ipi.c | 11 +++++------
+ 1 file changed, 5 insertions(+), 6 deletions(-)
+
+--- a/drivers/remoteproc/mtk_scp_ipi.c
++++ b/drivers/remoteproc/mtk_scp_ipi.c
+@@ -164,21 +164,21 @@ int scp_ipi_send(struct mtk_scp *scp, u3
+ WARN_ON(len > sizeof(send_obj->share_buf)) || WARN_ON(!buf))
+ return -EINVAL;
+
+- mutex_lock(&scp->send_lock);
+-
+ ret = clk_prepare_enable(scp->clk);
+ if (ret) {
+ dev_err(scp->dev, "failed to enable clock\n");
+- goto unlock_mutex;
++ return ret;
+ }
+
++ mutex_lock(&scp->send_lock);
++
+ /* Wait until SCP receives the last command */
+ timeout = jiffies + msecs_to_jiffies(2000);
+ do {
+ if (time_after(jiffies, timeout)) {
+ dev_err(scp->dev, "%s: IPI timeout!\n", __func__);
+ ret = -ETIMEDOUT;
+- goto clock_disable;
++ goto unlock_mutex;
+ }
+ } while (readl(scp->reg_base + scp->data->host_to_scp_reg));
+
+@@ -205,10 +205,9 @@ int scp_ipi_send(struct mtk_scp *scp, u3
+ ret = 0;
+ }
+
+-clock_disable:
+- clk_disable_unprepare(scp->clk);
+ unlock_mutex:
+ mutex_unlock(&scp->send_lock);
++ clk_disable_unprepare(scp->clk);
+
+ return ret;
+ }
--- /dev/null
+From 8843e06f67b14f71c044bf6267b2387784c7e198 Mon Sep 17 00:00:00 2001
+From: Mukesh Ojha <quic_mojha@quicinc.com>
+Date: Tue, 14 Feb 2023 17:36:43 +0530
+Subject: ring-buffer: Handle race between rb_move_tail and rb_check_pages
+
+From: Mukesh Ojha <quic_mojha@quicinc.com>
+
+commit 8843e06f67b14f71c044bf6267b2387784c7e198 upstream.
+
+It seems a data race between ring_buffer writing and integrity check.
+That is, RB_FLAG of head_page is been updating, while at same time
+RB_FLAG was cleared when doing integrity check rb_check_pages():
+
+ rb_check_pages() rb_handle_head_page():
+ -------- --------
+ rb_head_page_deactivate()
+ rb_head_page_set_normal()
+ rb_head_page_activate()
+
+We do intergrity test of the list to check if the list is corrupted and
+it is still worth doing it. So, let's refactor rb_check_pages() such that
+we no longer clear and set flag during the list sanity checking.
+
+[1] and [2] are the test to reproduce and the crash report respectively.
+
+1:
+``` read_trace.sh
+ while true;
+ do
+ # the "trace" file is closed after read
+ head -1 /sys/kernel/tracing/trace > /dev/null
+ done
+```
+``` repro.sh
+ sysctl -w kernel.panic_on_warn=1
+ # function tracer will writing enough data into ring_buffer
+ echo function > /sys/kernel/tracing/current_tracer
+ ./read_trace.sh &
+ ./read_trace.sh &
+ ./read_trace.sh &
+ ./read_trace.sh &
+ ./read_trace.sh &
+ ./read_trace.sh &
+ ./read_trace.sh &
+ ./read_trace.sh &
+```
+
+2:
+------------[ cut here ]------------
+WARNING: CPU: 9 PID: 62 at kernel/trace/ring_buffer.c:2653
+rb_move_tail+0x450/0x470
+Modules linked in:
+CPU: 9 PID: 62 Comm: ksoftirqd/9 Tainted: G W 6.2.0-rc6+
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
+rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
+RIP: 0010:rb_move_tail+0x450/0x470
+Code: ff ff 4c 89 c8 f0 4d 0f b1 02 48 89 c2 48 83 e2 fc 49 39 d0 75 24
+83 e0 03 83 f8 02 0f 84 e1 fb ff ff 48 8b 57 10 f0 ff 42 08 <0f> 0b 83
+f8 02 0f 84 ce fb ff ff e9 db
+RSP: 0018:ffffb5564089bd00 EFLAGS: 00000203
+RAX: 0000000000000000 RBX: ffff9db385a2bf81 RCX: ffffb5564089bd18
+RDX: ffff9db281110100 RSI: 0000000000000fe4 RDI: ffff9db380145400
+RBP: ffff9db385a2bf80 R08: ffff9db385a2bfc0 R09: ffff9db385a2bfc2
+R10: ffff9db385a6c000 R11: ffff9db385a2bf80 R12: 0000000000000000
+R13: 00000000000003e8 R14: ffff9db281110100 R15: ffffffffbb006108
+FS: 0000000000000000(0000) GS:ffff9db3bdcc0000(0000)
+knlGS:0000000000000000
+CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+CR2: 00005602323024c8 CR3: 0000000022e0c000 CR4: 00000000000006e0
+Call Trace:
+ <TASK>
+ ring_buffer_lock_reserve+0x136/0x360
+ ? __do_softirq+0x287/0x2df
+ ? __pfx_rcu_softirq_qs+0x10/0x10
+ trace_function+0x21/0x110
+ ? __pfx_rcu_softirq_qs+0x10/0x10
+ ? __do_softirq+0x287/0x2df
+ function_trace_call+0xf6/0x120
+ 0xffffffffc038f097
+ ? rcu_softirq_qs+0x5/0x140
+ rcu_softirq_qs+0x5/0x140
+ __do_softirq+0x287/0x2df
+ run_ksoftirqd+0x2a/0x30
+ smpboot_thread_fn+0x188/0x220
+ ? __pfx_smpboot_thread_fn+0x10/0x10
+ kthread+0xe7/0x110
+ ? __pfx_kthread+0x10/0x10
+ ret_from_fork+0x2c/0x50
+ </TASK>
+---[ end trace 0000000000000000 ]---
+
+[ crash report and test reproducer credit goes to Zheng Yejian]
+
+Link: https://lore.kernel.org/linux-trace-kernel/1676376403-16462-1-git-send-email-quic_mojha@quicinc.com
+
+Cc: <mhiramat@kernel.org>
+Cc: stable@vger.kernel.org
+Fixes: 1039221cc278 ("ring-buffer: Do not disable recording when there is an iterator")
+Reported-by: Zheng Yejian <zhengyejian1@huawei.com>
+Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/ring_buffer.c | 42 ++++++++++--------------------------------
+ 1 file changed, 10 insertions(+), 32 deletions(-)
+
+--- a/kernel/trace/ring_buffer.c
++++ b/kernel/trace/ring_buffer.c
+@@ -1450,19 +1450,6 @@ static int rb_check_bpage(struct ring_bu
+ }
+
+ /**
+- * rb_check_list - make sure a pointer to a list has the last bits zero
+- */
+-static int rb_check_list(struct ring_buffer_per_cpu *cpu_buffer,
+- struct list_head *list)
+-{
+- if (RB_WARN_ON(cpu_buffer, rb_list_head(list->prev) != list->prev))
+- return 1;
+- if (RB_WARN_ON(cpu_buffer, rb_list_head(list->next) != list->next))
+- return 1;
+- return 0;
+-}
+-
+-/**
+ * rb_check_pages - integrity check of buffer pages
+ * @cpu_buffer: CPU buffer with pages to test
+ *
+@@ -1471,36 +1458,27 @@ static int rb_check_list(struct ring_buf
+ */
+ static int rb_check_pages(struct ring_buffer_per_cpu *cpu_buffer)
+ {
+- struct list_head *head = cpu_buffer->pages;
+- struct buffer_page *bpage, *tmp;
++ struct list_head *head = rb_list_head(cpu_buffer->pages);
++ struct list_head *tmp;
+
+- /* Reset the head page if it exists */
+- if (cpu_buffer->head_page)
+- rb_set_head_page(cpu_buffer);
+-
+- rb_head_page_deactivate(cpu_buffer);
+-
+- if (RB_WARN_ON(cpu_buffer, head->next->prev != head))
+- return -1;
+- if (RB_WARN_ON(cpu_buffer, head->prev->next != head))
++ if (RB_WARN_ON(cpu_buffer,
++ rb_list_head(rb_list_head(head->next)->prev) != head))
+ return -1;
+
+- if (rb_check_list(cpu_buffer, head))
++ if (RB_WARN_ON(cpu_buffer,
++ rb_list_head(rb_list_head(head->prev)->next) != head))
+ return -1;
+
+- list_for_each_entry_safe(bpage, tmp, head, list) {
++ for (tmp = rb_list_head(head->next); tmp != head; tmp = rb_list_head(tmp->next)) {
+ if (RB_WARN_ON(cpu_buffer,
+- bpage->list.next->prev != &bpage->list))
++ rb_list_head(rb_list_head(tmp->next)->prev) != tmp))
+ return -1;
++
+ if (RB_WARN_ON(cpu_buffer,
+- bpage->list.prev->next != &bpage->list))
+- return -1;
+- if (rb_check_list(cpu_buffer, &bpage->list))
++ rb_list_head(rb_list_head(tmp->prev)->next) != tmp))
+ return -1;
+ }
+
+- rb_head_page_activate(cpu_buffer);
+-
+ return 0;
+ }
+
--- /dev/null
+From fc663711b94468f4e1427ebe289c9f05669699c9 Mon Sep 17 00:00:00 2001
+From: Bart Van Assche <bvanassche@acm.org>
+Date: Fri, 10 Feb 2023 12:52:00 -0800
+Subject: scsi: core: Remove the /proc/scsi/${proc_name} directory earlier
+
+From: Bart Van Assche <bvanassche@acm.org>
+
+commit fc663711b94468f4e1427ebe289c9f05669699c9 upstream.
+
+Remove the /proc/scsi/${proc_name} directory earlier to fix a race
+condition between unloading and reloading kernel modules. This fixes a bug
+introduced in 2009 by commit 77c019768f06 ("[SCSI] fix /proc memory leak in
+the SCSI core").
+
+Fix the following kernel warning:
+
+proc_dir_entry 'scsi/scsi_debug' already registered
+WARNING: CPU: 19 PID: 27986 at fs/proc/generic.c:376 proc_register+0x27d/0x2e0
+Call Trace:
+ proc_mkdir+0xb5/0xe0
+ scsi_proc_hostdir_add+0xb5/0x170
+ scsi_host_alloc+0x683/0x6c0
+ sdebug_driver_probe+0x6b/0x2d0 [scsi_debug]
+ really_probe+0x159/0x540
+ __driver_probe_device+0xdc/0x230
+ driver_probe_device+0x4f/0x120
+ __device_attach_driver+0xef/0x180
+ bus_for_each_drv+0xe5/0x130
+ __device_attach+0x127/0x290
+ device_initial_probe+0x17/0x20
+ bus_probe_device+0x110/0x130
+ device_add+0x673/0xc80
+ device_register+0x1e/0x30
+ sdebug_add_host_helper+0x1a7/0x3b0 [scsi_debug]
+ scsi_debug_init+0x64f/0x1000 [scsi_debug]
+ do_one_initcall+0xd7/0x470
+ do_init_module+0xe7/0x330
+ load_module+0x122a/0x12c0
+ __do_sys_finit_module+0x124/0x1a0
+ __x64_sys_finit_module+0x46/0x50
+ do_syscall_64+0x38/0x80
+ entry_SYSCALL_64_after_hwframe+0x46/0xb0
+
+Link: https://lore.kernel.org/r/20230210205200.36973-3-bvanassche@acm.org
+Cc: Alan Stern <stern@rowland.harvard.edu>
+Cc: Yi Zhang <yi.zhang@redhat.com>
+Cc: stable@vger.kernel.org
+Fixes: 77c019768f06 ("[SCSI] fix /proc memory leak in the SCSI core")
+Reported-by: Yi Zhang <yi.zhang@redhat.com>
+Signed-off-by: Bart Van Assche <bvanassche@acm.org>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/scsi/hosts.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/scsi/hosts.c
++++ b/drivers/scsi/hosts.c
+@@ -180,6 +180,7 @@ void scsi_remove_host(struct Scsi_Host *
+ scsi_forget_host(shost);
+ mutex_unlock(&shost->scan_mutex);
+ scsi_proc_host_rm(shost);
++ scsi_proc_hostdir_rm(shost->hostt);
+
+ spin_lock_irqsave(shost->host_lock, flags);
+ if (scsi_host_set_state(shost, SHOST_DEL))
+@@ -321,6 +322,7 @@ static void scsi_host_dev_release(struct
+ struct Scsi_Host *shost = dev_to_shost(dev);
+ struct device *parent = dev->parent;
+
++ /* In case scsi_remove_host() has not been called. */
+ scsi_proc_hostdir_rm(shost->hostt);
+
+ /* Wait for functions invoked through call_rcu(&shost->rcu, ...) */
--- /dev/null
+From c75e6aef5039830cce5d4cf764dd204522f89e6b Mon Sep 17 00:00:00 2001
+From: Arun Easi <aeasi@marvell.com>
+Date: Mon, 19 Dec 2022 03:07:40 -0800
+Subject: scsi: qla2xxx: Fix DMA-API call trace on NVMe LS requests
+
+From: Arun Easi <aeasi@marvell.com>
+
+commit c75e6aef5039830cce5d4cf764dd204522f89e6b upstream.
+
+The following message and call trace was seen with debug kernels:
+
+DMA-API: qla2xxx 0000:41:00.0: device driver failed to check map
+error [device address=0x00000002a3ff38d8] [size=1024 bytes] [mapped as
+single]
+WARNING: CPU: 0 PID: 2930 at kernel/dma/debug.c:1017
+ check_unmap+0xf42/0x1990
+
+Call Trace:
+ debug_dma_unmap_page+0xc9/0x100
+ qla_nvme_ls_unmap+0x141/0x210 [qla2xxx]
+
+Remove DMA mapping from the driver altogether, as it is already done by FC
+layer. This prevents the warning.
+
+Fixes: c85ab7d9e27a ("scsi: qla2xxx: Fix missed DMA unmap for NVMe ls requests")
+Cc: stable@vger.kernel.org
+Signed-off-by: Arun Easi <aeasi@marvell.com>
+Signed-off-by: Nilesh Javali <njavali@marvell.com>
+Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/scsi/qla2xxx/qla_nvme.c | 19 +------------------
+ 1 file changed, 1 insertion(+), 18 deletions(-)
+
+--- a/drivers/scsi/qla2xxx/qla_nvme.c
++++ b/drivers/scsi/qla2xxx/qla_nvme.c
+@@ -165,18 +165,6 @@ out:
+ qla2xxx_rel_qpair_sp(sp->qpair, sp);
+ }
+
+-static void qla_nvme_ls_unmap(struct srb *sp, struct nvmefc_ls_req *fd)
+-{
+- if (sp->flags & SRB_DMA_VALID) {
+- struct srb_iocb *nvme = &sp->u.iocb_cmd;
+- struct qla_hw_data *ha = sp->fcport->vha->hw;
+-
+- dma_unmap_single(&ha->pdev->dev, nvme->u.nvme.cmd_dma,
+- fd->rqstlen, DMA_TO_DEVICE);
+- sp->flags &= ~SRB_DMA_VALID;
+- }
+-}
+-
+ static void qla_nvme_release_ls_cmd_kref(struct kref *kref)
+ {
+ struct srb *sp = container_of(kref, struct srb, cmd_kref);
+@@ -194,7 +182,6 @@ static void qla_nvme_release_ls_cmd_kref
+
+ fd = priv->fd;
+
+- qla_nvme_ls_unmap(sp, fd);
+ fd->done(fd, priv->comp_status);
+ out:
+ qla2x00_rel_sp(sp);
+@@ -336,13 +323,10 @@ static int qla_nvme_ls_req(struct nvme_f
+ nvme->u.nvme.rsp_len = fd->rsplen;
+ nvme->u.nvme.rsp_dma = fd->rspdma;
+ nvme->u.nvme.timeout_sec = fd->timeout;
+- nvme->u.nvme.cmd_dma = dma_map_single(&ha->pdev->dev, fd->rqstaddr,
+- fd->rqstlen, DMA_TO_DEVICE);
++ nvme->u.nvme.cmd_dma = fd->rqstdma;
+ dma_sync_single_for_device(&ha->pdev->dev, nvme->u.nvme.cmd_dma,
+ fd->rqstlen, DMA_TO_DEVICE);
+
+- sp->flags |= SRB_DMA_VALID;
+-
+ rval = qla2x00_start_sp(sp);
+ if (rval != QLA_SUCCESS) {
+ ql_log(ql_log_warn, vha, 0x700e,
+@@ -350,7 +334,6 @@ static int qla_nvme_ls_req(struct nvme_f
+ wake_up(&sp->nvme_ls_waitq);
+ sp->priv = NULL;
+ priv->sp = NULL;
+- qla_nvme_ls_unmap(sp, fd);
+ qla2x00_rel_sp(sp);
+ return rval;
+ }
--- /dev/null
+From 3fbc74feb642deb688cc97f76d40b7287ddd4cb1 Mon Sep 17 00:00:00 2001
+From: Quinn Tran <qutran@marvell.com>
+Date: Mon, 19 Dec 2022 03:07:45 -0800
+Subject: scsi: qla2xxx: Fix erroneous link down
+
+From: Quinn Tran <qutran@marvell.com>
+
+commit 3fbc74feb642deb688cc97f76d40b7287ddd4cb1 upstream.
+
+If after an adapter reset the appearance of link is not recovered, the
+devices are not rediscovered. This is result of a race condition between
+adapter reset (abort_isp) and the topology scan. During adapter reset, the
+ABORT_ISP_ACTIVE flag is set. Topology scan usually occurred after adapter
+reset. In this case, the topology scan came earlier than usual where it
+ran into problem due to ABORT_ISP_ACTIVE flag was still set.
+
+kernel: qla2xxx [0000:13:00.0]-1005:1: Cmd 0x6a aborted with timeout since ISP Abort is pending
+kernel: qla2xxx [0000:13:00.0]-28a0:1: MBX_GET_PORT_NAME failed, No FL Port.
+kernel: qla2xxx [0000:13:00.0]-286b:1: qla2x00_configure_loop: exiting normally. local port wwpn 51402ec0123d9a80 id 012300)
+kernel: qla2xxx [0000:13:00.0]-8017:1: ADAPTER RESET SUCCEEDED nexus=1:0:15.
+
+Allow adapter reset to complete before any scan can start.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Quinn Tran <qutran@marvell.com>
+Signed-off-by: Nilesh Javali <njavali@marvell.com>
+Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/scsi/qla2xxx/qla_os.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/drivers/scsi/qla2xxx/qla_os.c
++++ b/drivers/scsi/qla2xxx/qla_os.c
+@@ -6899,9 +6899,12 @@ qla2x00_do_dpc(void *data)
+ }
+ }
+ loop_resync_check:
+- if (test_and_clear_bit(LOOP_RESYNC_NEEDED,
++ if (!qla2x00_reset_active(base_vha) &&
++ test_and_clear_bit(LOOP_RESYNC_NEEDED,
+ &base_vha->dpc_flags)) {
+-
++ /*
++ * Allow abort_isp to complete before moving on to scanning.
++ */
+ ql_dbg(ql_dbg_dpc, base_vha, 0x400f,
+ "Loop resync scheduled.\n");
+
--- /dev/null
+From b1ae65c082f74536ec292b15766f2846f0238373 Mon Sep 17 00:00:00 2001
+From: Quinn Tran <qutran@marvell.com>
+Date: Mon, 19 Dec 2022 03:07:39 -0800
+Subject: scsi: qla2xxx: Fix link failure in NPIV environment
+
+From: Quinn Tran <qutran@marvell.com>
+
+commit b1ae65c082f74536ec292b15766f2846f0238373 upstream.
+
+User experienced symptoms of adapter failure in NPIV environment. NPIV
+hosts were allowed to trigger chip reset back to back due to NPIV link
+state being slow to come online.
+
+Fix link failure in NPIV environment by removing NPIV host from directly
+being able to perform chip reset.
+
+ kernel: qla2xxx [0000:04:00.1]-6009:261: Loop down - aborting ISP.
+ kernel: qla2xxx [0000:04:00.1]-6009:262: Loop down - aborting ISP.
+ kernel: qla2xxx [0000:04:00.1]-6009:281: Loop down - aborting ISP.
+ kernel: qla2xxx [0000:04:00.1]-6009:285: Loop down - aborting ISP
+
+Fixes: 0d6e61bc6a4f ("[SCSI] qla2xxx: Correct various NPIV issues.")
+Cc: stable@vger.kernel.org
+Signed-off-by: Quinn Tran <qutran@marvell.com>
+Signed-off-by: Nilesh Javali <njavali@marvell.com>
+Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/scsi/qla2xxx/qla_os.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/scsi/qla2xxx/qla_os.c
++++ b/drivers/scsi/qla2xxx/qla_os.c
+@@ -7145,7 +7145,7 @@ qla2x00_timer(struct timer_list *t)
+
+ /* if the loop has been down for 4 minutes, reinit adapter */
+ if (atomic_dec_and_test(&vha->loop_down_timer) != 0) {
+- if (!(vha->device_flags & DFLG_NO_CABLE)) {
++ if (!(vha->device_flags & DFLG_NO_CABLE) && !vha->vp_idx) {
+ ql_log(ql_log_warn, vha, 0x6009,
+ "Loop down - aborting ISP.\n");
+
io_uring-rsrc-disallow-multi-source-reg-buffers.patch
io_uring-remove-msg_nosignal-from-recvmsg.patch
io_uring-poll-allow-some-retries-for-poll-triggering-spuriously.patch
+alsa-ice1712-do-not-left-ice-gpio_mutex-locked-in-aureon_add_controls.patch
+alsa-hda-realtek-add-quirk-for-hp-elitedesk-800-g6-tower-pc.patch
+jbd2-fix-data-missing-when-reusing-bh-which-is-ready-to-be-checkpointed.patch
+ext4-optimize-ea_inode-block-expansion.patch
+ext4-refuse-to-create-ea-block-when-umounted.patch
+ext4-fix-possible-corruption-when-moving-a-directory.patch
+mtd-spi-nor-fix-shift-out-of-bounds-in-spi_nor_set_erase_type.patch
+dm-add-cond_resched-to-dm_wq_work.patch
+wifi-rtl8xxxu-use-a-longer-retry-limit-of-48.patch
+wifi-cfg80211-fix-use-after-free-for-wext.patch
+thermal-intel-powerclamp-fix-cur_state-for-multi-package-system.patch
+dm-flakey-fix-logic-when-corrupting-a-bio.patch
+dm-flakey-don-t-corrupt-the-zero-page.patch
+dm-flakey-fix-a-bug-with-32-bit-highmem-systems.patch
+arm-dts-exynos-correct-tmu-phandle-in-exynos4210.patch
+arm-dts-exynos-correct-tmu-phandle-in-exynos4.patch
+arm-dts-exynos-correct-tmu-phandle-in-odroid-xu3-family.patch
+arm-dts-exynos-correct-tmu-phandle-in-exynos5250.patch
+arm-dts-exynos-correct-tmu-phandle-in-odroid-xu.patch
+arm-dts-exynos-correct-tmu-phandle-in-odroid-hc1.patch
+rbd-avoid-use-after-free-in-do_rbd_add-when-rbd_dev_create-fails.patch
+alpha-fix-fen-fault-handling.patch
+dax-kmem-fix-leak-of-memory-hotplug-resources.patch
+mips-fix-syscall_get_nr.patch
+media-ipu3-cio2-fix-pm-runtime-usage_count-in-driver-unbind.patch
+remoteproc-mtk_scp-move-clk-ops-outside-send_lock.patch
+docs-gdbmacros-print-newest-record.patch
+mm-memcontrol-deprecate-charge-moving.patch
+mm-thp-check-and-bail-out-if-page-in-deferred-queue-already.patch
+ktest.pl-give-back-console-on-ctrt-c-on-monitor.patch
+ktest.pl-fix-missing-end_monitor-when-machine-check-fails.patch
+ktest.pl-add-run_timeout-option-with-default-unlimited.patch
+ring-buffer-handle-race-between-rb_move_tail-and-rb_check_pages.patch
+scsi-core-remove-the-proc-scsi-proc_name-directory-earlier.patch
+scsi-qla2xxx-fix-link-failure-in-npiv-environment.patch
+scsi-qla2xxx-fix-dma-api-call-trace-on-nvme-ls-requests.patch
+scsi-qla2xxx-fix-erroneous-link-down.patch
--- /dev/null
+From 8e47363588377e1bdb65e2b020b409cfb44dd260 Mon Sep 17 00:00:00 2001
+From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
+Date: Wed, 1 Feb 2023 12:39:41 -0800
+Subject: thermal: intel: powerclamp: Fix cur_state for multi package system
+
+From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
+
+commit 8e47363588377e1bdb65e2b020b409cfb44dd260 upstream.
+
+The powerclamp cooling device cur_state shows actual idle observed by
+package C-state idle counters. But the implementation is not sufficient
+for multi package or multi die system. The cur_state value is incorrect.
+On these systems, these counters must be read from each package/die and
+somehow aggregate them. But there is no good method for aggregation.
+
+It was not a problem when explicit CPU model addition was required to
+enable intel powerclamp. In this way certain CPU models could have
+been avoided. But with the removal of CPU model check with the
+availability of Package C-state counters, the driver is loaded on most
+of the recent systems.
+
+For multi package/die systems, just show the actual target idle state,
+the system is trying to achieve. In powerclamp this is the user set
+state minus one.
+
+Also there is no use of starting a worker thread for polling package
+C-state counters and applying any compensation for multiple package
+or multiple die systems.
+
+Fixes: b721ca0d1927 ("thermal/powerclamp: remove cpu whitelist")
+Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
+Cc: 4.14+ <stable@vger.kernel.org> # 4.14+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/thermal/intel/intel_powerclamp.c | 20 ++++++++++++++++----
+ 1 file changed, 16 insertions(+), 4 deletions(-)
+
+--- a/drivers/thermal/intel/intel_powerclamp.c
++++ b/drivers/thermal/intel/intel_powerclamp.c
+@@ -57,6 +57,7 @@
+
+ static unsigned int target_mwait;
+ static struct dentry *debug_dir;
++static bool poll_pkg_cstate_enable;
+
+ /* user selected target */
+ static unsigned int set_target_ratio;
+@@ -262,6 +263,9 @@ static unsigned int get_compensation(int
+ {
+ unsigned int comp = 0;
+
++ if (!poll_pkg_cstate_enable)
++ return 0;
++
+ /* we only use compensation if all adjacent ones are good */
+ if (ratio == 1 &&
+ cal_data[ratio].confidence >= CONFIDENCE_OK &&
+@@ -534,7 +538,8 @@ static int start_power_clamp(void)
+ control_cpu = cpumask_first(cpu_online_mask);
+
+ clamping = true;
+- schedule_delayed_work(&poll_pkg_cstate_work, 0);
++ if (poll_pkg_cstate_enable)
++ schedule_delayed_work(&poll_pkg_cstate_work, 0);
+
+ /* start one kthread worker per online cpu */
+ for_each_online_cpu(cpu) {
+@@ -603,11 +608,15 @@ static int powerclamp_get_max_state(stru
+ static int powerclamp_get_cur_state(struct thermal_cooling_device *cdev,
+ unsigned long *state)
+ {
+- if (true == clamping)
+- *state = pkg_cstate_ratio_cur;
+- else
++ if (clamping) {
++ if (poll_pkg_cstate_enable)
++ *state = pkg_cstate_ratio_cur;
++ else
++ *state = set_target_ratio;
++ } else {
+ /* to save power, do not poll idle ratio while not clamping */
+ *state = -1; /* indicates invalid state */
++ }
+
+ return 0;
+ }
+@@ -732,6 +741,9 @@ static int __init powerclamp_init(void)
+ goto exit_unregister;
+ }
+
++ if (topology_max_packages() == 1 && topology_max_die_per_package() == 1)
++ poll_pkg_cstate_enable = true;
++
+ cooling_dev = thermal_cooling_device_register("intel_powerclamp", NULL,
+ &powerclamp_cooling_ops);
+ if (IS_ERR(cooling_dev)) {
--- /dev/null
+From 015b8cc5e7c4d7bb671f1984d7b7338c310b185b Mon Sep 17 00:00:00 2001
+From: Alexander Wetzel <alexander@wetzel-home.de>
+Date: Tue, 24 Jan 2023 15:18:56 +0100
+Subject: wifi: cfg80211: Fix use after free for wext
+
+From: Alexander Wetzel <alexander@wetzel-home.de>
+
+commit 015b8cc5e7c4d7bb671f1984d7b7338c310b185b upstream.
+
+Key information in wext.connect is not reset on (re)connect and can hold
+data from a previous connection.
+
+Reset key data to avoid that drivers or mac80211 incorrectly detect a
+WEP connection request and access the freed or already reused memory.
+
+Additionally optimize cfg80211_sme_connect() and avoid an useless
+schedule of conn_work.
+
+Fixes: fffd0934b939 ("cfg80211: rework key operation")
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20230124141856.356646-1-alexander@wetzel-home.de
+Signed-off-by: Alexander Wetzel <alexander@wetzel-home.de>
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/wireless/sme.c | 31 ++++++++++++++++++++++++++-----
+ 1 file changed, 26 insertions(+), 5 deletions(-)
+
+--- a/net/wireless/sme.c
++++ b/net/wireless/sme.c
+@@ -269,6 +269,15 @@ void cfg80211_conn_work(struct work_stru
+ rtnl_unlock();
+ }
+
++static void cfg80211_step_auth_next(struct cfg80211_conn *conn,
++ struct cfg80211_bss *bss)
++{
++ memcpy(conn->bssid, bss->bssid, ETH_ALEN);
++ conn->params.bssid = conn->bssid;
++ conn->params.channel = bss->channel;
++ conn->state = CFG80211_CONN_AUTHENTICATE_NEXT;
++}
++
+ /* Returned bss is reference counted and must be cleaned up appropriately. */
+ static struct cfg80211_bss *cfg80211_get_conn_bss(struct wireless_dev *wdev)
+ {
+@@ -286,10 +295,7 @@ static struct cfg80211_bss *cfg80211_get
+ if (!bss)
+ return NULL;
+
+- memcpy(wdev->conn->bssid, bss->bssid, ETH_ALEN);
+- wdev->conn->params.bssid = wdev->conn->bssid;
+- wdev->conn->params.channel = bss->channel;
+- wdev->conn->state = CFG80211_CONN_AUTHENTICATE_NEXT;
++ cfg80211_step_auth_next(wdev->conn, bss);
+ schedule_work(&rdev->conn_work);
+
+ return bss;
+@@ -568,7 +574,12 @@ static int cfg80211_sme_connect(struct w
+ wdev->conn->params.ssid_len = wdev->ssid_len;
+
+ /* see if we have the bss already */
+- bss = cfg80211_get_conn_bss(wdev);
++ bss = cfg80211_get_bss(wdev->wiphy, wdev->conn->params.channel,
++ wdev->conn->params.bssid,
++ wdev->conn->params.ssid,
++ wdev->conn->params.ssid_len,
++ wdev->conn_bss_type,
++ IEEE80211_PRIVACY(wdev->conn->params.privacy));
+
+ if (prev_bssid) {
+ memcpy(wdev->conn->prev_bssid, prev_bssid, ETH_ALEN);
+@@ -579,6 +590,7 @@ static int cfg80211_sme_connect(struct w
+ if (bss) {
+ enum nl80211_timeout_reason treason;
+
++ cfg80211_step_auth_next(wdev->conn, bss);
+ err = cfg80211_conn_do_work(wdev, &treason);
+ cfg80211_put_bss(wdev->wiphy, bss);
+ } else {
+@@ -1245,6 +1257,15 @@ int cfg80211_connect(struct cfg80211_reg
+ } else {
+ if (WARN_ON(connkeys))
+ return -EINVAL;
++
++ /* connect can point to wdev->wext.connect which
++ * can hold key data from a previous connection
++ */
++ connect->key = NULL;
++ connect->key_len = 0;
++ connect->key_idx = 0;
++ connect->crypto.cipher_group = 0;
++ connect->crypto.n_ciphers_pairwise = 0;
+ }
+
+ wdev->connect_keys = connkeys;
--- /dev/null
+From 2a86aa9a1892d60ef2e3f310f5b42b8b05546d65 Mon Sep 17 00:00:00 2001
+From: Bitterblue Smith <rtl8821cerfe2@gmail.com>
+Date: Sun, 8 Jan 2023 17:08:16 +0200
+Subject: wifi: rtl8xxxu: Use a longer retry limit of 48
+
+From: Bitterblue Smith <rtl8821cerfe2@gmail.com>
+
+commit 2a86aa9a1892d60ef2e3f310f5b42b8b05546d65 upstream.
+
+The Realtek rate control algorithm goes back and forth a lot between
+the highest and the lowest rate it's allowed to use. This is due to
+a lot of frames being dropped because the retry limits set by
+IEEE80211_CONF_CHANGE_RETRY_LIMITS are too low. (Experimentally, they
+are 4 for long frames and 7 for short frames.)
+
+The vendor drivers hardcode the value 48 for both retry limits (for
+station mode), which makes dropped frames very rare and thus the rate
+control is more stable.
+
+Because most Realtek chips handle the rate control in the firmware,
+which can't be modified, ignore the limits set by
+IEEE80211_CONF_CHANGE_RETRY_LIMITS and use the value 48 (set during
+chip initialisation), same as the vendor drivers.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
+Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
+Signed-off-by: Kalle Valo <kvalo@kernel.org>
+Link: https://lore.kernel.org/r/477d745b-6bac-111d-403c-487fc19aa30d@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 9 ---------
+ 1 file changed, 9 deletions(-)
+
+--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
++++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+@@ -5908,7 +5908,6 @@ static int rtl8xxxu_config(struct ieee80
+ {
+ struct rtl8xxxu_priv *priv = hw->priv;
+ struct device *dev = &priv->udev->dev;
+- u16 val16;
+ int ret = 0, channel;
+ bool ht40;
+
+@@ -5918,14 +5917,6 @@ static int rtl8xxxu_config(struct ieee80
+ __func__, hw->conf.chandef.chan->hw_value,
+ changed, hw->conf.chandef.width);
+
+- if (changed & IEEE80211_CONF_CHANGE_RETRY_LIMITS) {
+- val16 = ((hw->conf.long_frame_max_tx_count <<
+- RETRY_LIMIT_LONG_SHIFT) & RETRY_LIMIT_LONG_MASK) |
+- ((hw->conf.short_frame_max_tx_count <<
+- RETRY_LIMIT_SHORT_SHIFT) & RETRY_LIMIT_SHORT_MASK);
+- rtl8xxxu_write16(priv, REG_RETRY_LIMIT, val16);
+- }
+-
+ if (changed & IEEE80211_CONF_CHANGE_CHANNEL) {
+ switch (hw->conf.chandef.width) {
+ case NL80211_CHAN_WIDTH_20_NOHT:
projects / thirdparty / kernel / stable-queue.git / commitdiff
