--- /dev/null
+From d201c92bff90f3d3d0b079fc955378c15c0483cc Mon Sep 17 00:00:00 2001
+From: Dragan Simic <dsimic@manjaro.org>
+Date: Mon, 20 May 2024 19:20:28 +0200
+Subject: arm64: dts: rockchip: Fix the DCDC_REG2 minimum voltage on Quartz64 Model B
+
+From: Dragan Simic <dsimic@manjaro.org>
+
+commit d201c92bff90f3d3d0b079fc955378c15c0483cc upstream.
+
+Correct the specified regulator-min-microvolt value for the buck DCDC_REG2
+regulator, which is part of the Rockchip RK809 PMIC, in the Pine64 Quartz64
+Model B board dts. According to the RK809 datasheet, version 1.01, this
+regulator is capable of producing voltages as low as 0.5 V on its output,
+instead of going down to 0.9 V only, which is additionally confirmed by the
+regulator-min-microvolt values found in the board dts files for the other
+supported boards that use the same RK809 PMIC.
+
+This allows the DVFS to clock the GPU on the Quartz64 Model B below 700 MHz,
+all the way down to 200 MHz, which saves some power and reduces the amount of
+generated heat a bit, improving the thermal headroom and possibly improving
+the bursty CPU and GPU performance on this board.
+
+This also eliminates the following warnings in the kernel log:
+
+ core: _opp_supported_by_regulators: OPP minuV: 825000 maxuV: 825000, not supported by regulator
+ panfrost fde60000.gpu: _opp_add: OPP not supported by regulators (200000000)
+ core: _opp_supported_by_regulators: OPP minuV: 825000 maxuV: 825000, not supported by regulator
+ panfrost fde60000.gpu: _opp_add: OPP not supported by regulators (300000000)
+ core: _opp_supported_by_regulators: OPP minuV: 825000 maxuV: 825000, not supported by regulator
+ panfrost fde60000.gpu: _opp_add: OPP not supported by regulators (400000000)
+ core: _opp_supported_by_regulators: OPP minuV: 825000 maxuV: 825000, not supported by regulator
+ panfrost fde60000.gpu: _opp_add: OPP not supported by regulators (600000000)
+
+Fixes: dcc8c66bef79 ("arm64: dts: rockchip: add Pine64 Quartz64-B device tree")
+Cc: stable@vger.kernel.org
+Reported-By: Diederik de Haas <didi.debian@cknow.org>
+Signed-off-by: Dragan Simic <dsimic@manjaro.org>
+Tested-by: Diederik de Haas <didi.debian@cknow.org>
+Link: https://lore.kernel.org/r/e70742ea2df432bf57b3f7de542d81ca22b0da2f.1716225483.git.dsimic@manjaro.org
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/rockchip/rk3566-quartz64-b.dts | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/boot/dts/rockchip/rk3566-quartz64-b.dts
++++ b/arch/arm64/boot/dts/rockchip/rk3566-quartz64-b.dts
+@@ -289,7 +289,7 @@
+ regulator-name = "vdd_gpu";
+ regulator-always-on;
+ regulator-boot-on;
+- regulator-min-microvolt = <900000>;
++ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <6001>;
+
--- /dev/null
+From 134061163ee5ca4759de5c24ca3bd71608891ba7 Mon Sep 17 00:00:00 2001
+From: Ghadi Elie Rahme <ghadi.rahme@canonical.com>
+Date: Thu, 27 Jun 2024 14:14:05 +0300
+Subject: bnx2x: Fix multiple UBSAN array-index-out-of-bounds
+
+From: Ghadi Elie Rahme <ghadi.rahme@canonical.com>
+
+commit 134061163ee5ca4759de5c24ca3bd71608891ba7 upstream.
+
+Fix UBSAN warnings that occur when using a system with 32 physical
+cpu cores or more, or when the user defines a number of Ethernet
+queues greater than or equal to FP_SB_MAX_E1x using the num_queues
+module parameter.
+
+Currently there is a read/write out of bounds that occurs on the array
+"struct stats_query_entry query" present inside the "bnx2x_fw_stats_req"
+struct in "drivers/net/ethernet/broadcom/bnx2x/bnx2x.h".
+Looking at the definition of the "struct stats_query_entry query" array:
+
+struct stats_query_entry query[FP_SB_MAX_E1x+
+ BNX2X_FIRST_QUEUE_QUERY_IDX];
+
+FP_SB_MAX_E1x is defined as the maximum number of fast path interrupts and
+has a value of 16, while BNX2X_FIRST_QUEUE_QUERY_IDX has a value of 3
+meaning the array has a total size of 19.
+Since accesses to "struct stats_query_entry query" are offset-ted by
+BNX2X_FIRST_QUEUE_QUERY_IDX, that means that the total number of Ethernet
+queues should not exceed FP_SB_MAX_E1x (16). However one of these queues
+is reserved for FCOE and thus the number of Ethernet queues should be set
+to [FP_SB_MAX_E1x -1] (15) if FCOE is enabled or [FP_SB_MAX_E1x] (16) if
+it is not.
+
+This is also described in a comment in the source code in
+drivers/net/ethernet/broadcom/bnx2x/bnx2x.h just above the Macro definition
+of FP_SB_MAX_E1x. Below is the part of this explanation that it important
+for this patch
+
+/*
+ * The total number of L2 queues, MSIX vectors and HW contexts (CIDs) is
+ * control by the number of fast-path status blocks supported by the
+ * device (HW/FW). Each fast-path status block (FP-SB) aka non-default
+ * status block represents an independent interrupts context that can
+ * serve a regular L2 networking queue. However special L2 queues such
+ * as the FCoE queue do not require a FP-SB and other components like
+ * the CNIC may consume FP-SB reducing the number of possible L2 queues
+ *
+ * If the maximum number of FP-SB available is X then:
+ * a. If CNIC is supported it consumes 1 FP-SB thus the max number of
+ * regular L2 queues is Y=X-1
+ * b. In MF mode the actual number of L2 queues is Y= (X-1/MF_factor)
+ * c. If the FCoE L2 queue is supported the actual number of L2 queues
+ * is Y+1
+ * d. The number of irqs (MSIX vectors) is either Y+1 (one extra for
+ * slow-path interrupts) or Y+2 if CNIC is supported (one additional
+ * FP interrupt context for the CNIC).
+ * e. The number of HW context (CID count) is always X or X+1 if FCoE
+ * L2 queue is supported. The cid for the FCoE L2 queue is always X.
+ */
+
+However this driver also supports NICs that use the E2 controller which can
+handle more queues due to having more FP-SB represented by FP_SB_MAX_E2.
+Looking at the commits when the E2 support was added, it was originally
+using the E1x parameters: commit f2e0899f0f27 ("bnx2x: Add 57712 support").
+Back then FP_SB_MAX_E2 was set to 16 the same as E1x. However the driver
+was later updated to take full advantage of the E2 instead of having it be
+limited to the capabilities of the E1x. But as far as we can tell, the
+array "stats_query_entry query" was still limited to using the FP-SB
+available to the E1x cards as part of an oversignt when the driver was
+updated to take full advantage of the E2, and now with the driver being
+aware of the greater queue size supported by E2 NICs, it causes the UBSAN
+warnings seen in the stack traces below.
+
+This patch increases the size of the "stats_query_entry query" array by
+replacing FP_SB_MAX_E1x with FP_SB_MAX_E2 to be large enough to handle
+both types of NICs.
+
+Stack traces:
+
+UBSAN: array-index-out-of-bounds in
+ drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c:1529:11
+index 20 is out of range for type 'stats_query_entry [19]'
+CPU: 12 PID: 858 Comm: systemd-network Not tainted 6.9.0-060900rc7-generic
+ #202405052133
+Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360 Gen9,
+ BIOS P89 10/21/2019
+Call Trace:
+ <TASK>
+ dump_stack_lvl+0x76/0xa0
+ dump_stack+0x10/0x20
+ __ubsan_handle_out_of_bounds+0xcb/0x110
+ bnx2x_prep_fw_stats_req+0x2e1/0x310 [bnx2x]
+ bnx2x_stats_init+0x156/0x320 [bnx2x]
+ bnx2x_post_irq_nic_init+0x81/0x1a0 [bnx2x]
+ bnx2x_nic_load+0x8e8/0x19e0 [bnx2x]
+ bnx2x_open+0x16b/0x290 [bnx2x]
+ __dev_open+0x10e/0x1d0
+RIP: 0033:0x736223927a0a
+Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca
+ 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00
+ f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89
+RSP: 002b:00007ffc0bb2ada8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
+RAX: ffffffffffffffda RBX: 0000583df50f9c78 RCX: 0000736223927a0a
+RDX: 0000000000000020 RSI: 0000583df50ee510 RDI: 0000000000000003
+RBP: 0000583df50d4940 R08: 00007ffc0bb2adb0 R09: 0000000000000080
+R10: 0000000000000000 R11: 0000000000000246 R12: 0000583df5103ae0
+R13: 000000000000035a R14: 0000583df50f9c30 R15: 0000583ddddddf00
+</TASK>
+---[ end trace ]---
+------------[ cut here ]------------
+UBSAN: array-index-out-of-bounds in
+ drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c:1546:11
+index 28 is out of range for type 'stats_query_entry [19]'
+CPU: 12 PID: 858 Comm: systemd-network Not tainted 6.9.0-060900rc7-generic
+ #202405052133
+Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360 Gen9,
+ BIOS P89 10/21/2019
+Call Trace:
+<TASK>
+dump_stack_lvl+0x76/0xa0
+dump_stack+0x10/0x20
+__ubsan_handle_out_of_bounds+0xcb/0x110
+bnx2x_prep_fw_stats_req+0x2fd/0x310 [bnx2x]
+bnx2x_stats_init+0x156/0x320 [bnx2x]
+bnx2x_post_irq_nic_init+0x81/0x1a0 [bnx2x]
+bnx2x_nic_load+0x8e8/0x19e0 [bnx2x]
+bnx2x_open+0x16b/0x290 [bnx2x]
+__dev_open+0x10e/0x1d0
+RIP: 0033:0x736223927a0a
+Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca
+ 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00
+ f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89
+RSP: 002b:00007ffc0bb2ada8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
+RAX: ffffffffffffffda RBX: 0000583df50f9c78 RCX: 0000736223927a0a
+RDX: 0000000000000020 RSI: 0000583df50ee510 RDI: 0000000000000003
+RBP: 0000583df50d4940 R08: 00007ffc0bb2adb0 R09: 0000000000000080
+R10: 0000000000000000 R11: 0000000000000246 R12: 0000583df5103ae0
+R13: 000000000000035a R14: 0000583df50f9c30 R15: 0000583ddddddf00
+ </TASK>
+---[ end trace ]---
+------------[ cut here ]------------
+UBSAN: array-index-out-of-bounds in
+ drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c:1895:8
+index 29 is out of range for type 'stats_query_entry [19]'
+CPU: 13 PID: 163 Comm: kworker/u96:1 Not tainted 6.9.0-060900rc7-generic
+ #202405052133
+Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360 Gen9,
+ BIOS P89 10/21/2019
+Workqueue: bnx2x bnx2x_sp_task [bnx2x]
+Call Trace:
+ <TASK>
+ dump_stack_lvl+0x76/0xa0
+ dump_stack+0x10/0x20
+ __ubsan_handle_out_of_bounds+0xcb/0x110
+ bnx2x_iov_adjust_stats_req+0x3c4/0x3d0 [bnx2x]
+ bnx2x_storm_stats_post.part.0+0x4a/0x330 [bnx2x]
+ ? bnx2x_hw_stats_post+0x231/0x250 [bnx2x]
+ bnx2x_stats_start+0x44/0x70 [bnx2x]
+ bnx2x_stats_handle+0x149/0x350 [bnx2x]
+ bnx2x_attn_int_asserted+0x998/0x9b0 [bnx2x]
+ bnx2x_sp_task+0x491/0x5c0 [bnx2x]
+ process_one_work+0x18d/0x3f0
+ </TASK>
+---[ end trace ]---
+
+Fixes: 50f0a562f8cc ("bnx2x: add fcoe statistics")
+Signed-off-by: Ghadi Elie Rahme <ghadi.rahme@canonical.com>
+Cc: stable@vger.kernel.org
+Link: https://patch.msgid.link/20240627111405.1037812-1-ghadi.rahme@canonical.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/broadcom/bnx2x/bnx2x.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
++++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
+@@ -1262,7 +1262,7 @@ enum {
+
+ struct bnx2x_fw_stats_req {
+ struct stats_query_header hdr;
+- struct stats_query_entry query[FP_SB_MAX_E1x+
++ struct stats_query_entry query[FP_SB_MAX_E2 +
+ BNX2X_FIRST_QUEUE_QUERY_IDX];
+ };
+
--- /dev/null
+From 72ceafb587a56e26c905472418c7dc2033c294d3 Mon Sep 17 00:00:00 2001
+From: Md Sadre Alam <quic_mdalam@quicinc.com>
+Date: Thu, 9 May 2024 16:24:05 +0530
+Subject: clk: qcom: gcc-ipq9574: Add BRANCH_HALT_VOTED flag
+
+From: Md Sadre Alam <quic_mdalam@quicinc.com>
+
+commit 72ceafb587a56e26c905472418c7dc2033c294d3 upstream.
+
+The crypto_ahb and crypto_axi clks are hardware voteable.
+This means that the halt bit isn't reliable because some
+other voter in the system, e.g. TrustZone, could be keeping
+the clk enabled when the kernel turns it off from clk_disable().
+Make these clks use voting mode by changing the halt check to
+BRANCH_HALT_VOTED and toggle the voting bit in the voting register
+instead of directly controlling the branch by writing to the branch
+register. This fixes stuck clk warnings seen on ipq9574 and saves
+power by actually turning the clk off.
+
+Also changes the CRYPTO_AHB_CLK_ENA & CRYPTO_AXI_CLK_ENA
+offset to 0xb004 from 0x16014.
+
+Cc: stable@vger.kernel.org
+Fixes: f6b2bd9cb29a ("clk: qcom: gcc-ipq9574: Enable crypto clocks")
+Signed-off-by: Md Sadre Alam <quic_mdalam@quicinc.com>
+Link: https://lore.kernel.org/r/20240509105405.1262369-1-quic_mdalam@quicinc.com
+Signed-off-by: Bjorn Andersson <andersson@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/clk/qcom/gcc-ipq9574.c | 10 ++++++----
+ 1 file changed, 6 insertions(+), 4 deletions(-)
+
+--- a/drivers/clk/qcom/gcc-ipq9574.c
++++ b/drivers/clk/qcom/gcc-ipq9574.c
+@@ -2140,9 +2140,10 @@ static struct clk_rcg2 pcnoc_bfdcd_clk_s
+
+ static struct clk_branch gcc_crypto_axi_clk = {
+ .halt_reg = 0x16010,
++ .halt_check = BRANCH_HALT_VOTED,
+ .clkr = {
+- .enable_reg = 0x16010,
+- .enable_mask = BIT(0),
++ .enable_reg = 0xb004,
++ .enable_mask = BIT(15),
+ .hw.init = &(const struct clk_init_data) {
+ .name = "gcc_crypto_axi_clk",
+ .parent_hws = (const struct clk_hw *[]) {
+@@ -2156,9 +2157,10 @@ static struct clk_branch gcc_crypto_axi_
+
+ static struct clk_branch gcc_crypto_ahb_clk = {
+ .halt_reg = 0x16014,
++ .halt_check = BRANCH_HALT_VOTED,
+ .clkr = {
+- .enable_reg = 0x16014,
+- .enable_mask = BIT(0),
++ .enable_reg = 0xb004,
++ .enable_mask = BIT(16),
+ .hw.init = &(const struct clk_init_data) {
+ .name = "gcc_crypto_ahb_clk",
+ .parent_hws = (const struct clk_hw *[]) {
--- /dev/null
+From ea977d742507e534d9fe4f4d74256f6b7f589338 Mon Sep 17 00:00:00 2001
+From: Frank Oltmanns <frank@oltmanns.dev>
+Date: Sun, 23 Jun 2024 10:45:58 +0200
+Subject: clk: sunxi-ng: common: Don't call hw_to_ccu_common on hw without common
+
+From: Frank Oltmanns <frank@oltmanns.dev>
+
+commit ea977d742507e534d9fe4f4d74256f6b7f589338 upstream.
+
+In order to set the rate range of a hw sunxi_ccu_probe calls
+hw_to_ccu_common() assuming all entries in desc->ccu_clks are contained
+in a ccu_common struct. This assumption is incorrect and, in
+consequence, causes invalid pointer de-references.
+
+Remove the faulty call. Instead, add one more loop that iterates over
+the ccu_clks and sets the rate range, if required.
+
+Fixes: b914ec33b391 ("clk: sunxi-ng: common: Support minimum and maximum rate")
+Reported-by: Robert J. Pafford <pafford.9@buckeyemail.osu.edu>
+Closes: https://lore.kernel.org/lkml/DM6PR01MB58047C810DDD5D0AE397CADFF7C22@DM6PR01MB5804.prod.exchangelabs.com/
+Cc: stable@vger.kernel.org
+Signed-off-by: Frank Oltmanns <frank@oltmanns.dev>
+Tested-by: Robert J. Pafford <pafford.9@buckeyemail.osu.edu>
+Link: https://lore.kernel.org/r/20240623-sunxi-ng_fix_common_probe-v1-1-7c97e32824a1@oltmanns.dev
+Signed-off-by: Chen-Yu Tsai <wens@csie.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/clk/sunxi-ng/ccu_common.c | 18 ++++++++++++------
+ 1 file changed, 12 insertions(+), 6 deletions(-)
+
+--- a/drivers/clk/sunxi-ng/ccu_common.c
++++ b/drivers/clk/sunxi-ng/ccu_common.c
+@@ -132,7 +132,6 @@ static int sunxi_ccu_probe(struct sunxi_
+
+ for (i = 0; i < desc->hw_clks->num ; i++) {
+ struct clk_hw *hw = desc->hw_clks->hws[i];
+- struct ccu_common *common = hw_to_ccu_common(hw);
+ const char *name;
+
+ if (!hw)
+@@ -147,14 +146,21 @@ static int sunxi_ccu_probe(struct sunxi_
+ pr_err("Couldn't register clock %d - %s\n", i, name);
+ goto err_clk_unreg;
+ }
++ }
++
++ for (i = 0; i < desc->num_ccu_clks; i++) {
++ struct ccu_common *cclk = desc->ccu_clks[i];
++
++ if (!cclk)
++ continue;
+
+- if (common->max_rate)
+- clk_hw_set_rate_range(hw, common->min_rate,
+- common->max_rate);
++ if (cclk->max_rate)
++ clk_hw_set_rate_range(&cclk->hw, cclk->min_rate,
++ cclk->max_rate);
+ else
+- WARN(common->min_rate,
++ WARN(cclk->min_rate,
+ "No max_rate, ignoring min_rate of clock %d - %s\n",
+- i, name);
++ i, clk_hw_get_name(&cclk->hw));
+ }
+
+ ret = of_clk_add_hw_provider(node, of_clk_hw_onecell_get,
--- /dev/null
+From d0417264437a8fa05f894cabba5a26715b32d78e Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Mon, 1 Jul 2024 12:50:10 -0400
+Subject: drm/amdgpu/atomfirmware: silence UBSAN warning
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+commit d0417264437a8fa05f894cabba5a26715b32d78e upstream.
+
+This is a variable sized array.
+
+Link: https://lists.freedesktop.org/archives/amd-gfx/2024-June/110420.html
+Tested-by: Jeff Layton <jlayton@kernel.org>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/include/atomfirmware.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/amd/include/atomfirmware.h
++++ b/drivers/gpu/drm/amd/include/atomfirmware.h
+@@ -734,7 +734,7 @@ struct atom_gpio_pin_lut_v2_1
+ {
+ struct atom_common_table_header table_header;
+ /*the real number of this included in the structure is calcualted by using the (whole structure size - the header size)/size of atom_gpio_pin_lut */
+- struct atom_gpio_pin_assignment gpio_pin[8];
++ struct atom_gpio_pin_assignment gpio_pin[];
+ };
+
+
--- /dev/null
+From 80bec6825b19d95ccdfd3393cf8ec15ff2a749b4 Mon Sep 17 00:00:00 2001
+From: Ma Ke <make24@iscas.ac.cn>
+Date: Thu, 27 Jun 2024 15:42:04 +0800
+Subject: drm/nouveau: fix null pointer dereference in nouveau_connector_get_modes
+
+From: Ma Ke <make24@iscas.ac.cn>
+
+commit 80bec6825b19d95ccdfd3393cf8ec15ff2a749b4 upstream.
+
+In nouveau_connector_get_modes(), the return value of drm_mode_duplicate()
+is assigned to mode, which will lead to a possible NULL pointer
+dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.
+
+Cc: stable@vger.kernel.org
+Fixes: 6ee738610f41 ("drm/nouveau: Add DRM driver for NVIDIA GPUs")
+Signed-off-by: Ma Ke <make24@iscas.ac.cn>
+Signed-off-by: Lyude Paul <lyude@redhat.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20240627074204.3023776-1-make24@iscas.ac.cn
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/nouveau/nouveau_connector.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
++++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
+@@ -1001,6 +1001,9 @@ nouveau_connector_get_modes(struct drm_c
+ struct drm_display_mode *mode;
+
+ mode = drm_mode_duplicate(dev, nv_connector->native_mode);
++ if (!mode)
++ return 0;
++
+ drm_mode_probed_add(connector, mode);
+ ret = 1;
+ }
--- /dev/null
+From 26746ed40bb0e4ebe2b2bd61c04eaaa54e263c14 Mon Sep 17 00:00:00 2001
+From: John Schoenick <johns@valvesoftware.com>
+Date: Fri, 28 Jun 2024 13:58:21 -0700
+Subject: drm: panel-orientation-quirks: Add quirk for Valve Galileo
+
+From: John Schoenick <johns@valvesoftware.com>
+
+commit 26746ed40bb0e4ebe2b2bd61c04eaaa54e263c14 upstream.
+
+Valve's Steam Deck Galileo revision has a 800x1280 OLED panel
+
+Cc: stable@vger.kernel.org # 6.1+
+Signed-off-by: John Schoenick <johns@valvesoftware.com>
+Signed-off-by: Matthew Schwartz <mattschwartz@gwu.edu>
+Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20240628205822.348402-2-mattschwartz@gwu.edu
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/drm_panel_orientation_quirks.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
++++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
+@@ -421,6 +421,13 @@ static const struct dmi_system_id orient
+ DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "1"),
+ },
+ .driver_data = (void *)&lcd800x1280_rightside_up,
++ }, { /* Valve Steam Deck */
++ .matches = {
++ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Valve"),
++ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Galileo"),
++ DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "1"),
++ },
++ .driver_data = (void *)&lcd800x1280_rightside_up,
+ }, { /* VIOS LTH17 */
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "VIOS"),
--- /dev/null
+From d99fbd9aab624fc030934e21655389ab1765dc94 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Thomas=20Hellstr=C3=B6m?= <thomas.hellstrom@linux.intel.com>
+Date: Fri, 28 Jun 2024 17:38:48 +0200
+Subject: drm/ttm: Always take the bo delayed cleanup path for imported bos
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Thomas Hellström <thomas.hellstrom@linux.intel.com>
+
+commit d99fbd9aab624fc030934e21655389ab1765dc94 upstream.
+
+Bos can be put with multiple unrelated dma-resv locks held. But
+imported bos attempt to grab the bo dma-resv during dma-buf detach
+that typically happens during cleanup. That leads to lockde splats
+similar to the below and a potential ABBA deadlock.
+
+Fix this by always taking the delayed workqueue cleanup path for
+imported bos.
+
+Requesting stable fixes from when the Xe driver was introduced,
+since its usage of drm_exec and wide vm dma_resvs appear to be
+the first reliable trigger of this.
+
+[22982.116427] ============================================
+[22982.116428] WARNING: possible recursive locking detected
+[22982.116429] 6.10.0-rc2+ #10 Tainted: G U W
+[22982.116430] --------------------------------------------
+[22982.116430] glxgears:sh0/5785 is trying to acquire lock:
+[22982.116431] ffff8c2bafa539a8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: dma_buf_detach+0x3b/0xf0
+[22982.116438]
+ but task is already holding lock:
+[22982.116438] ffff8c2d9aba6da8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: drm_exec_lock_obj+0x49/0x2b0 [drm_exec]
+[22982.116442]
+ other info that might help us debug this:
+[22982.116442] Possible unsafe locking scenario:
+
+[22982.116443] CPU0
+[22982.116444] ----
+[22982.116444] lock(reservation_ww_class_mutex);
+[22982.116445] lock(reservation_ww_class_mutex);
+[22982.116447]
+ *** DEADLOCK ***
+
+[22982.116447] May be due to missing lock nesting notation
+
+[22982.116448] 5 locks held by glxgears:sh0/5785:
+[22982.116449] #0: ffff8c2d9aba58c8 (&xef->vm.lock){+.+.}-{3:3}, at: xe_file_close+0xde/0x1c0 [xe]
+[22982.116507] #1: ffff8c2e28cc8480 (&vm->lock){++++}-{3:3}, at: xe_vm_close_and_put+0x161/0x9b0 [xe]
+[22982.116578] #2: ffff8c2e31982970 (&val->lock){.+.+}-{3:3}, at: xe_validation_ctx_init+0x6d/0x70 [xe]
+[22982.116647] #3: ffffacdc469478a8 (reservation_ww_class_acquire){+.+.}-{0:0}, at: xe_vma_destroy_unlocked+0x7f/0xe0 [xe]
+[22982.116716] #4: ffff8c2d9aba6da8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: drm_exec_lock_obj+0x49/0x2b0 [drm_exec]
+[22982.116719]
+ stack backtrace:
+[22982.116720] CPU: 8 PID: 5785 Comm: glxgears:sh0 Tainted: G U W 6.10.0-rc2+ #10
+[22982.116721] Hardware name: ASUS System Product Name/PRIME B560M-A AC, BIOS 2001 02/01/2023
+[22982.116723] Call Trace:
+[22982.116724] <TASK>
+[22982.116725] dump_stack_lvl+0x77/0xb0
+[22982.116727] __lock_acquire+0x1232/0x2160
+[22982.116730] lock_acquire+0xcb/0x2d0
+[22982.116732] ? dma_buf_detach+0x3b/0xf0
+[22982.116734] ? __lock_acquire+0x417/0x2160
+[22982.116736] __ww_mutex_lock.constprop.0+0xd0/0x13b0
+[22982.116738] ? dma_buf_detach+0x3b/0xf0
+[22982.116741] ? dma_buf_detach+0x3b/0xf0
+[22982.116743] ? ww_mutex_lock+0x2b/0x90
+[22982.116745] ww_mutex_lock+0x2b/0x90
+[22982.116747] dma_buf_detach+0x3b/0xf0
+[22982.116749] drm_prime_gem_destroy+0x2f/0x40 [drm]
+[22982.116775] xe_ttm_bo_destroy+0x32/0x220 [xe]
+[22982.116818] ? __mutex_unlock_slowpath+0x3a/0x290
+[22982.116821] drm_exec_unlock_all+0xa1/0xd0 [drm_exec]
+[22982.116823] drm_exec_fini+0x12/0xb0 [drm_exec]
+[22982.116824] xe_validation_ctx_fini+0x15/0x40 [xe]
+[22982.116892] xe_vma_destroy_unlocked+0xb1/0xe0 [xe]
+[22982.116959] xe_vm_close_and_put+0x41a/0x9b0 [xe]
+[22982.117025] ? xa_find+0xe3/0x1e0
+[22982.117028] xe_file_close+0x10a/0x1c0 [xe]
+[22982.117074] drm_file_free+0x22a/0x280 [drm]
+[22982.117099] drm_release_noglobal+0x22/0x70 [drm]
+[22982.117119] __fput+0xf1/0x2d0
+[22982.117122] task_work_run+0x59/0x90
+[22982.117125] do_exit+0x330/0xb40
+[22982.117127] do_group_exit+0x36/0xa0
+[22982.117129] get_signal+0xbd2/0xbe0
+[22982.117131] arch_do_signal_or_restart+0x3e/0x240
+[22982.117134] syscall_exit_to_user_mode+0x1e7/0x290
+[22982.117137] do_syscall_64+0xa1/0x180
+[22982.117139] ? lock_acquire+0xcb/0x2d0
+[22982.117140] ? __set_task_comm+0x28/0x1e0
+[22982.117141] ? find_held_lock+0x2b/0x80
+[22982.117144] ? __set_task_comm+0xe1/0x1e0
+[22982.117145] ? lock_release+0xca/0x290
+[22982.117147] ? __do_sys_prctl+0x245/0xab0
+[22982.117149] ? lockdep_hardirqs_on_prepare+0xde/0x190
+[22982.117150] ? syscall_exit_to_user_mode+0xb0/0x290
+[22982.117152] ? do_syscall_64+0xa1/0x180
+[22982.117154] ? __lock_acquire+0x417/0x2160
+[22982.117155] ? reacquire_held_locks+0xd1/0x1f0
+[22982.117156] ? do_user_addr_fault+0x30c/0x790
+[22982.117158] ? lock_acquire+0xcb/0x2d0
+[22982.117160] ? find_held_lock+0x2b/0x80
+[22982.117162] ? do_user_addr_fault+0x357/0x790
+[22982.117163] ? lock_release+0xca/0x290
+[22982.117164] ? do_user_addr_fault+0x361/0x790
+[22982.117166] ? trace_hardirqs_off+0x4b/0xc0
+[22982.117168] ? clear_bhb_loop+0x45/0xa0
+[22982.117170] ? clear_bhb_loop+0x45/0xa0
+[22982.117172] ? clear_bhb_loop+0x45/0xa0
+[22982.117174] entry_SYSCALL_64_after_hwframe+0x76/0x7e
+[22982.117176] RIP: 0033:0x7f943d267169
+[22982.117192] Code: Unable to access opcode bytes at 0x7f943d26713f.
+[22982.117193] RSP: 002b:00007f9430bffc80 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
+[22982.117195] RAX: fffffffffffffe00 RBX: 0000000000000000 RCX: 00007f943d267169
+[22982.117196] RDX: 0000000000000000 RSI: 0000000000000189 RDI: 00005622f89579d0
+[22982.117197] RBP: 00007f9430bffcb0 R08: 0000000000000000 R09: 00000000ffffffff
+[22982.117198] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
+[22982.117199] R13: 0000000000000000 R14: 0000000000000000 R15: 00005622f89579d0
+[22982.117202] </TASK>
+
+Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
+Cc: Christian König <christian.koenig@amd.com>
+Cc: Daniel Vetter <daniel@ffwll.ch>
+Cc: dri-devel@lists.freedesktop.org
+Cc: intel-xe@lists.freedesktop.org
+Cc: <stable@vger.kernel.org> # v6.8+
+Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
+Reviewed-by: Matthew Brost <matthew.brost@intel.com>
+Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+Reviewed-by: Christian König <christian.koenig@amd.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20240628153848.4989-1-thomas.hellstrom@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/ttm/ttm_bo.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
+index 6396dece0db1..2427be8bc97f 100644
+--- a/drivers/gpu/drm/ttm/ttm_bo.c
++++ b/drivers/gpu/drm/ttm/ttm_bo.c
+@@ -346,6 +346,7 @@ static void ttm_bo_release(struct kref *kref)
+ if (!dma_resv_test_signaled(bo->base.resv,
+ DMA_RESV_USAGE_BOOKKEEP) ||
+ (want_init_on_free() && (bo->ttm != NULL)) ||
++ bo->type == ttm_bo_type_sg ||
+ !dma_resv_trylock(bo->base.resv)) {
+ /* The BO is not idle, resurrect it for delayed destroy */
+ ttm_bo_flush_all_fences(bo);
+--
+2.45.2
+
--- /dev/null
+From fc932f51926698488f874ddf7d8f18483ca10271 Mon Sep 17 00:00:00 2001
+From: Matthew Auld <matthew.auld@intel.com>
+Date: Thu, 20 Jun 2024 11:20:26 +0100
+Subject: drm/xe: fix error handling in xe_migrate_update_pgtables
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Matthew Auld <matthew.auld@intel.com>
+
+commit fc932f51926698488f874ddf7d8f18483ca10271 upstream.
+
+Don't call drm_suballoc_free with sa_bo pointing to PTR_ERR.
+
+References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2120
+Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
+Signed-off-by: Matthew Auld <matthew.auld@intel.com>
+Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
+Cc: Matthew Brost <matthew.brost@intel.com>
+Cc: <stable@vger.kernel.org> # v6.8+
+Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20240620102025.127699-2-matthew.auld@intel.com
+(cherry picked from commit ce6b63336f79ec5f3996de65f452330e395f99ae)
+Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/xe/xe_migrate.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/drivers/gpu/drm/xe/xe_migrate.c
++++ b/drivers/gpu/drm/xe/xe_migrate.c
+@@ -1336,7 +1336,7 @@ xe_migrate_update_pgtables(struct xe_mig
+ GFP_KERNEL, true, 0);
+ if (IS_ERR(sa_bo)) {
+ err = PTR_ERR(sa_bo);
+- goto err;
++ goto err_bb;
+ }
+
+ ppgtt_ofs = NUM_KERNEL_PDE +
+@@ -1387,7 +1387,7 @@ xe_migrate_update_pgtables(struct xe_mig
+ update_idx);
+ if (IS_ERR(job)) {
+ err = PTR_ERR(job);
+- goto err_bb;
++ goto err_sa;
+ }
+
+ /* Wait on BO move */
+@@ -1436,12 +1436,12 @@ xe_migrate_update_pgtables(struct xe_mig
+
+ err_job:
+ xe_sched_job_put(job);
++err_sa:
++ drm_suballoc_free(sa_bo, NULL);
+ err_bb:
+ if (!q)
+ mutex_unlock(&m->job_mutex);
+ xe_bb_free(bb, NULL);
+-err:
+- drm_suballoc_free(sa_bo, NULL);
+ return ERR_PTR(err);
+ }
+
--- /dev/null
+From 3cad1bc010416c6dd780643476bc59ed742436b9 Mon Sep 17 00:00:00 2001
+From: Jann Horn <jannh@google.com>
+Date: Tue, 2 Jul 2024 18:26:52 +0200
+Subject: filelock: Remove locks reliably when fcntl/close race is detected
+
+From: Jann Horn <jannh@google.com>
+
+commit 3cad1bc010416c6dd780643476bc59ed742436b9 upstream.
+
+When fcntl_setlk() races with close(), it removes the created lock with
+do_lock_file_wait().
+However, LSMs can allow the first do_lock_file_wait() that created the lock
+while denying the second do_lock_file_wait() that tries to remove the lock.
+In theory (but AFAIK not in practice), posix_lock_file() could also fail to
+remove a lock due to GFP_KERNEL allocation failure (when splitting a range
+in the middle).
+
+After the bug has been triggered, use-after-free reads will occur in
+lock_get_status() when userspace reads /proc/locks. This can likely be used
+to read arbitrary kernel memory, but can't corrupt kernel memory.
+This only affects systems with SELinux / Smack / AppArmor / BPF-LSM in
+enforcing mode and only works from some security contexts.
+
+Fix it by calling locks_remove_posix() instead, which is designed to
+reliably get rid of POSIX locks associated with the given file and
+files_struct and is also used by filp_flush().
+
+Fixes: c293621bbf67 ("[PATCH] stale POSIX lock handling")
+Cc: stable@kernel.org
+Link: https://bugs.chromium.org/p/project-zero/issues/detail?id=2563
+Signed-off-by: Jann Horn <jannh@google.com>
+Link: https://lore.kernel.org/r/20240702-fs-lock-recover-2-v1-1-edd456f63789@google.com
+Reviewed-by: Jeff Layton <jlayton@kernel.org>
+Signed-off-by: Christian Brauner <brauner@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/locks.c | 9 ++++-----
+ 1 file changed, 4 insertions(+), 5 deletions(-)
+
+--- a/fs/locks.c
++++ b/fs/locks.c
+@@ -2448,8 +2448,9 @@ int fcntl_setlk(unsigned int fd, struct
+ error = do_lock_file_wait(filp, cmd, file_lock);
+
+ /*
+- * Attempt to detect a close/fcntl race and recover by releasing the
+- * lock that was just acquired. There is no need to do that when we're
++ * Detect close/fcntl races and recover by zapping all POSIX locks
++ * associated with this file and our files_struct, just like on
++ * filp_flush(). There is no need to do that when we're
+ * unlocking though, or for OFD locks.
+ */
+ if (!error && file_lock->c.flc_type != F_UNLCK &&
+@@ -2464,9 +2465,7 @@ int fcntl_setlk(unsigned int fd, struct
+ f = files_lookup_fd_locked(files, fd);
+ spin_unlock(&files->file_lock);
+ if (f != filp) {
+- file_lock->c.flc_type = F_UNLCK;
+- error = do_lock_file_wait(filp, cmd, file_lock);
+- WARN_ON_ONCE(error);
++ locks_remove_posix(filp, files);
+ error = -EBADF;
+ }
+ }
--- /dev/null
+From 3285d8f0a2ede604c368155c9c0921e16d41f70a Mon Sep 17 00:00:00 2001
+From: Thomas Zimmermann <tzimmermann@suse.de>
+Date: Tue, 25 Jun 2024 10:17:43 +0200
+Subject: firmware: sysfb: Fix reference count of sysfb parent device
+
+From: Thomas Zimmermann <tzimmermann@suse.de>
+
+commit 3285d8f0a2ede604c368155c9c0921e16d41f70a upstream.
+
+Retrieving the system framebuffer's parent device in sysfb_init()
+increments the parent device's reference count. Hence release the
+reference before leaving the init function.
+
+Adding the sysfb platform device acquires and additional reference
+for the parent. This keeps the parent device around while the system
+framebuffer is in use.
+
+Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
+Fixes: 9eac534db001 ("firmware/sysfb: Set firmware-framebuffer parent device")
+Cc: Thomas Zimmermann <tzimmermann@suse.de>
+Cc: Javier Martinez Canillas <javierm@redhat.com>
+Cc: Helge Deller <deller@gmx.de>
+Cc: Jani Nikula <jani.nikula@intel.com>
+Cc: Dan Carpenter <dan.carpenter@linaro.org>
+Cc: Arnd Bergmann <arnd@arndb.de>
+Cc: Sui Jingfeng <suijingfeng@loongson.cn>
+Cc: <stable@vger.kernel.org> # v6.9+
+Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20240625081818.15696-1-tzimmermann@suse.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/firmware/sysfb.c | 12 ++++++++----
+ 1 file changed, 8 insertions(+), 4 deletions(-)
+
+--- a/drivers/firmware/sysfb.c
++++ b/drivers/firmware/sysfb.c
+@@ -101,8 +101,10 @@ static __init struct device *sysfb_paren
+ if (IS_ERR(pdev)) {
+ return ERR_CAST(pdev);
+ } else if (pdev) {
+- if (!sysfb_pci_dev_is_enabled(pdev))
++ if (!sysfb_pci_dev_is_enabled(pdev)) {
++ pci_dev_put(pdev);
+ return ERR_PTR(-ENODEV);
++ }
+ return &pdev->dev;
+ }
+
+@@ -137,7 +139,7 @@ static __init int sysfb_init(void)
+ if (compatible) {
+ pd = sysfb_create_simplefb(si, &mode, parent);
+ if (!IS_ERR(pd))
+- goto unlock_mutex;
++ goto put_device;
+ }
+
+ /* if the FB is incompatible, create a legacy framebuffer device */
+@@ -155,7 +157,7 @@ static __init int sysfb_init(void)
+ pd = platform_device_alloc(name, 0);
+ if (!pd) {
+ ret = -ENOMEM;
+- goto unlock_mutex;
++ goto put_device;
+ }
+
+ pd->dev.parent = parent;
+@@ -170,9 +172,11 @@ static __init int sysfb_init(void)
+ if (ret)
+ goto err;
+
+- goto unlock_mutex;
++ goto put_device;
+ err:
+ platform_device_put(pd);
++put_device:
++ put_device(parent);
+ unlock_mutex:
+ mutex_unlock(&disable_lock);
+ return ret;
--- /dev/null
+From 2ae4db5647d807efb6a87c09efaa6d1db9c905d7 Mon Sep 17 00:00:00 2001
+From: Christian Brauner <brauner@kernel.org>
+Date: Thu, 13 Jun 2024 11:38:14 +0200
+Subject: fs: don't misleadingly warn during thaw operations
+
+From: Christian Brauner <brauner@kernel.org>
+
+commit 2ae4db5647d807efb6a87c09efaa6d1db9c905d7 upstream.
+
+The block device may have been frozen before it was claimed by a
+filesystem. Concurrently another process might try to mount that
+frozen block device and has temporarily claimed the block device for
+that purpose causing a concurrent fs_bdev_thaw() to end up here. The
+mounter is already about to abort mounting because they still saw an
+elevanted bdev->bd_fsfreeze_count so get_bdev_super() will return
+NULL in that case.
+
+For example, P1 calls dm_suspend() which calls into bdev_freeze() before
+the block device has been claimed by the filesystem. This brings
+bdev->bd_fsfreeze_count to 1 and no call into fs_bdev_freeze() is
+required.
+
+Now P2 tries to mount that frozen block device. It claims it and checks
+bdev->bd_fsfreeze_count. As it's elevated it aborts mounting.
+
+In the meantime P3 called dm_resume(). P3 sees that the block device is
+already claimed by a filesystem and calls into fs_bdev_thaw().
+
+P3 takes a passive reference and realizes that the filesystem isn't
+ready yet. P3 puts itself to sleep to wait for the filesystem to become
+ready.
+
+P2 now puts the last active reference to the filesystem and marks it as
+dying. P3 gets woken, sees that the filesystem is dying and
+get_bdev_super() fails.
+
+Fixes: 49ef8832fb1a ("bdev: implement freeze and thaw holder operations")
+Cc: <stable@vger.kernel.org>
+Reported-by: Theodore Ts'o <tytso@mit.edu>
+Link: https://lore.kernel.org/r/20240611085210.GA1838544@mit.edu
+Link: https://lore.kernel.org/r/20240613-lackmantel-einsehen-90f0d727358d@brauner
+Reviewed-by: Darrick J. Wong <djwong@kernel.org>
+Signed-off-by: Christian Brauner <brauner@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/super.c | 11 ++++++++++-
+ 1 file changed, 10 insertions(+), 1 deletion(-)
+
+--- a/fs/super.c
++++ b/fs/super.c
+@@ -1501,8 +1501,17 @@ static int fs_bdev_thaw(struct block_dev
+
+ lockdep_assert_held(&bdev->bd_fsfreeze_mutex);
+
++ /*
++ * The block device may have been frozen before it was claimed by a
++ * filesystem. Concurrently another process might try to mount that
++ * frozen block device and has temporarily claimed the block device for
++ * that purpose causing a concurrent fs_bdev_thaw() to end up here. The
++ * mounter is already about to abort mounting because they still saw an
++ * elevanted bdev->bd_fsfreeze_count so get_bdev_super() will return
++ * NULL in that case.
++ */
+ sb = get_bdev_super(bdev);
+- if (WARN_ON_ONCE(!sb))
++ if (!sb)
+ return -EINVAL;
+
+ if (sb->s_op->thaw_super)
--- /dev/null
+From 8754d9835683e8fab9a8305acdb38a3aeb9d20bd Mon Sep 17 00:00:00 2001
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+Date: Thu, 16 May 2024 15:13:20 +0200
+Subject: mtd: rawnand: Bypass a couple of sanity checks during NAND identification
+
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+
+commit 8754d9835683e8fab9a8305acdb38a3aeb9d20bd upstream.
+
+Early during NAND identification, mtd_info fields have not yet been
+initialized (namely, writesize and oobsize) and thus cannot be used for
+sanity checks yet. Of course if there is a misuse of
+nand_change_read_column_op() so early we won't be warned, but there is
+anyway no actual check to perform at this stage as we do not yet know
+the NAND geometry.
+
+So, if the fields are empty, especially mtd->writesize which is *always*
+set quite rapidly after identification, let's skip the sanity checks.
+
+nand_change_read_column_op() is subject to be used early for ONFI/JEDEC
+identification in the very unlikely case of:
+- bitflips appearing in the parameter page,
+- the controller driver not supporting simple DATA_IN cycles.
+
+As nand_change_read_column_op() uses nand_fill_column_cycles() the logic
+explaind above also applies in this secondary helper.
+
+Fixes: c27842e7e11f ("mtd: rawnand: onfi: Adapt the parameter page read to constraint controllers")
+Fixes: daca31765e8b ("mtd: rawnand: jedec: Adapt the parameter page read to constraint controllers")
+Cc: stable@vger.kernel.org
+Reported-by: Alexander Dahl <ada@thorsis.com>
+Closes: https://lore.kernel.org/linux-mtd/20240306-shaky-bunion-d28b65ea97d7@thorsis.com/
+Reported-by: Steven Seeger <steven.seeger@flightsystems.net>
+Closes: https://lore.kernel.org/linux-mtd/DM6PR05MB4506554457CF95191A670BDEF7062@DM6PR05MB4506.namprd05.prod.outlook.com/
+Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Tested-by: Sascha Hauer <s.hauer@pengutronix.de>
+Link: https://lore.kernel.org/linux-mtd/20240516131320.579822-3-miquel.raynal@bootlin.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mtd/nand/raw/nand_base.c | 57 +++++++++++++++++++++------------------
+ 1 file changed, 32 insertions(+), 25 deletions(-)
+
+--- a/drivers/mtd/nand/raw/nand_base.c
++++ b/drivers/mtd/nand/raw/nand_base.c
+@@ -1093,28 +1093,32 @@ static int nand_fill_column_cycles(struc
+ unsigned int offset_in_page)
+ {
+ struct mtd_info *mtd = nand_to_mtd(chip);
++ bool ident_stage = !mtd->writesize;
+
+- /* Make sure the offset is less than the actual page size. */
+- if (offset_in_page > mtd->writesize + mtd->oobsize)
+- return -EINVAL;
+-
+- /*
+- * On small page NANDs, there's a dedicated command to access the OOB
+- * area, and the column address is relative to the start of the OOB
+- * area, not the start of the page. Asjust the address accordingly.
+- */
+- if (mtd->writesize <= 512 && offset_in_page >= mtd->writesize)
+- offset_in_page -= mtd->writesize;
+-
+- /*
+- * The offset in page is expressed in bytes, if the NAND bus is 16-bit
+- * wide, then it must be divided by 2.
+- */
+- if (chip->options & NAND_BUSWIDTH_16) {
+- if (WARN_ON(offset_in_page % 2))
++ /* Bypass all checks during NAND identification */
++ if (likely(!ident_stage)) {
++ /* Make sure the offset is less than the actual page size. */
++ if (offset_in_page > mtd->writesize + mtd->oobsize)
+ return -EINVAL;
+
+- offset_in_page /= 2;
++ /*
++ * On small page NANDs, there's a dedicated command to access the OOB
++ * area, and the column address is relative to the start of the OOB
++ * area, not the start of the page. Asjust the address accordingly.
++ */
++ if (mtd->writesize <= 512 && offset_in_page >= mtd->writesize)
++ offset_in_page -= mtd->writesize;
++
++ /*
++ * The offset in page is expressed in bytes, if the NAND bus is 16-bit
++ * wide, then it must be divided by 2.
++ */
++ if (chip->options & NAND_BUSWIDTH_16) {
++ if (WARN_ON(offset_in_page % 2))
++ return -EINVAL;
++
++ offset_in_page /= 2;
++ }
+ }
+
+ addrs[0] = offset_in_page;
+@@ -1123,7 +1127,7 @@ static int nand_fill_column_cycles(struc
+ * Small page NANDs use 1 cycle for the columns, while large page NANDs
+ * need 2
+ */
+- if (mtd->writesize <= 512)
++ if (!ident_stage && mtd->writesize <= 512)
+ return 1;
+
+ addrs[1] = offset_in_page >> 8;
+@@ -1436,16 +1440,19 @@ int nand_change_read_column_op(struct na
+ unsigned int len, bool force_8bit)
+ {
+ struct mtd_info *mtd = nand_to_mtd(chip);
++ bool ident_stage = !mtd->writesize;
+
+ if (len && !buf)
+ return -EINVAL;
+
+- if (offset_in_page + len > mtd->writesize + mtd->oobsize)
+- return -EINVAL;
++ if (!ident_stage) {
++ if (offset_in_page + len > mtd->writesize + mtd->oobsize)
++ return -EINVAL;
+
+- /* Small page NANDs do not support column change. */
+- if (mtd->writesize <= 512)
+- return -ENOTSUPP;
++ /* Small page NANDs do not support column change. */
++ if (mtd->writesize <= 512)
++ return -ENOTSUPP;
++ }
+
+ if (nand_has_exec_op(chip)) {
+ const struct nand_interface_config *conf =
--- /dev/null
+From 3a1b777eb9fb75d09c45ae5dd1d007eddcbebf1f Mon Sep 17 00:00:00 2001
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+Date: Tue, 7 May 2024 10:58:42 +0200
+Subject: mtd: rawnand: Ensure ECC configuration is propagated to upper layers
+
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+
+commit 3a1b777eb9fb75d09c45ae5dd1d007eddcbebf1f upstream.
+
+Until recently the "upper layer" was MTD. But following incremental
+reworks to bring spi-nand support and more recently generic ECC support,
+there is now an intermediate "generic NAND" layer that also needs to get
+access to some values. When using "converted" ECC engines, like the
+software ones, these values are already propagated correctly. But
+otherwise when using good old raw NAND controller drivers, we need to
+manually set these values ourselves at the end of the "scan" operation,
+once these values have been negotiated.
+
+Without this propagation, later (generic) checks like the one warning
+users that the ECC strength is not high enough might simply no longer
+work.
+
+Fixes: 8c126720fe10 ("mtd: rawnand: Use the ECC framework nand_ecc_is_strong_enough() helper")
+Cc: stable@vger.kernel.org
+Reported-by: Sascha Hauer <s.hauer@pengutronix.de>
+Closes: https://lore.kernel.org/all/Zhe2JtvvN1M4Ompw@pengutronix.de/
+Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Tested-by: Sascha Hauer <s.hauer@pengutronix.de>
+Link: https://lore.kernel.org/linux-mtd/20240507085842.108844-1-miquel.raynal@bootlin.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mtd/nand/raw/nand_base.c | 9 ++++++++-
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+--- a/drivers/mtd/nand/raw/nand_base.c
++++ b/drivers/mtd/nand/raw/nand_base.c
+@@ -6301,6 +6301,7 @@ static const struct nand_ops rawnand_ops
+ static int nand_scan_tail(struct nand_chip *chip)
+ {
+ struct mtd_info *mtd = nand_to_mtd(chip);
++ struct nand_device *base = &chip->base;
+ struct nand_ecc_ctrl *ecc = &chip->ecc;
+ int ret, i;
+
+@@ -6445,9 +6446,13 @@ static int nand_scan_tail(struct nand_ch
+ if (!ecc->write_oob_raw)
+ ecc->write_oob_raw = ecc->write_oob;
+
+- /* propagate ecc info to mtd_info */
++ /* Propagate ECC info to the generic NAND and MTD layers */
+ mtd->ecc_strength = ecc->strength;
++ if (!base->ecc.ctx.conf.strength)
++ base->ecc.ctx.conf.strength = ecc->strength;
+ mtd->ecc_step_size = ecc->size;
++ if (!base->ecc.ctx.conf.step_size)
++ base->ecc.ctx.conf.step_size = ecc->size;
+
+ /*
+ * Set the number of read / write steps for one page depending on ECC
+@@ -6455,6 +6460,8 @@ static int nand_scan_tail(struct nand_ch
+ */
+ if (!ecc->steps)
+ ecc->steps = mtd->writesize / ecc->size;
++ if (!base->ecc.ctx.nsteps)
++ base->ecc.ctx.nsteps = ecc->steps;
+ if (ecc->steps * ecc->size != mtd->writesize) {
+ WARN(1, "Invalid ECC parameters\n");
+ ret = -EINVAL;
--- /dev/null
+From 5da39530d19946f6241de84d1db69da2f5c61da7 Mon Sep 17 00:00:00 2001
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+Date: Thu, 16 May 2024 15:13:19 +0200
+Subject: mtd: rawnand: Fix the nand_read_data_op() early check
+
+From: Miquel Raynal <miquel.raynal@bootlin.com>
+
+commit 5da39530d19946f6241de84d1db69da2f5c61da7 upstream.
+
+The nand_read_data_op() operation, which only consists in DATA_IN
+cycles, is sadly not supported by all controllers despite being very
+basic. The core, for some time, supposed all drivers would support
+it. An improvement to this situation for supporting more constrained
+controller added a check to verify if the operation was supported before
+attempting it by running the function with the check_only boolean set
+first, and then possibly falling back to another (possibly slightly less
+optimized) alternative.
+
+An even newer addition moved that check very early and probe time, in
+order to perform the check only once. The content of the operation was
+not so important, as long as the controller driver would tell whether
+such operation on the NAND bus would be possible or not. In practice, no
+buffer was provided (no fake buffer or whatever) as it is anyway not
+relevant for the "check_only" condition. Unfortunately, early in the
+function, there is an if statement verifying that the input parameters
+are right for normal use, making the early check always unsuccessful.
+
+Fixes: 9f820fc0651c ("mtd: rawnand: Check the data only read pattern only once")
+Cc: stable@vger.kernel.org
+Reported-by: Alexander Dahl <ada@thorsis.com>
+Closes: https://lore.kernel.org/linux-mtd/20240306-shaky-bunion-d28b65ea97d7@thorsis.com/
+Reported-by: Steven Seeger <steven.seeger@flightsystems.net>
+Closes: https://lore.kernel.org/linux-mtd/DM6PR05MB4506554457CF95191A670BDEF7062@DM6PR05MB4506.namprd05.prod.outlook.com/
+Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Reviewed-by: Alexander Dahl <ada@thorsis.com>
+Link: https://lore.kernel.org/linux-mtd/20240516131320.579822-2-miquel.raynal@bootlin.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mtd/nand/raw/nand_base.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/mtd/nand/raw/nand_base.c
++++ b/drivers/mtd/nand/raw/nand_base.c
+@@ -2173,7 +2173,7 @@ EXPORT_SYMBOL_GPL(nand_reset_op);
+ int nand_read_data_op(struct nand_chip *chip, void *buf, unsigned int len,
+ bool force_8bit, bool check_only)
+ {
+- if (!len || !buf)
++ if (!len || (!check_only && !buf))
+ return -EINVAL;
+
+ if (nand_has_exec_op(chip)) {
--- /dev/null
+From b27d8946b5edd9827ee3c2f9ea1dd30022fb1ebe Mon Sep 17 00:00:00 2001
+From: Val Packett <val@packett.cool>
+Date: Sun, 19 May 2024 00:13:39 -0300
+Subject: mtd: rawnand: rockchip: ensure NVDDR timings are rejected
+
+From: Val Packett <val@packett.cool>
+
+commit b27d8946b5edd9827ee3c2f9ea1dd30022fb1ebe upstream.
+
+.setup_interface first gets called with a "target" value of
+NAND_DATA_IFACE_CHECK_ONLY, in which case an error is expected
+if the controller driver does not support the timing mode (NVDDR).
+
+Fixes: a9ecc8c814e9 ("mtd: rawnand: Choose the best timings, NV-DDR included")
+Signed-off-by: Val Packett <val@packett.cool>
+Cc: stable@vger.kernel.org
+Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Link: https://lore.kernel.org/linux-mtd/20240519031409.26464-1-val@packett.cool
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/mtd/nand/raw/rockchip-nand-controller.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/mtd/nand/raw/rockchip-nand-controller.c
++++ b/drivers/mtd/nand/raw/rockchip-nand-controller.c
+@@ -420,13 +420,13 @@ static int rk_nfc_setup_interface(struct
+ u32 rate, tc2rw, trwpw, trw2c;
+ u32 temp;
+
+- if (target < 0)
+- return 0;
+-
+ timings = nand_get_sdr_timings(conf);
+ if (IS_ERR(timings))
+ return -EOPNOTSUPP;
+
++ if (target < 0)
++ return 0;
++
+ if (IS_ERR(nfc->nfc_clk))
+ rate = clk_get_rate(nfc->ahb_clk);
+ else
--- /dev/null
+From b698ab56837bc9e666b7e7e12e9c28fe1d6a763c Mon Sep 17 00:00:00 2001
+From: Yijie Yang <quic_yijiyang@quicinc.com>
+Date: Mon, 1 Jul 2024 09:47:20 +0800
+Subject: net: stmmac: dwmac-qcom-ethqos: fix error array size
+
+From: Yijie Yang <quic_yijiyang@quicinc.com>
+
+commit b698ab56837bc9e666b7e7e12e9c28fe1d6a763c upstream.
+
+Correct member @num_por with size of right array @emac_v4_0_0_por for
+struct ethqos_emac_driver_data @emac_v4_0_0_data.
+
+Cc: stable@vger.kernel.org
+Fixes: 8c4d92e82d50 ("net: stmmac: dwmac-qcom-ethqos: add support for emac4 on sa8775p platforms")
+Signed-off-by: Yijie Yang <quic_yijiyang@quicinc.com>
+Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
+Link: https://patch.msgid.link/20240701014720.2547856-1-quic_yijiyang@quicinc.com
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
++++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
+@@ -272,7 +272,7 @@ static const struct ethqos_emac_por emac
+
+ static const struct ethqos_emac_driver_data emac_v4_0_0_data = {
+ .por = emac_v4_0_0_por,
+- .num_por = ARRAY_SIZE(emac_v3_0_0_por),
++ .num_por = ARRAY_SIZE(emac_v4_0_0_por),
+ .rgmii_config_loopback_en = false,
+ .has_emac_ge_3 = true,
+ .link_clk_name = "phyaux",
--- /dev/null
+From 13fc6c175924eaa953cf597ce28ffa4edc4554a6 Mon Sep 17 00:00:00 2001
+From: Jinglin Wen <jinglin.wen@shingroup.cn>
+Date: Thu, 20 Jun 2024 10:41:50 +0800
+Subject: powerpc/64s: Fix unnecessary copy to 0 when kernel is booted at address 0
+
+From: Jinglin Wen <jinglin.wen@shingroup.cn>
+
+commit 13fc6c175924eaa953cf597ce28ffa4edc4554a6 upstream.
+
+According to the code logic, when the kernel is loaded at address 0, no
+copying operation should be performed, but it is currently being done.
+
+This patch fixes the issue where the kernel code was incorrectly
+duplicated to address 0 when booting from address 0.
+
+Fixes: b270bebd34e3 ("powerpc/64s: Run at the kernel virtual address earlier in boot")
+Cc: stable@vger.kernel.org # v6.4+
+Signed-off-by: Jinglin Wen <jinglin.wen@shingroup.cn>
+Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://msgid.link/20240620024150.14857-1-jinglin.wen@shingroup.cn
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/powerpc/kernel/head_64.S | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/arch/powerpc/kernel/head_64.S
++++ b/arch/powerpc/kernel/head_64.S
+@@ -647,8 +647,9 @@ __after_prom_start:
+ * Note: This process overwrites the OF exception vectors.
+ */
+ LOAD_REG_IMMEDIATE(r3, PAGE_OFFSET)
+- mr. r4,r26 /* In some cases the loader may */
+- beq 9f /* have already put us at zero */
++ mr r4,r26 /* Load the virtual source address into r4 */
++ cmpld r3,r4 /* Check if source == dest */
++ beq 9f /* If so skip the copy */
+ li r6,0x100 /* Start offset, the first 0x100 */
+ /* bytes were copied earlier. */
+
--- /dev/null
+From 21a741eb75f80397e5f7d3739e24d7d75e619011 Mon Sep 17 00:00:00 2001
+From: Nicholas Piggin <npiggin@gmail.com>
+Date: Tue, 25 Jun 2024 23:40:47 +1000
+Subject: powerpc/pseries: Fix scv instruction crash with kexec
+
+From: Nicholas Piggin <npiggin@gmail.com>
+
+commit 21a741eb75f80397e5f7d3739e24d7d75e619011 upstream.
+
+kexec on pseries disables AIL (reloc_on_exc), required for scv
+instruction support, before other CPUs have been shut down. This means
+they can execute scv instructions after AIL is disabled, which causes an
+interrupt at an unexpected entry location that crashes the kernel.
+
+Change the kexec sequence to disable AIL after other CPUs have been
+brought down.
+
+As a refresher, the real-mode scv interrupt vector is 0x17000, and the
+fixed-location head code probably couldn't easily deal with implementing
+such high addresses so it was just decided not to support that interrupt
+at all.
+
+Fixes: 7fa95f9adaee ("powerpc/64s: system call support for scv/rfscv instructions")
+Cc: stable@vger.kernel.org # v5.9+
+Reported-by: Sourabh Jain <sourabhjain@linux.ibm.com>
+Closes: https://lore.kernel.org/3b4b2943-49ad-4619-b195-bc416f1d1409@linux.ibm.com
+Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
+Tested-by: Gautam Menghani <gautam@linux.ibm.com>
+Tested-by: Sourabh Jain <sourabhjain@linux.ibm.com>
+Link: https://msgid.link/20240625134047.298759-1-npiggin@gmail.com
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/powerpc/kexec/core_64.c | 11 +++++++++++
+ arch/powerpc/platforms/pseries/kexec.c | 8 --------
+ arch/powerpc/platforms/pseries/pseries.h | 1 -
+ arch/powerpc/platforms/pseries/setup.c | 1 -
+ 4 files changed, 11 insertions(+), 10 deletions(-)
+
+--- a/arch/powerpc/kexec/core_64.c
++++ b/arch/powerpc/kexec/core_64.c
+@@ -26,6 +26,7 @@
+ #include <asm/paca.h>
+ #include <asm/mmu.h>
+ #include <asm/sections.h> /* _end */
++#include <asm/setup.h>
+ #include <asm/smp.h>
+ #include <asm/hw_breakpoint.h>
+ #include <asm/svm.h>
+@@ -315,6 +316,16 @@ void default_machine_kexec(struct kimage
+ if (!kdump_in_progress())
+ kexec_prepare_cpus();
+
++#ifdef CONFIG_PPC_PSERIES
++ /*
++ * This must be done after other CPUs have shut down, otherwise they
++ * could execute the 'scv' instruction, which is not supported with
++ * reloc disabled (see configure_exceptions()).
++ */
++ if (firmware_has_feature(FW_FEATURE_SET_MODE))
++ pseries_disable_reloc_on_exc();
++#endif
++
+ printk("kexec: Starting switchover sequence.\n");
+
+ /* switch to a staticly allocated stack. Based on irq stack code.
+--- a/arch/powerpc/platforms/pseries/kexec.c
++++ b/arch/powerpc/platforms/pseries/kexec.c
+@@ -61,11 +61,3 @@ void pseries_kexec_cpu_down(int crash_sh
+ } else
+ xics_kexec_teardown_cpu(secondary);
+ }
+-
+-void pseries_machine_kexec(struct kimage *image)
+-{
+- if (firmware_has_feature(FW_FEATURE_SET_MODE))
+- pseries_disable_reloc_on_exc();
+-
+- default_machine_kexec(image);
+-}
+--- a/arch/powerpc/platforms/pseries/pseries.h
++++ b/arch/powerpc/platforms/pseries/pseries.h
+@@ -38,7 +38,6 @@ static inline void smp_init_pseries(void
+ #endif
+
+ extern void pseries_kexec_cpu_down(int crash_shutdown, int secondary);
+-void pseries_machine_kexec(struct kimage *image);
+
+ extern void pSeries_final_fixup(void);
+
+--- a/arch/powerpc/platforms/pseries/setup.c
++++ b/arch/powerpc/platforms/pseries/setup.c
+@@ -1159,7 +1159,6 @@ define_machine(pseries) {
+ .machine_check_exception = pSeries_machine_check_exception,
+ .machine_check_log_err = pSeries_machine_check_log_err,
+ #ifdef CONFIG_KEXEC_CORE
+- .machine_kexec = pseries_machine_kexec,
+ .kexec_cpu_down = pseries_kexec_cpu_down,
+ #endif
+ #ifdef CONFIG_MEMORY_HOTPLUG
--- /dev/null
+From 30139c702048f1097342a31302cbd3d478f50c63 Mon Sep 17 00:00:00 2001
+From: Jan Kara <jack@suse.cz>
+Date: Fri, 21 Jun 2024 16:42:37 +0200
+Subject: Revert "mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again"
+
+From: Jan Kara <jack@suse.cz>
+
+commit 30139c702048f1097342a31302cbd3d478f50c63 upstream.
+
+Patch series "mm: Avoid possible overflows in dirty throttling".
+
+Dirty throttling logic assumes dirty limits in page units fit into
+32-bits. This patch series makes sure this is true (see patch 2/2 for
+more details).
+
+
+This patch (of 2):
+
+This reverts commit 9319b647902cbd5cc884ac08a8a6d54ce111fc78.
+
+The commit is broken in several ways. Firstly, the removed (u64) cast
+from the multiplication will introduce a multiplication overflow on 32-bit
+archs if wb_thresh * bg_thresh >= 1<<32 (which is actually common - the
+default settings with 4GB of RAM will trigger this). Secondly, the
+div64_u64() is unnecessarily expensive on 32-bit archs. We have
+div64_ul() in case we want to be safe & cheap. Thirdly, if dirty
+thresholds are larger than 1<<32 pages, then dirty balancing is going to
+blow up in many other spectacular ways anyway so trying to fix one
+possible overflow is just moot.
+
+Link: https://lkml.kernel.org/r/20240621144017.30993-1-jack@suse.cz
+Link: https://lkml.kernel.org/r/20240621144246.11148-1-jack@suse.cz
+Fixes: 9319b647902c ("mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again")
+Signed-off-by: Jan Kara <jack@suse.cz>
+Reviewed-By: Zach O'Keefe <zokeefe@google.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/page-writeback.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/mm/page-writeback.c
++++ b/mm/page-writeback.c
+@@ -1660,7 +1660,7 @@ static inline void wb_dirty_limits(struc
+ */
+ dtc->wb_thresh = __wb_calc_thresh(dtc);
+ dtc->wb_bg_thresh = dtc->thresh ?
+- div64_u64(dtc->wb_thresh * dtc->bg_thresh, dtc->thresh) : 0;
++ div_u64((u64)dtc->wb_thresh * dtc->bg_thresh, dtc->thresh) : 0;
+
+ /*
+ * In order to avoid the stacked BDI deadlock we need
--- /dev/null
+From b3a58f3b90f564f42a5c35778d8c5107b2c2150b Mon Sep 17 00:00:00 2001
+From: Stefan Haberland <sth@linux.ibm.com>
+Date: Wed, 3 Jul 2024 11:23:12 +0200
+Subject: s390/dasd: Fix invalid dereferencing of indirect CCW data pointer
+
+From: Stefan Haberland <sth@linux.ibm.com>
+
+commit b3a58f3b90f564f42a5c35778d8c5107b2c2150b upstream.
+
+Fix invalid dereferencing of indirect CCW data pointer in
+dasd_eckd_dump_sense() that leads to a kernel panic in error cases.
+
+When using indirect addressing for DASD CCWs (IDAW) the CCW CDA pointer
+does not contain the data address itself but a pointer to the IDAL.
+This needs to be translated from physical to virtual as well before
+using it.
+
+This dereferencing is also used for dasd_page_cache and also fixed
+although it is very unlikely that this code path ever gets used.
+
+Fixes: c0bd39601c13 ("s390/dasd: use new address translation helpers")
+Cc: stable@vger.kernel.org
+Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
+Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
+Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/s390/block/dasd_eckd.c | 4 ++--
+ drivers/s390/block/dasd_fba.c | 2 +-
+ 2 files changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/s390/block/dasd_eckd.c b/drivers/s390/block/dasd_eckd.c
+index 2f16f543079b..a76c6af9ea63 100644
+--- a/drivers/s390/block/dasd_eckd.c
++++ b/drivers/s390/block/dasd_eckd.c
+@@ -4906,7 +4906,7 @@ dasd_eckd_free_cp(struct dasd_ccw_req *cqr, struct request *req)
+ ccw++;
+ if (dst) {
+ if (ccw->flags & CCW_FLAG_IDA)
+- cda = *((char **)dma32_to_virt(ccw->cda));
++ cda = dma64_to_virt(*((dma64_t *)dma32_to_virt(ccw->cda)));
+ else
+ cda = dma32_to_virt(ccw->cda);
+ if (dst != cda) {
+@@ -5525,7 +5525,7 @@ dasd_eckd_dump_ccw_range(struct dasd_device *device, struct ccw1 *from,
+
+ /* get pointer to data (consider IDALs) */
+ if (from->flags & CCW_FLAG_IDA)
+- datap = (char *)*((addr_t *)dma32_to_virt(from->cda));
++ datap = dma64_to_virt(*((dma64_t *)dma32_to_virt(from->cda)));
+ else
+ datap = dma32_to_virt(from->cda);
+
+diff --git a/drivers/s390/block/dasd_fba.c b/drivers/s390/block/dasd_fba.c
+index 361e9bd75257..9f2023a077c2 100644
+--- a/drivers/s390/block/dasd_fba.c
++++ b/drivers/s390/block/dasd_fba.c
+@@ -585,7 +585,7 @@ dasd_fba_free_cp(struct dasd_ccw_req *cqr, struct request *req)
+ ccw++;
+ if (dst) {
+ if (ccw->flags & CCW_FLAG_IDA)
+- cda = *((char **)dma32_to_virt(ccw->cda));
++ cda = dma64_to_virt(*((dma64_t *)dma32_to_virt(ccw->cda)));
+ else
+ cda = dma32_to_virt(ccw->cda);
+ if (dst != cda) {
+--
+2.45.2
+
--- /dev/null
+From 130e42806773013e9cf32d211922c935ae2df86c Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Micka=C3=ABl=20Sala=C3=BCn?= <mic@digikod.net>
+Date: Fri, 21 Jun 2024 20:06:05 +0200
+Subject: selftests/harness: Fix tests timeout and race condition
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Mickaël Salaün <mic@digikod.net>
+
+commit 130e42806773013e9cf32d211922c935ae2df86c upstream.
+
+We cannot use CLONE_VFORK because we also need to wait for the timeout
+signal.
+
+Restore tests timeout by using the original fork() call in __run_test()
+but also in __TEST_F_IMPL(). Also fix a race condition when waiting for
+the test child process.
+
+Because test metadata are shared between test processes, only the
+parent process must set the test PID (child). Otherwise, t->pid may be
+set to zero, leading to inconsistent error cases:
+
+ # RUN layout1.rule_on_mountpoint ...
+ # rule_on_mountpoint: Test ended in some other way [127]
+ # OK layout1.rule_on_mountpoint
+ ok 20 layout1.rule_on_mountpoint
+
+As safeguards, initialize the "status" variable with a valid exit code,
+and handle unknown test exits as errors.
+
+The use of fork() introduces a new race condition in landlock/fs_test.c
+which seems to be specific to hostfs bind mounts, but I haven't found
+the root cause and it's difficult to trigger. I'll try to fix it with
+another patch.
+
+Cc: Christian Brauner <brauner@kernel.org>
+Cc: Günther Noack <gnoack@google.com>
+Cc: Jakub Kicinski <kuba@kernel.org>
+Cc: Kees Cook <keescook@chromium.org>
+Cc: Shuah Khan <shuah@kernel.org>
+Cc: Will Drewry <wad@chromium.org>
+Cc: stable@vger.kernel.org
+Closes: https://lore.kernel.org/r/9341d4db-5e21-418c-bf9e-9ae2da7877e1@sirena.org.uk
+Fixes: a86f18903db9 ("selftests/harness: Fix interleaved scheduling leading to race conditions")
+Fixes: 24cf65a62266 ("selftests/harness: Share _metadata between forked processes")
+Link: https://lore.kernel.org/r/20240621180605.834676-1-mic@digikod.net
+Tested-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Mickaël Salaün <mic@digikod.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ tools/testing/selftests/kselftest_harness.h | 43 +++++++++++++++-------------
+ 1 file changed, 24 insertions(+), 19 deletions(-)
+
+--- a/tools/testing/selftests/kselftest_harness.h
++++ b/tools/testing/selftests/kselftest_harness.h
+@@ -66,8 +66,6 @@
+ #include <sys/wait.h>
+ #include <unistd.h>
+ #include <setjmp.h>
+-#include <syscall.h>
+-#include <linux/sched.h>
+
+ #include "kselftest.h"
+
+@@ -82,17 +80,6 @@
+ # define TH_LOG_ENABLED 1
+ #endif
+
+-/* Wait for the child process to end but without sharing memory mapping. */
+-static inline pid_t clone3_vfork(void)
+-{
+- struct clone_args args = {
+- .flags = CLONE_VFORK,
+- .exit_signal = SIGCHLD,
+- };
+-
+- return syscall(__NR_clone3, &args, sizeof(args));
+-}
+-
+ /**
+ * TH_LOG()
+ *
+@@ -437,7 +424,7 @@ static inline pid_t clone3_vfork(void)
+ } \
+ if (setjmp(_metadata->env) == 0) { \
+ /* _metadata and potentially self are shared with all forks. */ \
+- child = clone3_vfork(); \
++ child = fork(); \
+ if (child == 0) { \
+ fixture_name##_setup(_metadata, self, variant->data); \
+ /* Let setup failure terminate early. */ \
+@@ -1016,7 +1003,14 @@ void __wait_for_test(struct __test_metad
+ .sa_flags = SA_SIGINFO,
+ };
+ struct sigaction saved_action;
+- int status;
++ /*
++ * Sets status so that WIFEXITED(status) returns true and
++ * WEXITSTATUS(status) returns KSFT_FAIL. This safe default value
++ * should never be evaluated because of the waitpid(2) check and
++ * SIGALRM handling.
++ */
++ int status = KSFT_FAIL << 8;
++ int child;
+
+ if (sigaction(SIGALRM, &action, &saved_action)) {
+ t->exit_code = KSFT_FAIL;
+@@ -1028,7 +1022,15 @@ void __wait_for_test(struct __test_metad
+ __active_test = t;
+ t->timed_out = false;
+ alarm(t->timeout);
+- waitpid(t->pid, &status, 0);
++ child = waitpid(t->pid, &status, 0);
++ if (child == -1 && errno != EINTR) {
++ t->exit_code = KSFT_FAIL;
++ fprintf(TH_LOG_STREAM,
++ "# %s: Failed to wait for PID %d (errno: %d)\n",
++ t->name, t->pid, errno);
++ return;
++ }
++
+ alarm(0);
+ if (sigaction(SIGALRM, &saved_action, NULL)) {
+ t->exit_code = KSFT_FAIL;
+@@ -1083,6 +1085,7 @@ void __wait_for_test(struct __test_metad
+ WTERMSIG(status));
+ }
+ } else {
++ t->exit_code = KSFT_FAIL;
+ fprintf(TH_LOG_STREAM,
+ "# %s: Test ended in some other way [%u]\n",
+ t->name,
+@@ -1218,6 +1221,7 @@ void __run_test(struct __fixture_metadat
+ struct __test_xfail *xfail;
+ char test_name[1024];
+ const char *diagnostic;
++ int child;
+
+ /* reset test struct */
+ t->exit_code = KSFT_PASS;
+@@ -1236,15 +1240,16 @@ void __run_test(struct __fixture_metadat
+ fflush(stdout);
+ fflush(stderr);
+
+- t->pid = clone3_vfork();
+- if (t->pid < 0) {
++ child = fork();
++ if (child < 0) {
+ ksft_print_msg("ERROR SPAWNING TEST CHILD\n");
+ t->exit_code = KSFT_FAIL;
+- } else if (t->pid == 0) {
++ } else if (child == 0) {
+ setpgrp();
+ t->fn(t, variant);
+ _exit(t->exit_code);
+ } else {
++ t->pid = child;
+ __wait_for_test(t);
+ }
+ ksft_print_msg(" %4s %s\n",
bluetooth-qca-fix-bt-enable-failure-again-for-qca6390-after-warm-reboot.patch
can-kvaser_usb-explicitly-initialize-family-in-leafimx-driver_info-struct.patch
fsnotify-do-not-generate-events-for-o_path-file-descriptors.patch
+revert-mm-writeback-fix-possible-divide-by-zero-in-wb_dirty_limits-again.patch
+drm-xe-fix-error-handling-in-xe_migrate_update_pgtables.patch
+drm-ttm-always-take-the-bo-delayed-cleanup-path-for-imported-bos.patch
+drm-nouveau-fix-null-pointer-dereference-in-nouveau_connector_get_modes.patch
+drm-amdgpu-atomfirmware-silence-ubsan-warning.patch
+drm-panel-orientation-quirks-add-quirk-for-valve-galileo.patch
+clk-qcom-gcc-ipq9574-add-branch_halt_voted-flag.patch
+clk-sunxi-ng-common-don-t-call-hw_to_ccu_common-on-hw-without-common.patch
+powerpc-pseries-fix-scv-instruction-crash-with-kexec.patch
+powerpc-64s-fix-unnecessary-copy-to-0-when-kernel-is-booted-at-address-0.patch
+firmware-sysfb-fix-reference-count-of-sysfb-parent-device.patch
+filelock-remove-locks-reliably-when-fcntl-close-race-is-detected.patch
+mtd-rawnand-ensure-ecc-configuration-is-propagated-to-upper-layers.patch
+mtd-rawnand-fix-the-nand_read_data_op-early-check.patch
+mtd-rawnand-bypass-a-couple-of-sanity-checks-during-nand-identification.patch
+mtd-rawnand-rockchip-ensure-nvddr-timings-are-rejected.patch
+fs-don-t-misleadingly-warn-during-thaw-operations.patch
+net-stmmac-dwmac-qcom-ethqos-fix-error-array-size.patch
+bnx2x-fix-multiple-ubsan-array-index-out-of-bounds.patch
+s390-dasd-fix-invalid-dereferencing-of-indirect-ccw-data-pointer.patch
+selftests-harness-fix-tests-timeout-and-race-condition.patch
+arm64-dts-rockchip-fix-the-dcdc_reg2-minimum-voltage-on-quartz64-model-b.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
