From: Greg Kroah-Hartman Date: Mon, 8 Jul 2024 12:57:45 +0000 (+0200) Subject: 6.9-stable patches X-Git-Tag: v6.6.38~24 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=799609471226da5de3d6f423bed5811f6d794043;p=thirdparty%2Fkernel%2Fstable-queue.git 6.9-stable patches added patches: arm64-dts-rockchip-fix-the-dcdc_reg2-minimum-voltage-on-quartz64-model-b.patch bnx2x-fix-multiple-ubsan-array-index-out-of-bounds.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 drm-amdgpu-atomfirmware-silence-ubsan-warning.patch drm-nouveau-fix-null-pointer-dereference-in-nouveau_connector_get_modes.patch drm-panel-orientation-quirks-add-quirk-for-valve-galileo.patch drm-ttm-always-take-the-bo-delayed-cleanup-path-for-imported-bos.patch drm-xe-fix-error-handling-in-xe_migrate_update_pgtables.patch filelock-remove-locks-reliably-when-fcntl-close-race-is-detected.patch firmware-sysfb-fix-reference-count-of-sysfb-parent-device.patch fs-don-t-misleadingly-warn-during-thaw-operations.patch mtd-rawnand-bypass-a-couple-of-sanity-checks-during-nand-identification.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-rockchip-ensure-nvddr-timings-are-rejected.patch net-stmmac-dwmac-qcom-ethqos-fix-error-array-size.patch powerpc-64s-fix-unnecessary-copy-to-0-when-kernel-is-booted-at-address-0.patch powerpc-pseries-fix-scv-instruction-crash-with-kexec.patch revert-mm-writeback-fix-possible-divide-by-zero-in-wb_dirty_limits-again.patch s390-dasd-fix-invalid-dereferencing-of-indirect-ccw-data-pointer.patch selftests-harness-fix-tests-timeout-and-race-condition.patch --- diff --git a/queue-6.9/arm64-dts-rockchip-fix-the-dcdc_reg2-minimum-voltage-on-quartz64-model-b.patch b/queue-6.9/arm64-dts-rockchip-fix-the-dcdc_reg2-minimum-voltage-on-quartz64-model-b.patch new file mode 100644 index 00000000000..3ecbd57f4c6 --- /dev/null +++ b/queue-6.9/arm64-dts-rockchip-fix-the-dcdc_reg2-minimum-voltage-on-quartz64-model-b.patch @@ -0,0 +1,56 @@ +From d201c92bff90f3d3d0b079fc955378c15c0483cc Mon Sep 17 00:00:00 2001 +From: Dragan Simic +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 + +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 +Signed-off-by: Dragan Simic +Tested-by: Diederik de Haas +Link: https://lore.kernel.org/r/e70742ea2df432bf57b3f7de542d81ca22b0da2f.1716225483.git.dsimic@manjaro.org +Signed-off-by: Heiko Stuebner +Signed-off-by: Greg Kroah-Hartman +--- + 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>; + diff --git a/queue-6.9/bnx2x-fix-multiple-ubsan-array-index-out-of-bounds.patch b/queue-6.9/bnx2x-fix-multiple-ubsan-array-index-out-of-bounds.patch new file mode 100644 index 00000000000..0a7d28b95ad --- /dev/null +++ b/queue-6.9/bnx2x-fix-multiple-ubsan-array-index-out-of-bounds.patch @@ -0,0 +1,185 @@ +From 134061163ee5ca4759de5c24ca3bd71608891ba7 Mon Sep 17 00:00:00 2001 +From: Ghadi Elie Rahme +Date: Thu, 27 Jun 2024 14:14:05 +0300 +Subject: bnx2x: Fix multiple UBSAN array-index-out-of-bounds + +From: Ghadi Elie Rahme + +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: + + 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 + +---[ 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: + +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 + +---[ 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: + + 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 + +---[ end trace ]--- + +Fixes: 50f0a562f8cc ("bnx2x: add fcoe statistics") +Signed-off-by: Ghadi Elie Rahme +Cc: stable@vger.kernel.org +Link: https://patch.msgid.link/20240627111405.1037812-1-ghadi.rahme@canonical.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + 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]; + }; + diff --git a/queue-6.9/clk-qcom-gcc-ipq9574-add-branch_halt_voted-flag.patch b/queue-6.9/clk-qcom-gcc-ipq9574-add-branch_halt_voted-flag.patch new file mode 100644 index 00000000000..d175a0c97d3 --- /dev/null +++ b/queue-6.9/clk-qcom-gcc-ipq9574-add-branch_halt_voted-flag.patch @@ -0,0 +1,60 @@ +From 72ceafb587a56e26c905472418c7dc2033c294d3 Mon Sep 17 00:00:00 2001 +From: Md Sadre Alam +Date: Thu, 9 May 2024 16:24:05 +0530 +Subject: clk: qcom: gcc-ipq9574: Add BRANCH_HALT_VOTED flag + +From: Md Sadre Alam + +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 +Link: https://lore.kernel.org/r/20240509105405.1262369-1-quic_mdalam@quicinc.com +Signed-off-by: Bjorn Andersson +Signed-off-by: Greg Kroah-Hartman +--- + 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 *[]) { diff --git a/queue-6.9/clk-sunxi-ng-common-don-t-call-hw_to_ccu_common-on-hw-without-common.patch b/queue-6.9/clk-sunxi-ng-common-don-t-call-hw_to_ccu_common-on-hw-without-common.patch new file mode 100644 index 00000000000..5dfece0c5b5 --- /dev/null +++ b/queue-6.9/clk-sunxi-ng-common-don-t-call-hw_to_ccu_common-on-hw-without-common.patch @@ -0,0 +1,67 @@ +From ea977d742507e534d9fe4f4d74256f6b7f589338 Mon Sep 17 00:00:00 2001 +From: Frank Oltmanns +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 + +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 +Closes: https://lore.kernel.org/lkml/DM6PR01MB58047C810DDD5D0AE397CADFF7C22@DM6PR01MB5804.prod.exchangelabs.com/ +Cc: stable@vger.kernel.org +Signed-off-by: Frank Oltmanns +Tested-by: Robert J. Pafford +Link: https://lore.kernel.org/r/20240623-sunxi-ng_fix_common_probe-v1-1-7c97e32824a1@oltmanns.dev +Signed-off-by: Chen-Yu Tsai +Signed-off-by: Greg Kroah-Hartman +--- + 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, diff --git a/queue-6.9/drm-amdgpu-atomfirmware-silence-ubsan-warning.patch b/queue-6.9/drm-amdgpu-atomfirmware-silence-ubsan-warning.patch new file mode 100644 index 00000000000..da5fe4adcea --- /dev/null +++ b/queue-6.9/drm-amdgpu-atomfirmware-silence-ubsan-warning.patch @@ -0,0 +1,31 @@ +From d0417264437a8fa05f894cabba5a26715b32d78e Mon Sep 17 00:00:00 2001 +From: Alex Deucher +Date: Mon, 1 Jul 2024 12:50:10 -0400 +Subject: drm/amdgpu/atomfirmware: silence UBSAN warning + +From: Alex Deucher + +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 +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + 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[]; + }; + + diff --git a/queue-6.9/drm-nouveau-fix-null-pointer-dereference-in-nouveau_connector_get_modes.patch b/queue-6.9/drm-nouveau-fix-null-pointer-dereference-in-nouveau_connector_get_modes.patch new file mode 100644 index 00000000000..e7f0c696164 --- /dev/null +++ b/queue-6.9/drm-nouveau-fix-null-pointer-dereference-in-nouveau_connector_get_modes.patch @@ -0,0 +1,35 @@ +From 80bec6825b19d95ccdfd3393cf8ec15ff2a749b4 Mon Sep 17 00:00:00 2001 +From: Ma Ke +Date: Thu, 27 Jun 2024 15:42:04 +0800 +Subject: drm/nouveau: fix null pointer dereference in nouveau_connector_get_modes + +From: Ma Ke + +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 +Signed-off-by: Lyude Paul +Link: https://patchwork.freedesktop.org/patch/msgid/20240627074204.3023776-1-make24@iscas.ac.cn +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } diff --git a/queue-6.9/drm-panel-orientation-quirks-add-quirk-for-valve-galileo.patch b/queue-6.9/drm-panel-orientation-quirks-add-quirk-for-valve-galileo.patch new file mode 100644 index 00000000000..49c215021d5 --- /dev/null +++ b/queue-6.9/drm-panel-orientation-quirks-add-quirk-for-valve-galileo.patch @@ -0,0 +1,37 @@ +From 26746ed40bb0e4ebe2b2bd61c04eaaa54e263c14 Mon Sep 17 00:00:00 2001 +From: John Schoenick +Date: Fri, 28 Jun 2024 13:58:21 -0700 +Subject: drm: panel-orientation-quirks: Add quirk for Valve Galileo + +From: John Schoenick + +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 +Signed-off-by: Matthew Schwartz +Signed-off-by: Hamza Mahfooz +Link: https://patchwork.freedesktop.org/patch/msgid/20240628205822.348402-2-mattschwartz@gwu.edu +Signed-off-by: Greg Kroah-Hartman +--- + 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"), diff --git a/queue-6.9/drm-ttm-always-take-the-bo-delayed-cleanup-path-for-imported-bos.patch b/queue-6.9/drm-ttm-always-take-the-bo-delayed-cleanup-path-for-imported-bos.patch new file mode 100644 index 00000000000..f9ea097c3f1 --- /dev/null +++ b/queue-6.9/drm-ttm-always-take-the-bo-delayed-cleanup-path-for-imported-bos.patch @@ -0,0 +1,152 @@ +From d99fbd9aab624fc030934e21655389ab1765dc94 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Thomas=20Hellstr=C3=B6m?= +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 + +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] +[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] + +Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") +Cc: Christian König +Cc: Daniel Vetter +Cc: dri-devel@lists.freedesktop.org +Cc: intel-xe@lists.freedesktop.org +Cc: # v6.8+ +Signed-off-by: Thomas Hellström +Reviewed-by: Matthew Brost +Reviewed-by: Daniel Vetter +Reviewed-by: Christian König +Link: https://patchwork.freedesktop.org/patch/msgid/20240628153848.4989-1-thomas.hellstrom@linux.intel.com +Signed-off-by: Greg Kroah-Hartman +--- + 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 + diff --git a/queue-6.9/drm-xe-fix-error-handling-in-xe_migrate_update_pgtables.patch b/queue-6.9/drm-xe-fix-error-handling-in-xe_migrate_update_pgtables.patch new file mode 100644 index 00000000000..a9e418294a5 --- /dev/null +++ b/queue-6.9/drm-xe-fix-error-handling-in-xe_migrate_update_pgtables.patch @@ -0,0 +1,64 @@ +From fc932f51926698488f874ddf7d8f18483ca10271 Mon Sep 17 00:00:00 2001 +From: Matthew Auld +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 + +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 +Cc: Thomas Hellström +Cc: Matthew Brost +Cc: # v6.8+ +Reviewed-by: Thomas Hellström +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 +Signed-off-by: Greg Kroah-Hartman +--- + 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); + } + diff --git a/queue-6.9/filelock-remove-locks-reliably-when-fcntl-close-race-is-detected.patch b/queue-6.9/filelock-remove-locks-reliably-when-fcntl-close-race-is-detected.patch new file mode 100644 index 00000000000..b0a8292d37c --- /dev/null +++ b/queue-6.9/filelock-remove-locks-reliably-when-fcntl-close-race-is-detected.patch @@ -0,0 +1,64 @@ +From 3cad1bc010416c6dd780643476bc59ed742436b9 Mon Sep 17 00:00:00 2001 +From: Jann Horn +Date: Tue, 2 Jul 2024 18:26:52 +0200 +Subject: filelock: Remove locks reliably when fcntl/close race is detected + +From: Jann Horn + +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 +Link: https://lore.kernel.org/r/20240702-fs-lock-recover-2-v1-1-edd456f63789@google.com +Reviewed-by: Jeff Layton +Signed-off-by: Christian Brauner +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } + } diff --git a/queue-6.9/firmware-sysfb-fix-reference-count-of-sysfb-parent-device.patch b/queue-6.9/firmware-sysfb-fix-reference-count-of-sysfb-parent-device.patch new file mode 100644 index 00000000000..58ac7236003 --- /dev/null +++ b/queue-6.9/firmware-sysfb-fix-reference-count-of-sysfb-parent-device.patch @@ -0,0 +1,79 @@ +From 3285d8f0a2ede604c368155c9c0921e16d41f70a Mon Sep 17 00:00:00 2001 +From: Thomas Zimmermann +Date: Tue, 25 Jun 2024 10:17:43 +0200 +Subject: firmware: sysfb: Fix reference count of sysfb parent device + +From: Thomas Zimmermann + +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 +Fixes: 9eac534db001 ("firmware/sysfb: Set firmware-framebuffer parent device") +Cc: Thomas Zimmermann +Cc: Javier Martinez Canillas +Cc: Helge Deller +Cc: Jani Nikula +Cc: Dan Carpenter +Cc: Arnd Bergmann +Cc: Sui Jingfeng +Cc: # v6.9+ +Reviewed-by: Javier Martinez Canillas +Link: https://patchwork.freedesktop.org/patch/msgid/20240625081818.15696-1-tzimmermann@suse.de +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-6.9/fs-don-t-misleadingly-warn-during-thaw-operations.patch b/queue-6.9/fs-don-t-misleadingly-warn-during-thaw-operations.patch new file mode 100644 index 00000000000..9c23e1aa68e --- /dev/null +++ b/queue-6.9/fs-don-t-misleadingly-warn-during-thaw-operations.patch @@ -0,0 +1,69 @@ +From 2ae4db5647d807efb6a87c09efaa6d1db9c905d7 Mon Sep 17 00:00:00 2001 +From: Christian Brauner +Date: Thu, 13 Jun 2024 11:38:14 +0200 +Subject: fs: don't misleadingly warn during thaw operations + +From: Christian Brauner + +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: +Reported-by: Theodore Ts'o +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 +Signed-off-by: Christian Brauner +Signed-off-by: Greg Kroah-Hartman +--- + 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) diff --git a/queue-6.9/mtd-rawnand-bypass-a-couple-of-sanity-checks-during-nand-identification.patch b/queue-6.9/mtd-rawnand-bypass-a-couple-of-sanity-checks-during-nand-identification.patch new file mode 100644 index 00000000000..d6e73e9fca1 --- /dev/null +++ b/queue-6.9/mtd-rawnand-bypass-a-couple-of-sanity-checks-during-nand-identification.patch @@ -0,0 +1,130 @@ +From 8754d9835683e8fab9a8305acdb38a3aeb9d20bd Mon Sep 17 00:00:00 2001 +From: Miquel Raynal +Date: Thu, 16 May 2024 15:13:20 +0200 +Subject: mtd: rawnand: Bypass a couple of sanity checks during NAND identification + +From: Miquel Raynal + +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 +Closes: https://lore.kernel.org/linux-mtd/20240306-shaky-bunion-d28b65ea97d7@thorsis.com/ +Reported-by: Steven Seeger +Closes: https://lore.kernel.org/linux-mtd/DM6PR05MB4506554457CF95191A670BDEF7062@DM6PR05MB4506.namprd05.prod.outlook.com/ +Signed-off-by: Miquel Raynal +Tested-by: Sascha Hauer +Link: https://lore.kernel.org/linux-mtd/20240516131320.579822-3-miquel.raynal@bootlin.com +Signed-off-by: Greg Kroah-Hartman +--- + 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 = diff --git a/queue-6.9/mtd-rawnand-ensure-ecc-configuration-is-propagated-to-upper-layers.patch b/queue-6.9/mtd-rawnand-ensure-ecc-configuration-is-propagated-to-upper-layers.patch new file mode 100644 index 00000000000..a9e0f60a074 --- /dev/null +++ b/queue-6.9/mtd-rawnand-ensure-ecc-configuration-is-propagated-to-upper-layers.patch @@ -0,0 +1,68 @@ +From 3a1b777eb9fb75d09c45ae5dd1d007eddcbebf1f Mon Sep 17 00:00:00 2001 +From: Miquel Raynal +Date: Tue, 7 May 2024 10:58:42 +0200 +Subject: mtd: rawnand: Ensure ECC configuration is propagated to upper layers + +From: Miquel Raynal + +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 +Closes: https://lore.kernel.org/all/Zhe2JtvvN1M4Ompw@pengutronix.de/ +Signed-off-by: Miquel Raynal +Tested-by: Sascha Hauer +Link: https://lore.kernel.org/linux-mtd/20240507085842.108844-1-miquel.raynal@bootlin.com +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-6.9/mtd-rawnand-fix-the-nand_read_data_op-early-check.patch b/queue-6.9/mtd-rawnand-fix-the-nand_read_data_op-early-check.patch new file mode 100644 index 00000000000..5ab2090d719 --- /dev/null +++ b/queue-6.9/mtd-rawnand-fix-the-nand_read_data_op-early-check.patch @@ -0,0 +1,52 @@ +From 5da39530d19946f6241de84d1db69da2f5c61da7 Mon Sep 17 00:00:00 2001 +From: Miquel Raynal +Date: Thu, 16 May 2024 15:13:19 +0200 +Subject: mtd: rawnand: Fix the nand_read_data_op() early check + +From: Miquel Raynal + +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 +Closes: https://lore.kernel.org/linux-mtd/20240306-shaky-bunion-d28b65ea97d7@thorsis.com/ +Reported-by: Steven Seeger +Closes: https://lore.kernel.org/linux-mtd/DM6PR05MB4506554457CF95191A670BDEF7062@DM6PR05MB4506.namprd05.prod.outlook.com/ +Signed-off-by: Miquel Raynal +Reviewed-by: Alexander Dahl +Link: https://lore.kernel.org/linux-mtd/20240516131320.579822-2-miquel.raynal@bootlin.com +Signed-off-by: Greg Kroah-Hartman +--- + 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)) { diff --git a/queue-6.9/mtd-rawnand-rockchip-ensure-nvddr-timings-are-rejected.patch b/queue-6.9/mtd-rawnand-rockchip-ensure-nvddr-timings-are-rejected.patch new file mode 100644 index 00000000000..c77574b05cd --- /dev/null +++ b/queue-6.9/mtd-rawnand-rockchip-ensure-nvddr-timings-are-rejected.patch @@ -0,0 +1,42 @@ +From b27d8946b5edd9827ee3c2f9ea1dd30022fb1ebe Mon Sep 17 00:00:00 2001 +From: Val Packett +Date: Sun, 19 May 2024 00:13:39 -0300 +Subject: mtd: rawnand: rockchip: ensure NVDDR timings are rejected + +From: Val Packett + +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 +Cc: stable@vger.kernel.org +Signed-off-by: Miquel Raynal +Link: https://lore.kernel.org/linux-mtd/20240519031409.26464-1-val@packett.cool +Signed-off-by: Greg Kroah-Hartman +--- + 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 diff --git a/queue-6.9/net-stmmac-dwmac-qcom-ethqos-fix-error-array-size.patch b/queue-6.9/net-stmmac-dwmac-qcom-ethqos-fix-error-array-size.patch new file mode 100644 index 00000000000..e8f5d8bf4e1 --- /dev/null +++ b/queue-6.9/net-stmmac-dwmac-qcom-ethqos-fix-error-array-size.patch @@ -0,0 +1,34 @@ +From b698ab56837bc9e666b7e7e12e9c28fe1d6a763c Mon Sep 17 00:00:00 2001 +From: Yijie Yang +Date: Mon, 1 Jul 2024 09:47:20 +0800 +Subject: net: stmmac: dwmac-qcom-ethqos: fix error array size + +From: Yijie Yang + +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 +Reviewed-by: Bartosz Golaszewski +Link: https://patch.msgid.link/20240701014720.2547856-1-quic_yijiyang@quicinc.com +Signed-off-by: Paolo Abeni +Signed-off-by: Greg Kroah-Hartman +--- + 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", diff --git a/queue-6.9/powerpc-64s-fix-unnecessary-copy-to-0-when-kernel-is-booted-at-address-0.patch b/queue-6.9/powerpc-64s-fix-unnecessary-copy-to-0-when-kernel-is-booted-at-address-0.patch new file mode 100644 index 00000000000..0a82e2f3698 --- /dev/null +++ b/queue-6.9/powerpc-64s-fix-unnecessary-copy-to-0-when-kernel-is-booted-at-address-0.patch @@ -0,0 +1,40 @@ +From 13fc6c175924eaa953cf597ce28ffa4edc4554a6 Mon Sep 17 00:00:00 2001 +From: Jinglin Wen +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 + +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 +Suggested-by: Michael Ellerman +Signed-off-by: Michael Ellerman +Link: https://msgid.link/20240620024150.14857-1-jinglin.wen@shingroup.cn +Signed-off-by: Greg Kroah-Hartman +--- + 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. */ + diff --git a/queue-6.9/powerpc-pseries-fix-scv-instruction-crash-with-kexec.patch b/queue-6.9/powerpc-pseries-fix-scv-instruction-crash-with-kexec.patch new file mode 100644 index 00000000000..1775abef6e0 --- /dev/null +++ b/queue-6.9/powerpc-pseries-fix-scv-instruction-crash-with-kexec.patch @@ -0,0 +1,100 @@ +From 21a741eb75f80397e5f7d3739e24d7d75e619011 Mon Sep 17 00:00:00 2001 +From: Nicholas Piggin +Date: Tue, 25 Jun 2024 23:40:47 +1000 +Subject: powerpc/pseries: Fix scv instruction crash with kexec + +From: Nicholas Piggin + +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 +Closes: https://lore.kernel.org/3b4b2943-49ad-4619-b195-bc416f1d1409@linux.ibm.com +Signed-off-by: Nicholas Piggin +Tested-by: Gautam Menghani +Tested-by: Sourabh Jain +Link: https://msgid.link/20240625134047.298759-1-npiggin@gmail.com +Signed-off-by: Michael Ellerman +Signed-off-by: Greg Kroah-Hartman +--- + 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 + #include + #include /* _end */ ++#include + #include + #include + #include +@@ -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 diff --git a/queue-6.9/revert-mm-writeback-fix-possible-divide-by-zero-in-wb_dirty_limits-again.patch b/queue-6.9/revert-mm-writeback-fix-possible-divide-by-zero-in-wb_dirty_limits-again.patch new file mode 100644 index 00000000000..f5dc777f97a --- /dev/null +++ b/queue-6.9/revert-mm-writeback-fix-possible-divide-by-zero-in-wb_dirty_limits-again.patch @@ -0,0 +1,53 @@ +From 30139c702048f1097342a31302cbd3d478f50c63 Mon Sep 17 00:00:00 2001 +From: Jan Kara +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 + +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 +Reviewed-By: Zach O'Keefe +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + 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 diff --git a/queue-6.9/s390-dasd-fix-invalid-dereferencing-of-indirect-ccw-data-pointer.patch b/queue-6.9/s390-dasd-fix-invalid-dereferencing-of-indirect-ccw-data-pointer.patch new file mode 100644 index 00000000000..d4f39f39948 --- /dev/null +++ b/queue-6.9/s390-dasd-fix-invalid-dereferencing-of-indirect-ccw-data-pointer.patch @@ -0,0 +1,69 @@ +From b3a58f3b90f564f42a5c35778d8c5107b2c2150b Mon Sep 17 00:00:00 2001 +From: Stefan Haberland +Date: Wed, 3 Jul 2024 11:23:12 +0200 +Subject: s390/dasd: Fix invalid dereferencing of indirect CCW data pointer + +From: Stefan Haberland + +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 +Reviewed-by: Heiko Carstens +Signed-off-by: Heiko Carstens +Signed-off-by: Greg Kroah-Hartman +--- + 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 + diff --git a/queue-6.9/selftests-harness-fix-tests-timeout-and-race-condition.patch b/queue-6.9/selftests-harness-fix-tests-timeout-and-race-condition.patch new file mode 100644 index 00000000000..bf927d21347 --- /dev/null +++ b/queue-6.9/selftests-harness-fix-tests-timeout-and-race-condition.patch @@ -0,0 +1,161 @@ +From 130e42806773013e9cf32d211922c935ae2df86c Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Micka=C3=ABl=20Sala=C3=BCn?= +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 + +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 +Cc: Günther Noack +Cc: Jakub Kicinski +Cc: Kees Cook +Cc: Shuah Khan +Cc: Will Drewry +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 +Signed-off-by: Mickaël Salaün +Signed-off-by: Greg Kroah-Hartman +--- + 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 + #include + #include +-#include +-#include + + #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", diff --git a/queue-6.9/series b/queue-6.9/series index e1e084714d3..174b7a38390 100644 --- a/queue-6.9/series +++ b/queue-6.9/series @@ -145,3 +145,25 @@ bluetooth-add-quirk-to-ignore-reserved-phy-bits-in-le-extended-adv-report.patch 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