From: Greg Kroah-Hartman Date: Thu, 17 Apr 2025 11:27:27 +0000 (+0200) Subject: 6.14-stable patches X-Git-Tag: v6.12.24~70 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=6cfe154858eb3293237acc3652b48bc16e3b5d41;p=thirdparty%2Fkernel%2Fstable-queue.git 6.14-stable patches added patches: arm64-dts-exynos-gs101-disable-pinctrl_gsacore-node.patch arm64-dts-mediatek-mt8173-fix-disp-pwm-compatible-string.patch arm64-dts-mediatek-mt8188-assign-apll1-clock-as-parent-to-avoid-hang.patch arm64-dts-ti-k3-j784s4-j742s2-main-common-correct-the-gicd-size.patch arm64-dts-ti-k3-j784s4-j742s2-main-common-fix-serdes_ln_ctrl-reg-masks.patch arm64-mm-correct-the-update-of-max_pfn.patch arm64-mops-do-not-dereference-src-reg-for-a-set-operation.patch arm64-tegra-remove-the-orin-nx-nano-suspend-key.patch backlight-led_bl-hold-led_access-lock-when-calling-led_sysfs_disable.patch btrfs-fix-non-empty-delayed-iputs-list-on-unmount-due-to-compressed-write-workers.patch btrfs-tests-fix-chunk-map-leak-after-failure-to-add-it-to-the-tree.patch btrfs-zoned-fix-zone-activation-with-missing-devices.patch btrfs-zoned-fix-zone-finishing-with-missing-devices.patch i3c-add-null-pointer-check-in-i3c_master_queue_ibi.patch i3c-master-svc-use-readsb-helper-for-reading-mdb.patch igc-fix-xsk-queue-napi-id-mapping.patch ima-limit-the-number-of-open-writers-integrity-violations.patch ima-limit-the-number-of-tomtou-integrity-violations.patch jbd2-remove-wrong-sb-s_sequence-check.patch kbuild-add-fno-builtin-wcslen.patch kbuild-exclude-.rodata.-cst-str-when-building-ranges.patch leds-rgb-leds-qcom-lpg-fix-calculation-of-best-period-hi-res-pwms.patch leds-rgb-leds-qcom-lpg-fix-pwm-resolution-max-for-hi-res-pwms.patch lib-scatterlist-fix-sg_split_phys-to-preserve-original-scatterlist-offsets.patch locking-lockdep-decrease-nr_unused_locks-if-lock-unused-in-zap_class.patch mailbox-tegra-hsp-define-dimensioning-masks-in-soc-data.patch mfd-ene-kb3930-fix-a-potential-null-pointer-dereference.patch mptcp-fix-null-pointer-in-can_accept_new_subflow.patch mptcp-only-inc-mpjoinackhmacfailure-for-hmac-failures.patch mtd-inftlcore-add-error-check-for-inftl_read_oob.patch mtd-rawnand-add-status-chack-in-r852_ready.patch mtd-spinand-fix-build-with-gcc-7.5.patch --- diff --git a/queue-6.14/arm64-dts-exynos-gs101-disable-pinctrl_gsacore-node.patch b/queue-6.14/arm64-dts-exynos-gs101-disable-pinctrl_gsacore-node.patch new file mode 100644 index 0000000000..556689d947 --- /dev/null +++ b/queue-6.14/arm64-dts-exynos-gs101-disable-pinctrl_gsacore-node.patch @@ -0,0 +1,47 @@ +From 168e24966f10ff635b0ec9728aa71833bf850ee5 Mon Sep 17 00:00:00 2001 +From: Peter Griffin +Date: Mon, 6 Jan 2025 14:57:46 +0000 +Subject: arm64: dts: exynos: gs101: disable pinctrl_gsacore node + +From: Peter Griffin + +commit 168e24966f10ff635b0ec9728aa71833bf850ee5 upstream. + +gsacore registers are not accessible from normal world. + +Disable this node, so that the suspend/resume callbacks +in the pinctrl driver don't cause a Serror attempting to +access the registers. + +Fixes: ea89fdf24fd9 ("arm64: dts: exynos: google: Add initial Google gs101 SoC support") +Signed-off-by: Peter Griffin +To: Rob Herring +To: Krzysztof Kozlowski +To: Conor Dooley +To: Alim Akhtar +Cc: linux-arm-kernel@lists.infradead.org +Cc: linux-samsung-soc@vger.kernel.org +Cc: devicetree@vger.kernel.org +Cc: linux-kernel@vger.kernel.org +Cc: tudor.ambarus@linaro.org +Cc: andre.draszik@linaro.org +Cc: kernel-team@android.com +Cc: willmcvicker@google.com +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20250106-contrib-pg-pinctrl_gsacore_disable-v1-1-d3fc88a48aed@linaro.org +Signed-off-by: Krzysztof Kozlowski +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/boot/dts/exynos/google/gs101.dtsi | 1 + + 1 file changed, 1 insertion(+) + +--- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi ++++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi +@@ -1454,6 +1454,7 @@ + /* TODO: update once support for this CMU exists */ + clocks = <0>; + clock-names = "pclk"; ++ status = "disabled"; + }; + + cmu_top: clock-controller@1e080000 { diff --git a/queue-6.14/arm64-dts-mediatek-mt8173-fix-disp-pwm-compatible-string.patch b/queue-6.14/arm64-dts-mediatek-mt8173-fix-disp-pwm-compatible-string.patch new file mode 100644 index 0000000000..8bc7c104bd --- /dev/null +++ b/queue-6.14/arm64-dts-mediatek-mt8173-fix-disp-pwm-compatible-string.patch @@ -0,0 +1,63 @@ +From 46ad36002088eff8fc5cae200aa42ae9f9310ddd Mon Sep 17 00:00:00 2001 +From: Chen-Yu Tsai +Date: Wed, 8 Jan 2025 16:34:22 +0800 +Subject: arm64: dts: mediatek: mt8173: Fix disp-pwm compatible string + +From: Chen-Yu Tsai + +commit 46ad36002088eff8fc5cae200aa42ae9f9310ddd upstream. + +The MT8173 disp-pwm device should have only one compatible string, based +on the following DT validation error: + + arch/arm64/boot/dts/mediatek/mt8173-elm.dtb: pwm@1401e000: compatible: 'oneOf' conditional failed, one must be fixed: + ['mediatek,mt8173-disp-pwm', 'mediatek,mt6595-disp-pwm'] is too long + 'mediatek,mt8173-disp-pwm' is not one of ['mediatek,mt6795-disp-pwm', 'mediatek,mt8167-disp-pwm'] + 'mediatek,mt8173-disp-pwm' is not one of ['mediatek,mt8186-disp-pwm', 'mediatek,mt8188-disp-pwm', 'mediatek,mt8192-disp-pwm', 'mediatek,mt8195-disp-pwm', 'mediatek,mt8365-disp-pwm'] + 'mediatek,mt8173-disp-pwm' was expected + 'mediatek,mt8183-disp-pwm' was expected + from schema $id: http://devicetree.org/schemas/pwm/mediatek,pwm-disp.yaml# + arch/arm64/boot/dts/mediatek/mt8173-elm.dtb: pwm@1401f000: compatible: 'oneOf' conditional failed, one must be fixed: + ['mediatek,mt8173-disp-pwm', 'mediatek,mt6595-disp-pwm'] is too long + 'mediatek,mt8173-disp-pwm' is not one of ['mediatek,mt6795-disp-pwm', 'mediatek,mt8167-disp-pwm'] + 'mediatek,mt8173-disp-pwm' is not one of ['mediatek,mt8186-disp-pwm', 'mediatek,mt8188-disp-pwm', 'mediatek,mt8192-disp-pwm', 'mediatek,mt8195-disp-pwm', 'mediatek,mt8365-disp-pwm'] + 'mediatek,mt8173-disp-pwm' was expected + 'mediatek,mt8183-disp-pwm' was expected + from schema $id: http://devicetree.org/schemas/pwm/mediatek,pwm-disp.yaml# + +Drop the extra "mediatek,mt6595-disp-pwm" compatible string. + +Fixes: 61aee9342514 ("arm64: dts: mt8173: add MT8173 display PWM driver support node") +Cc: YH Huang +Cc: stable@vger.kernel.org # v4.5+ +Signed-off-by: Chen-Yu Tsai +Reviewed-by: AngeloGioacchino Del Regno +Link: https://lore.kernel.org/r/20250108083424.2732375-2-wenst@chromium.org +Signed-off-by: AngeloGioacchino Del Regno +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/boot/dts/mediatek/mt8173.dtsi | 6 ++---- + 1 file changed, 2 insertions(+), 4 deletions(-) + +--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi ++++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi +@@ -1255,8 +1255,7 @@ + }; + + pwm0: pwm@1401e000 { +- compatible = "mediatek,mt8173-disp-pwm", +- "mediatek,mt6595-disp-pwm"; ++ compatible = "mediatek,mt8173-disp-pwm"; + reg = <0 0x1401e000 0 0x1000>; + #pwm-cells = <2>; + clocks = <&mmsys CLK_MM_DISP_PWM026M>, +@@ -1266,8 +1265,7 @@ + }; + + pwm1: pwm@1401f000 { +- compatible = "mediatek,mt8173-disp-pwm", +- "mediatek,mt6595-disp-pwm"; ++ compatible = "mediatek,mt8173-disp-pwm"; + reg = <0 0x1401f000 0 0x1000>; + #pwm-cells = <2>; + clocks = <&mmsys CLK_MM_DISP_PWM126M>, diff --git a/queue-6.14/arm64-dts-mediatek-mt8188-assign-apll1-clock-as-parent-to-avoid-hang.patch b/queue-6.14/arm64-dts-mediatek-mt8188-assign-apll1-clock-as-parent-to-avoid-hang.patch new file mode 100644 index 0000000000..8371b9b1fe --- /dev/null +++ b/queue-6.14/arm64-dts-mediatek-mt8188-assign-apll1-clock-as-parent-to-avoid-hang.patch @@ -0,0 +1,49 @@ +From a69d5795f12b06d07b6437cafdd08f929fff2706 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?N=C3=ADcolas=20F=2E=20R=2E=20A=2E=20Prado?= + +Date: Fri, 7 Feb 2025 14:41:24 -0300 +Subject: arm64: dts: mediatek: mt8188: Assign apll1 clock as parent to avoid hang +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Nícolas F. R. A. Prado + +commit a69d5795f12b06d07b6437cafdd08f929fff2706 upstream. + +Certain registers in the AFE IO space require the apll1 clock to be +enabled in order to be read, otherwise the machine hangs (registers like +0x280, 0x410 (AFE_GAIN1_CON0) and 0x830 (AFE_CONN0_5)). During AFE +driver probe, when initializing the regmap for the AFE IO space those +registers are read, resulting in a hang during boot. + +This has been observed on the Genio 700 EVK, Genio 510 EVK and +MT8188-Geralt-Ciri Chromebook, all of which are based on the MT8188 SoC. + +Assign CLK_TOP_APLL1_D4 as the parent for CLK_TOP_A1SYS_HP, which is +enabled during register read and write, to make sure the apll1 is +enabled during register operations and prevent the MT8188 machines from +hanging during boot. + +Cc: stable@vger.kernel.org +Fixes: bd568ce198b8 ("arm64: dts: mediatek: mt8188: Add audio support") +Suggested-by: AngeloGioacchino Del Regno +Signed-off-by: Nícolas F. R. A. Prado +Link: https://lore.kernel.org/r/20250207-mt8188-afe-fix-hang-disabled-apll1-clk-v2-1-a636d844c272@collabora.com +Signed-off-by: AngeloGioacchino Del Regno +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/boot/dts/mediatek/mt8188.dtsi | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/arm64/boot/dts/mediatek/mt8188.dtsi ++++ b/arch/arm64/boot/dts/mediatek/mt8188.dtsi +@@ -1392,7 +1392,7 @@ + compatible = "mediatek,mt8188-afe"; + reg = <0 0x10b10000 0 0x10000>; + assigned-clocks = <&topckgen CLK_TOP_A1SYS_HP>; +- assigned-clock-parents = <&clk26m>; ++ assigned-clock-parents = <&topckgen CLK_TOP_APLL1_D4>; + clocks = <&clk26m>, + <&apmixedsys CLK_APMIXED_APLL1>, + <&apmixedsys CLK_APMIXED_APLL2>, diff --git a/queue-6.14/arm64-dts-ti-k3-j784s4-j742s2-main-common-correct-the-gicd-size.patch b/queue-6.14/arm64-dts-ti-k3-j784s4-j742s2-main-common-correct-the-gicd-size.patch new file mode 100644 index 0000000000..bba3949f7d --- /dev/null +++ b/queue-6.14/arm64-dts-ti-k3-j784s4-j742s2-main-common-correct-the-gicd-size.patch @@ -0,0 +1,37 @@ +From 398898f9cca1a19a83184430c675562680e57c7b Mon Sep 17 00:00:00 2001 +From: Keerthy +Date: Tue, 18 Feb 2025 10:52:48 +0530 +Subject: arm64: dts: ti: k3-j784s4-j742s2-main-common: Correct the GICD size + +From: Keerthy + +commit 398898f9cca1a19a83184430c675562680e57c7b upstream. + +Currently we get the warning: + +"GICv3: [Firmware Bug]: GICR region 0x0000000001900000 has +overlapping address" + +As per TRM GICD is 64 KB. Fix it by correcting the size of GICD. + +Cc: stable@vger.kernel.org +Fixes: 9cc161a4509c ("arm64: dts: ti: Refactor J784s4 SoC files to a common file") +Link: https://lore.kernel.org/r/20250218052248.4734-1-j-keerthy@ti.com +Signed-off-by: Keerthy +Signed-off-by: Vignesh Raghavendra +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi ++++ b/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi +@@ -193,7 +193,7 @@ + ranges; + #interrupt-cells = <3>; + interrupt-controller; +- reg = <0x00 0x01800000 0x00 0x200000>, /* GICD */ ++ reg = <0x00 0x01800000 0x00 0x10000>, /* GICD */ + <0x00 0x01900000 0x00 0x100000>, /* GICR */ + <0x00 0x6f000000 0x00 0x2000>, /* GICC */ + <0x00 0x6f010000 0x00 0x1000>, /* GICH */ diff --git a/queue-6.14/arm64-dts-ti-k3-j784s4-j742s2-main-common-fix-serdes_ln_ctrl-reg-masks.patch b/queue-6.14/arm64-dts-ti-k3-j784s4-j742s2-main-common-fix-serdes_ln_ctrl-reg-masks.patch new file mode 100644 index 0000000000..2abecf0de5 --- /dev/null +++ b/queue-6.14/arm64-dts-ti-k3-j784s4-j742s2-main-common-fix-serdes_ln_ctrl-reg-masks.patch @@ -0,0 +1,38 @@ +From 38e7f9092efbbf2a4a67e4410b55b797f8d1e184 Mon Sep 17 00:00:00 2001 +From: Siddharth Vadapalli +Date: Fri, 28 Feb 2025 11:08:50 +0530 +Subject: arm64: dts: ti: k3-j784s4-j742s2-main-common: Fix serdes_ln_ctrl reg-masks + +From: Siddharth Vadapalli + +commit 38e7f9092efbbf2a4a67e4410b55b797f8d1e184 upstream. + +Commit under Fixes added the 'idle-states' property for SERDES4 lane muxes +without defining the corresponding register offsets and masks for it in the +'mux-reg-masks' property within the 'serdes_ln_ctrl' node. + +Fix this. + +Fixes: 7287d423f138 ("arm64: dts: ti: k3-j784s4-main: Add system controller and SERDES lane mux") +Cc: stable@vger.kernel.org +Signed-off-by: Siddharth Vadapalli +Link: https://lore.kernel.org/r/20250228053850.506028-1-s-vadapalli@ti.com +Signed-off-by: Vignesh Raghavendra +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi ++++ b/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi +@@ -84,7 +84,9 @@ + <0x10 0x3>, <0x14 0x3>, /* SERDES1 lane0/1 select */ + <0x18 0x3>, <0x1c 0x3>, /* SERDES1 lane2/3 select */ + <0x20 0x3>, <0x24 0x3>, /* SERDES2 lane0/1 select */ +- <0x28 0x3>, <0x2c 0x3>; /* SERDES2 lane2/3 select */ ++ <0x28 0x3>, <0x2c 0x3>, /* SERDES2 lane2/3 select */ ++ <0x40 0x3>, <0x44 0x3>, /* SERDES4 lane0/1 select */ ++ <0x48 0x3>, <0x4c 0x3>; /* SERDES4 lane2/3 select */ + idle-states = , + , + , diff --git a/queue-6.14/arm64-mm-correct-the-update-of-max_pfn.patch b/queue-6.14/arm64-mm-correct-the-update-of-max_pfn.patch new file mode 100644 index 0000000000..e06a5e266b --- /dev/null +++ b/queue-6.14/arm64-mm-correct-the-update-of-max_pfn.patch @@ -0,0 +1,45 @@ +From 89f43e1ce6f60d4f44399059595ac47f7a90a393 Mon Sep 17 00:00:00 2001 +From: Zhenhua Huang +Date: Fri, 21 Mar 2025 15:00:19 +0800 +Subject: arm64: mm: Correct the update of max_pfn + +From: Zhenhua Huang + +commit 89f43e1ce6f60d4f44399059595ac47f7a90a393 upstream. + +Hotplugged memory can be smaller than the original memory. For example, +on my target: + +root@genericarmv8:~# cat /sys/kernel/debug/memblock/memory + 0: 0x0000000064005000..0x0000000064023fff 0 NOMAP + 1: 0x0000000064400000..0x00000000647fffff 0 NOMAP + 2: 0x0000000068000000..0x000000006fffffff 0 DRV_MNG + 3: 0x0000000088800000..0x0000000094ffefff 0 NONE + 4: 0x0000000094fff000..0x0000000094ffffff 0 NOMAP +max_pfn will affect read_page_owner. Therefore, it should first compare and +then select the larger value for max_pfn. + +Fixes: 8fac67ca236b ("arm64: mm: update max_pfn after memory hotplug") +Cc: # 6.1.x +Signed-off-by: Zhenhua Huang +Acked-by: David Hildenbrand +Reviewed-by: Anshuman Khandual +Link: https://lore.kernel.org/r/20250321070019.1271859-1-quic_zhenhuah@quicinc.com +Signed-off-by: Catalin Marinas +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/mm/mmu.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/arch/arm64/mm/mmu.c ++++ b/arch/arm64/mm/mmu.c +@@ -1361,7 +1361,8 @@ int arch_add_memory(int nid, u64 start, + __remove_pgd_mapping(swapper_pg_dir, + __phys_to_virt(start), size); + else { +- max_pfn = PFN_UP(start + size); ++ /* Address of hotplugged memory can be smaller */ ++ max_pfn = max(max_pfn, PFN_UP(start + size)); + max_low_pfn = max_pfn; + } + diff --git a/queue-6.14/arm64-mops-do-not-dereference-src-reg-for-a-set-operation.patch b/queue-6.14/arm64-mops-do-not-dereference-src-reg-for-a-set-operation.patch new file mode 100644 index 0000000000..50ba3d0e3b --- /dev/null +++ b/queue-6.14/arm64-mops-do-not-dereference-src-reg-for-a-set-operation.patch @@ -0,0 +1,59 @@ +From a13bfa4fe0d6949cea14718df2d1fe84c38cd113 Mon Sep 17 00:00:00 2001 +From: Keir Fraser +Date: Wed, 26 Mar 2025 11:04:47 +0000 +Subject: arm64: mops: Do not dereference src reg for a set operation +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Keir Fraser + +commit a13bfa4fe0d6949cea14718df2d1fe84c38cd113 upstream. + +The source register is not used for SET* and reading it can result in +a UBSAN out-of-bounds array access error, specifically when the MOPS +exception is taken from a SET* sequence with XZR (reg 31) as the +source. Architecturally this is the only case where a src/dst/size +field in the ESR can be reported as 31. + +Prior to 2de451a329cf662b the code in do_el0_mops() was benign as the +use of pt_regs_read_reg() prevented the out-of-bounds access. + +Fixes: 2de451a329cf ("KVM: arm64: Add handler for MOPS exceptions") +Cc: # 6.12.x +Cc: Kristina Martsenko +Cc: Will Deacon +Cc: stable@vger.kernel.org +Reviewed-by: Marc Zyngier +Signed-off-by: Keir Fraser +Reviewed-by: Kristina Martšenko +Acked-by: Mark Rutland +Link: https://lore.kernel.org/r/20250326110448.3792396-1-keirf@google.com +Signed-off-by: Catalin Marinas +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/include/asm/traps.h | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/arch/arm64/include/asm/traps.h ++++ b/arch/arm64/include/asm/traps.h +@@ -109,10 +109,9 @@ static inline void arm64_mops_reset_regs + int dstreg = ESR_ELx_MOPS_ISS_DESTREG(esr); + int srcreg = ESR_ELx_MOPS_ISS_SRCREG(esr); + int sizereg = ESR_ELx_MOPS_ISS_SIZEREG(esr); +- unsigned long dst, src, size; ++ unsigned long dst, size; + + dst = regs->regs[dstreg]; +- src = regs->regs[srcreg]; + size = regs->regs[sizereg]; + + /* +@@ -129,6 +128,7 @@ static inline void arm64_mops_reset_regs + } + } else { + /* CPY* instruction */ ++ unsigned long src = regs->regs[srcreg]; + if (!(option_a ^ wrong_option)) { + /* Format is from Option B */ + if (regs->pstate & PSR_N_BIT) { diff --git a/queue-6.14/arm64-tegra-remove-the-orin-nx-nano-suspend-key.patch b/queue-6.14/arm64-tegra-remove-the-orin-nx-nano-suspend-key.patch new file mode 100644 index 0000000000..29cc02bec4 --- /dev/null +++ b/queue-6.14/arm64-tegra-remove-the-orin-nx-nano-suspend-key.patch @@ -0,0 +1,45 @@ +From bb8a3ad25f098b6ea9b1d0f522427b4ad53a7bba Mon Sep 17 00:00:00 2001 +From: Ninad Malwade +Date: Thu, 6 Feb 2025 22:40:34 +0000 +Subject: arm64: tegra: Remove the Orin NX/Nano suspend key + +From: Ninad Malwade + +commit bb8a3ad25f098b6ea9b1d0f522427b4ad53a7bba upstream. + +As per the Orin Nano Dev Kit schematic, GPIO_G.02 is not available +on this device family. It should not be used at all on Orin NX/Nano. +Having this unused pin mapped as the suspend key can lead to +unpredictable behavior for low power modes. + +Orin NX/Nano uses GPIO_EE.04 as both a "power" button and a "suspend" +button. However, we cannot have two gpio-keys mapped to the same +GPIO. Therefore remove the "suspend" key. + +Cc: stable@vger.kernel.org +Fixes: e63472eda5ea ("arm64: tegra: Support Jetson Orin NX reference platform") +Signed-off-by: Ninad Malwade +Signed-off-by: Ivy Huang +Link: https://lore.kernel.org/r/20250206224034.3691397-1-yijuh@nvidia.com +Signed-off-by: Thierry Reding +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767.dtsi | 7 ------- + 1 file changed, 7 deletions(-) + +--- a/arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767.dtsi ++++ b/arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767.dtsi +@@ -227,13 +227,6 @@ + wakeup-event-action = ; + wakeup-source; + }; +- +- key-suspend { +- label = "Suspend"; +- gpios = <&gpio TEGRA234_MAIN_GPIO(G, 2) GPIO_ACTIVE_LOW>; +- linux,input-type = ; +- linux,code = ; +- }; + }; + + fan: pwm-fan { diff --git a/queue-6.14/backlight-led_bl-hold-led_access-lock-when-calling-led_sysfs_disable.patch b/queue-6.14/backlight-led_bl-hold-led_access-lock-when-calling-led_sysfs_disable.patch new file mode 100644 index 0000000000..904ce6a06b --- /dev/null +++ b/queue-6.14/backlight-led_bl-hold-led_access-lock-when-calling-led_sysfs_disable.patch @@ -0,0 +1,50 @@ +From 276822a00db3c1061382b41e72cafc09d6a0ec30 Mon Sep 17 00:00:00 2001 +From: Herve Codina +Date: Wed, 22 Jan 2025 10:19:14 +0100 +Subject: backlight: led_bl: Hold led_access lock when calling led_sysfs_disable() + +From: Herve Codina + +commit 276822a00db3c1061382b41e72cafc09d6a0ec30 upstream. + +Lockdep detects the following issue on led-backlight removal: + [ 142.315935] ------------[ cut here ]------------ + [ 142.315954] WARNING: CPU: 2 PID: 292 at drivers/leds/led-core.c:455 led_sysfs_enable+0x54/0x80 + ... + [ 142.500725] Call trace: + [ 142.503176] led_sysfs_enable+0x54/0x80 (P) + [ 142.507370] led_bl_remove+0x80/0xa8 [led_bl] + [ 142.511742] platform_remove+0x30/0x58 + [ 142.515501] device_remove+0x54/0x90 + ... + +Indeed, led_sysfs_enable() has to be called with the led_access +lock held. + +Hold the lock when calling led_sysfs_disable(). + +Fixes: ae232e45acf9 ("backlight: add led-backlight driver") +Cc: stable@vger.kernel.org +Signed-off-by: Herve Codina +Link: https://lore.kernel.org/r/20250122091914.309533-1-herve.codina@bootlin.com +Signed-off-by: Lee Jones +Signed-off-by: Greg Kroah-Hartman +--- + drivers/video/backlight/led_bl.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +--- a/drivers/video/backlight/led_bl.c ++++ b/drivers/video/backlight/led_bl.c +@@ -229,8 +229,11 @@ static void led_bl_remove(struct platfor + backlight_device_unregister(bl); + + led_bl_power_off(priv); +- for (i = 0; i < priv->nb_leds; i++) ++ for (i = 0; i < priv->nb_leds; i++) { ++ mutex_lock(&priv->leds[i]->led_access); + led_sysfs_enable(priv->leds[i]); ++ mutex_unlock(&priv->leds[i]->led_access); ++ } + } + + static const struct of_device_id led_bl_of_match[] = { diff --git a/queue-6.14/btrfs-fix-non-empty-delayed-iputs-list-on-unmount-due-to-compressed-write-workers.patch b/queue-6.14/btrfs-fix-non-empty-delayed-iputs-list-on-unmount-due-to-compressed-write-workers.patch new file mode 100644 index 0000000000..49f049eb79 --- /dev/null +++ b/queue-6.14/btrfs-fix-non-empty-delayed-iputs-list-on-unmount-due-to-compressed-write-workers.patch @@ -0,0 +1,80 @@ +From 4c782247b89376a83fa132f7d45d6977edae0629 Mon Sep 17 00:00:00 2001 +From: Filipe Manana +Date: Wed, 5 Mar 2025 16:52:26 +0000 +Subject: btrfs: fix non-empty delayed iputs list on unmount due to compressed write workers + +From: Filipe Manana + +commit 4c782247b89376a83fa132f7d45d6977edae0629 upstream. + +At close_ctree() after we have ran delayed iputs either through explicitly +calling btrfs_run_delayed_iputs() or later during the call to +btrfs_commit_super() or btrfs_error_commit_super(), we assert that the +delayed iputs list is empty. + +When we have compressed writes this assertion may fail because delayed +iputs may have been added to the list after we last ran delayed iputs. +This happens like this: + +1) We have a compressed write bio executing; + +2) We enter close_ctree() and flush the fs_info->endio_write_workers + queue which is the queue used for running ordered extent completion; + +3) The compressed write bio finishes and enters + btrfs_finish_compressed_write_work(), where it calls + btrfs_finish_ordered_extent() which in turn calls + btrfs_queue_ordered_fn(), which queues a work item in the + fs_info->endio_write_workers queue that we have flushed before; + +4) At close_ctree() we proceed, run all existing delayed iputs and + call btrfs_commit_super() (which also runs delayed iputs), but before + we run the following assertion below: + + ASSERT(list_empty(&fs_info->delayed_iputs)) + + A delayed iput is added by the step below... + +5) The ordered extent completion job queued in step 3 runs and results in + creating a delayed iput when dropping the last reference of the ordered + extent (a call to btrfs_put_ordered_extent() made from + btrfs_finish_one_ordered()); + +6) At this point the delayed iputs list is not empty, so the assertion at + close_ctree() fails. + +Fix this by flushing the fs_info->compressed_write_workers queue at +close_ctree() before flushing the fs_info->endio_write_workers queue, +respecting the queue dependency as the later is responsible for the +execution of ordered extent completion. + +CC: stable@vger.kernel.org # 5.15+ +Reviewed-by: Qu Wenruo +Signed-off-by: Filipe Manana +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/disk-io.c | 12 ++++++++++++ + 1 file changed, 12 insertions(+) + +--- a/fs/btrfs/disk-io.c ++++ b/fs/btrfs/disk-io.c +@@ -4349,6 +4349,18 @@ void __cold close_ctree(struct btrfs_fs_ + btrfs_flush_workqueue(fs_info->delalloc_workers); + + /* ++ * When finishing a compressed write bio we schedule a work queue item ++ * to finish an ordered extent - btrfs_finish_compressed_write_work() ++ * calls btrfs_finish_ordered_extent() which in turns does a call to ++ * btrfs_queue_ordered_fn(), and that queues the ordered extent ++ * completion either in the endio_write_workers work queue or in the ++ * fs_info->endio_freespace_worker work queue. We flush those queues ++ * below, so before we flush them we must flush this queue for the ++ * workers of compressed writes. ++ */ ++ flush_workqueue(fs_info->compressed_write_workers); ++ ++ /* + * After we parked the cleaner kthread, ordered extents may have + * completed and created new delayed iputs. If one of the async reclaim + * tasks is running and in the RUN_DELAYED_IPUTS flush state, then we diff --git a/queue-6.14/btrfs-tests-fix-chunk-map-leak-after-failure-to-add-it-to-the-tree.patch b/queue-6.14/btrfs-tests-fix-chunk-map-leak-after-failure-to-add-it-to-the-tree.patch new file mode 100644 index 0000000000..a89ab67ac6 --- /dev/null +++ b/queue-6.14/btrfs-tests-fix-chunk-map-leak-after-failure-to-add-it-to-the-tree.patch @@ -0,0 +1,35 @@ +From 009ca358486ded9b4822eddb924009b6848d7271 Mon Sep 17 00:00:00 2001 +From: Filipe Manana +Date: Tue, 11 Mar 2025 15:50:50 +0000 +Subject: btrfs: tests: fix chunk map leak after failure to add it to the tree + +From: Filipe Manana + +commit 009ca358486ded9b4822eddb924009b6848d7271 upstream. + +If we fail to add the chunk map to the fs mapping tree we exit +test_rmap_block() without freeing the chunk map. Fix this by adding a +call to btrfs_free_chunk_map() before exiting the test function if the +call to btrfs_add_chunk_map() failed. + +Fixes: 7dc66abb5a47 ("btrfs: use a dedicated data structure for chunk maps") +CC: stable@vger.kernel.org # 6.12+ +Reviewed-by: Boris Burkov +Signed-off-by: Filipe Manana +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/tests/extent-map-tests.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/fs/btrfs/tests/extent-map-tests.c ++++ b/fs/btrfs/tests/extent-map-tests.c +@@ -1045,6 +1045,7 @@ static int test_rmap_block(struct btrfs_ + ret = btrfs_add_chunk_map(fs_info, map); + if (ret) { + test_err("error adding chunk map to mapping tree"); ++ btrfs_free_chunk_map(map); + goto out_free; + } + diff --git a/queue-6.14/btrfs-zoned-fix-zone-activation-with-missing-devices.patch b/queue-6.14/btrfs-zoned-fix-zone-activation-with-missing-devices.patch new file mode 100644 index 0000000000..e64e17926b --- /dev/null +++ b/queue-6.14/btrfs-zoned-fix-zone-activation-with-missing-devices.patch @@ -0,0 +1,41 @@ +From 2bbc4a45e5eb6b868357c1045bf6f38f6ba576e0 Mon Sep 17 00:00:00 2001 +From: Johannes Thumshirn +Date: Mon, 17 Mar 2025 12:24:58 +0100 +Subject: btrfs: zoned: fix zone activation with missing devices + +From: Johannes Thumshirn + +commit 2bbc4a45e5eb6b868357c1045bf6f38f6ba576e0 upstream. + +If btrfs_zone_activate() is called with a filesystem that has missing +devices (e.g. a RAID file system mounted in degraded mode) it is accessing +the btrfs_device::zone_info pointer, which will not be set if the device in +question is missing. + +Check if the device is present (by checking if it has a valid block +device pointer associated) and if not, skip zone activation for it. + +Fixes: f9a912a3c45f ("btrfs: zoned: make zone activation multi stripe capable") +CC: stable@vger.kernel.org # 6.1+ +Reviewed-by: Naohiro Aota +Reviewed-by: Anand Jain +Signed-off-by: Johannes Thumshirn +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/zoned.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/fs/btrfs/zoned.c ++++ b/fs/btrfs/zoned.c +@@ -2111,6 +2111,9 @@ bool btrfs_zone_activate(struct btrfs_bl + physical = map->stripes[i].physical; + zinfo = device->zone_info; + ++ if (!device->bdev) ++ continue; ++ + if (zinfo->max_active_zones == 0) + continue; + diff --git a/queue-6.14/btrfs-zoned-fix-zone-finishing-with-missing-devices.patch b/queue-6.14/btrfs-zoned-fix-zone-finishing-with-missing-devices.patch new file mode 100644 index 0000000000..7d1c3d8355 --- /dev/null +++ b/queue-6.14/btrfs-zoned-fix-zone-finishing-with-missing-devices.patch @@ -0,0 +1,41 @@ +From 35fec1089ebb5617f85884d3fa6a699ce6337a75 Mon Sep 17 00:00:00 2001 +From: Johannes Thumshirn +Date: Mon, 17 Mar 2025 12:24:59 +0100 +Subject: btrfs: zoned: fix zone finishing with missing devices + +From: Johannes Thumshirn + +commit 35fec1089ebb5617f85884d3fa6a699ce6337a75 upstream. + +If do_zone_finish() is called with a filesystem that has missing devices +(e.g. a RAID file system mounted in degraded mode) it is accessing the +btrfs_device::zone_info pointer, which will not be set if the device +in question is missing. + +Check if the device is present (by checking if it has a valid block device +pointer associated) and if not, skip zone finishing for it. + +Fixes: 4dcbb8ab31c1 ("btrfs: zoned: make zone finishing multi stripe capable") +CC: stable@vger.kernel.org # 6.1+ +Reviewed-by: Naohiro Aota +Reviewed-by: Anand Jain +Signed-off-by: Johannes Thumshirn +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/zoned.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/fs/btrfs/zoned.c ++++ b/fs/btrfs/zoned.c +@@ -2275,6 +2275,9 @@ static int do_zone_finish(struct btrfs_b + struct btrfs_zoned_device_info *zinfo = device->zone_info; + unsigned int nofs_flags; + ++ if (!device->bdev) ++ continue; ++ + if (zinfo->max_active_zones == 0) + continue; + diff --git a/queue-6.14/i3c-add-null-pointer-check-in-i3c_master_queue_ibi.patch b/queue-6.14/i3c-add-null-pointer-check-in-i3c_master_queue_ibi.patch new file mode 100644 index 0000000000..03cbfb61cc --- /dev/null +++ b/queue-6.14/i3c-add-null-pointer-check-in-i3c_master_queue_ibi.patch @@ -0,0 +1,56 @@ +From bd496a44f041da9ef3afe14d1d6193d460424e91 Mon Sep 17 00:00:00 2001 +From: Manjunatha Venkatesh +Date: Wed, 26 Mar 2025 18:00:46 +0530 +Subject: i3c: Add NULL pointer check in i3c_master_queue_ibi() +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Manjunatha Venkatesh + +commit bd496a44f041da9ef3afe14d1d6193d460424e91 upstream. + +The I3C master driver may receive an IBI from a target device that has not +been probed yet. In such cases, the master calls `i3c_master_queue_ibi()` +to queue an IBI work task, leading to "Unable to handle kernel read from +unreadable memory" and resulting in a kernel panic. + +Typical IBI handling flow: +1. The I3C master scans target devices and probes their respective drivers. +2. The target device driver calls `i3c_device_request_ibi()` to enable IBI + and assigns `dev->ibi = ibi`. +3. The I3C master receives an IBI from the target device and calls + `i3c_master_queue_ibi()` to queue the target device driver’s IBI + handler task. + +However, since target device events are asynchronous to the I3C probe +sequence, step 3 may occur before step 2, causing `dev->ibi` to be `NULL`, +leading to a kernel panic. + +Add a NULL pointer check in `i3c_master_queue_ibi()` to prevent accessing +an uninitialized `dev->ibi`, ensuring stability. + +Fixes: 3a379bbcea0af ("i3c: Add core I3C infrastructure") +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/lkml/Z9gjGYudiYyl3bSe@lizhi-Precision-Tower-5810/ +Signed-off-by: Manjunatha Venkatesh +Reviewed-by: Frank Li +Link: https://lore.kernel.org/r/20250326123047.2797946-1-manjunatha.venkatesh@nxp.com +Signed-off-by: Alexandre Belloni +Signed-off-by: Greg Kroah-Hartman +--- + drivers/i3c/master.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/i3c/master.c ++++ b/drivers/i3c/master.c +@@ -2561,6 +2561,9 @@ static void i3c_master_unregister_i3c_de + */ + void i3c_master_queue_ibi(struct i3c_dev_desc *dev, struct i3c_ibi_slot *slot) + { ++ if (!dev->ibi || !slot) ++ return; ++ + atomic_inc(&dev->ibi->pending_ibis); + queue_work(dev->ibi->wq, &slot->work); + } diff --git a/queue-6.14/i3c-master-svc-use-readsb-helper-for-reading-mdb.patch b/queue-6.14/i3c-master-svc-use-readsb-helper-for-reading-mdb.patch new file mode 100644 index 0000000000..743e0cde90 --- /dev/null +++ b/queue-6.14/i3c-master-svc-use-readsb-helper-for-reading-mdb.patch @@ -0,0 +1,36 @@ +From c06acf7143bddaa3c0f7bedd8b99e48f6acb85c3 Mon Sep 17 00:00:00 2001 +From: Stanley Chu +Date: Tue, 18 Mar 2025 13:36:05 +0800 +Subject: i3c: master: svc: Use readsb helper for reading MDB + +From: Stanley Chu + +commit c06acf7143bddaa3c0f7bedd8b99e48f6acb85c3 upstream. + +The target can send the MDB byte followed by additional data bytes. +The readl on MRDATAB reads one actual byte, but the readsl advances +the destination pointer by 4 bytes. This causes the subsequent payload +to be copied to wrong position in the destination buffer. + +Cc: stable@kernel.org +Fixes: dd3c52846d59 ("i3c: master: svc: Add Silvaco I3C master driver") +Signed-off-by: Stanley Chu +Reviewed-by: Frank Li +Link: https://lore.kernel.org/r/20250318053606.3087121-3-yschu@nuvoton.com +Signed-off-by: Alexandre Belloni +Signed-off-by: Greg Kroah-Hartman +--- + drivers/i3c/master/svc-i3c-master.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/i3c/master/svc-i3c-master.c ++++ b/drivers/i3c/master/svc-i3c-master.c +@@ -378,7 +378,7 @@ static int svc_i3c_master_handle_ibi(str + slot->len < SVC_I3C_FIFO_SIZE) { + mdatactrl = readl(master->regs + SVC_I3C_MDATACTRL); + count = SVC_I3C_MDATACTRL_RXCOUNT(mdatactrl); +- readsl(master->regs + SVC_I3C_MRDATAB, buf, count); ++ readsb(master->regs + SVC_I3C_MRDATAB, buf, count); + slot->len += count; + buf += count; + } diff --git a/queue-6.14/igc-fix-xsk-queue-napi-id-mapping.patch b/queue-6.14/igc-fix-xsk-queue-napi-id-mapping.patch new file mode 100644 index 0000000000..8312bfc6c2 --- /dev/null +++ b/queue-6.14/igc-fix-xsk-queue-napi-id-mapping.patch @@ -0,0 +1,84 @@ +From dddeeaa16ce9d163ccf3b681715512d338afa541 Mon Sep 17 00:00:00 2001 +From: Joe Damato +Date: Wed, 5 Mar 2025 18:09:00 +0000 +Subject: igc: Fix XSK queue NAPI ID mapping + +From: Joe Damato + +commit dddeeaa16ce9d163ccf3b681715512d338afa541 upstream. + +In commit b65969856d4f ("igc: Link queues to NAPI instances"), the XSK +queues were incorrectly unmapped from their NAPI instances. After +discussion on the mailing list and the introduction of a test to codify +the expected behavior, we can see that the unmapping causes the +check_xsk test to fail: + +NETIF=enp86s0 ./tools/testing/selftests/drivers/net/queues.py + +[...] + # Check| ksft_eq(q.get('xsk', None), {}, + # Check failed None != {} xsk attr on queue we configured + not ok 4 queues.check_xsk + +After this commit, the test passes: + + ok 4 queues.check_xsk + +Note that the test itself is only in net-next, so I tested this change +by applying it to my local net-next tree, booting, and running the test. + +Cc: stable@vger.kernel.org +Fixes: b65969856d4f ("igc: Link queues to NAPI instances") +Signed-off-by: Joe Damato +Reviewed-by: Gerhard Engleder +Tested-by: Mor Bar-Gabay +Signed-off-by: Tony Nguyen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/intel/igc/igc.h | 2 -- + drivers/net/ethernet/intel/igc/igc_main.c | 4 ++-- + drivers/net/ethernet/intel/igc/igc_xdp.c | 2 -- + 3 files changed, 2 insertions(+), 6 deletions(-) + +--- a/drivers/net/ethernet/intel/igc/igc.h ++++ b/drivers/net/ethernet/intel/igc/igc.h +@@ -337,8 +337,6 @@ struct igc_adapter { + struct igc_led_classdev *leds; + }; + +-void igc_set_queue_napi(struct igc_adapter *adapter, int q_idx, +- struct napi_struct *napi); + void igc_up(struct igc_adapter *adapter); + void igc_down(struct igc_adapter *adapter); + int igc_open(struct net_device *netdev); +--- a/drivers/net/ethernet/intel/igc/igc_main.c ++++ b/drivers/net/ethernet/intel/igc/igc_main.c +@@ -5021,8 +5021,8 @@ static int igc_sw_init(struct igc_adapte + return 0; + } + +-void igc_set_queue_napi(struct igc_adapter *adapter, int vector, +- struct napi_struct *napi) ++static void igc_set_queue_napi(struct igc_adapter *adapter, int vector, ++ struct napi_struct *napi) + { + struct igc_q_vector *q_vector = adapter->q_vector[vector]; + +--- a/drivers/net/ethernet/intel/igc/igc_xdp.c ++++ b/drivers/net/ethernet/intel/igc/igc_xdp.c +@@ -86,7 +86,6 @@ static int igc_xdp_enable_pool(struct ig + napi_disable(napi); + } + +- igc_set_queue_napi(adapter, queue_id, NULL); + set_bit(IGC_RING_FLAG_AF_XDP_ZC, &rx_ring->flags); + set_bit(IGC_RING_FLAG_AF_XDP_ZC, &tx_ring->flags); + +@@ -136,7 +135,6 @@ static int igc_xdp_disable_pool(struct i + xsk_pool_dma_unmap(pool, IGC_RX_DMA_ATTR); + clear_bit(IGC_RING_FLAG_AF_XDP_ZC, &rx_ring->flags); + clear_bit(IGC_RING_FLAG_AF_XDP_ZC, &tx_ring->flags); +- igc_set_queue_napi(adapter, queue_id, napi); + + if (needs_reset) { + napi_enable(napi); diff --git a/queue-6.14/ima-limit-the-number-of-open-writers-integrity-violations.patch b/queue-6.14/ima-limit-the-number-of-open-writers-integrity-violations.patch new file mode 100644 index 0000000000..38f4dba537 --- /dev/null +++ b/queue-6.14/ima-limit-the-number-of-open-writers-integrity-violations.patch @@ -0,0 +1,68 @@ +From 5b3cd801155f0b34b0b95942a5b057c9b8cad33e Mon Sep 17 00:00:00 2001 +From: Mimi Zohar +Date: Mon, 27 Jan 2025 10:24:13 -0500 +Subject: ima: limit the number of open-writers integrity violations + +From: Mimi Zohar + +commit 5b3cd801155f0b34b0b95942a5b057c9b8cad33e upstream. + +Each time a file in policy, that is already opened for write, is opened +for read, an open-writers integrity violation audit message is emitted +and a violation record is added to the IMA measurement list. This +occurs even if an open-writers violation has already been recorded. + +Limit the number of open-writers integrity violations for an existing +file open for write to one. After the existing file open for write +closes (__fput), subsequent open-writers integrity violations may be +emitted. + +Cc: stable@vger.kernel.org # applies cleanly up to linux-6.6 +Tested-by: Stefan Berger +Reviewed-by: Petr Vorel +Tested-by: Petr Vorel +Reviewed-by: Roberto Sassu +Signed-off-by: Mimi Zohar +Signed-off-by: Greg Kroah-Hartman +--- + security/integrity/ima/ima.h | 1 + + security/integrity/ima/ima_main.c | 11 +++++++++-- + 2 files changed, 10 insertions(+), 2 deletions(-) + +--- a/security/integrity/ima/ima.h ++++ b/security/integrity/ima/ima.h +@@ -182,6 +182,7 @@ struct ima_kexec_hdr { + #define IMA_CHANGE_ATTR 2 + #define IMA_DIGSIG 3 + #define IMA_MUST_MEASURE 4 ++#define IMA_EMITTED_OPENWRITERS 5 + + /* IMA integrity metadata associated with an inode */ + struct ima_iint_cache { +--- a/security/integrity/ima/ima_main.c ++++ b/security/integrity/ima/ima_main.c +@@ -137,8 +137,13 @@ static void ima_rdwr_violation_check(str + } else { + if (must_measure) + set_bit(IMA_MUST_MEASURE, &iint->atomic_flags); +- if (inode_is_open_for_write(inode) && must_measure) +- send_writers = true; ++ ++ /* Limit number of open_writers violations */ ++ if (inode_is_open_for_write(inode) && must_measure) { ++ if (!test_and_set_bit(IMA_EMITTED_OPENWRITERS, ++ &iint->atomic_flags)) ++ send_writers = true; ++ } + } + + if (!send_tomtou && !send_writers) +@@ -167,6 +172,8 @@ static void ima_check_last_writer(struct + if (atomic_read(&inode->i_writecount) == 1) { + struct kstat stat; + ++ clear_bit(IMA_EMITTED_OPENWRITERS, &iint->atomic_flags); ++ + update = test_and_clear_bit(IMA_UPDATE_XATTR, + &iint->atomic_flags); + if ((iint->flags & IMA_NEW_FILE) || diff --git a/queue-6.14/ima-limit-the-number-of-tomtou-integrity-violations.patch b/queue-6.14/ima-limit-the-number-of-tomtou-integrity-violations.patch new file mode 100644 index 0000000000..5084d104d9 --- /dev/null +++ b/queue-6.14/ima-limit-the-number-of-tomtou-integrity-violations.patch @@ -0,0 +1,68 @@ +From a414016218ca97140171aa3bb926b02e1f68c2cc Mon Sep 17 00:00:00 2001 +From: Mimi Zohar +Date: Mon, 27 Jan 2025 10:45:48 -0500 +Subject: ima: limit the number of ToMToU integrity violations + +From: Mimi Zohar + +commit a414016218ca97140171aa3bb926b02e1f68c2cc upstream. + +Each time a file in policy, that is already opened for read, is opened +for write, a Time-of-Measure-Time-of-Use (ToMToU) integrity violation +audit message is emitted and a violation record is added to the IMA +measurement list. This occurs even if a ToMToU violation has already +been recorded. + +Limit the number of ToMToU integrity violations per file open for read. + +Note: The IMA_MAY_EMIT_TOMTOU atomic flag must be set from the reader +side based on policy. This may result in a per file open for read +ToMToU violation. + +Since IMA_MUST_MEASURE is only used for violations, rename the atomic +IMA_MUST_MEASURE flag to IMA_MAY_EMIT_TOMTOU. + +Cc: stable@vger.kernel.org # applies cleanly up to linux-6.6 +Tested-by: Stefan Berger +Reviewed-by: Petr Vorel +Tested-by: Petr Vorel +Reviewed-by: Roberto Sassu +Signed-off-by: Mimi Zohar +Signed-off-by: Greg Kroah-Hartman +--- + security/integrity/ima/ima.h | 2 +- + security/integrity/ima/ima_main.c | 7 ++++--- + 2 files changed, 5 insertions(+), 4 deletions(-) + +--- a/security/integrity/ima/ima.h ++++ b/security/integrity/ima/ima.h +@@ -181,7 +181,7 @@ struct ima_kexec_hdr { + #define IMA_UPDATE_XATTR 1 + #define IMA_CHANGE_ATTR 2 + #define IMA_DIGSIG 3 +-#define IMA_MUST_MEASURE 4 ++#define IMA_MAY_EMIT_TOMTOU 4 + #define IMA_EMITTED_OPENWRITERS 5 + + /* IMA integrity metadata associated with an inode */ +--- a/security/integrity/ima/ima_main.c ++++ b/security/integrity/ima/ima_main.c +@@ -129,14 +129,15 @@ static void ima_rdwr_violation_check(str + if (atomic_read(&inode->i_readcount) && IS_IMA(inode)) { + if (!iint) + iint = ima_iint_find(inode); ++ + /* IMA_MEASURE is set from reader side */ +- if (iint && test_bit(IMA_MUST_MEASURE, +- &iint->atomic_flags)) ++ if (iint && test_and_clear_bit(IMA_MAY_EMIT_TOMTOU, ++ &iint->atomic_flags)) + send_tomtou = true; + } + } else { + if (must_measure) +- set_bit(IMA_MUST_MEASURE, &iint->atomic_flags); ++ set_bit(IMA_MAY_EMIT_TOMTOU, &iint->atomic_flags); + + /* Limit number of open_writers violations */ + if (inode_is_open_for_write(inode) && must_measure) { diff --git a/queue-6.14/jbd2-remove-wrong-sb-s_sequence-check.patch b/queue-6.14/jbd2-remove-wrong-sb-s_sequence-check.patch new file mode 100644 index 0000000000..a734c19fd6 --- /dev/null +++ b/queue-6.14/jbd2-remove-wrong-sb-s_sequence-check.patch @@ -0,0 +1,34 @@ +From e6eff39dd0fe4190c6146069cc16d160e71d1148 Mon Sep 17 00:00:00 2001 +From: Jan Kara +Date: Thu, 6 Feb 2025 10:46:58 +0100 +Subject: jbd2: remove wrong sb->s_sequence check + +From: Jan Kara + +commit e6eff39dd0fe4190c6146069cc16d160e71d1148 upstream. + +Journal emptiness is not determined by sb->s_sequence == 0 but rather by +sb->s_start == 0 (which is set a few lines above). Furthermore 0 is a +valid transaction ID so the check can spuriously trigger. Remove the +invalid WARN_ON. + +CC: stable@vger.kernel.org +Signed-off-by: Jan Kara +Reviewed-by: Zhang Yi +Link: https://patch.msgid.link/20250206094657.20865-3-jack@suse.cz +Signed-off-by: Theodore Ts'o +Signed-off-by: Greg Kroah-Hartman +--- + fs/jbd2/journal.c | 1 - + 1 file changed, 1 deletion(-) + +--- a/fs/jbd2/journal.c ++++ b/fs/jbd2/journal.c +@@ -1879,7 +1879,6 @@ int jbd2_journal_update_sb_log_tail(jour + + /* Log is no longer empty */ + write_lock(&journal->j_state_lock); +- WARN_ON(!sb->s_sequence); + journal->j_flags &= ~JBD2_FLUSHED; + write_unlock(&journal->j_state_lock); + diff --git a/queue-6.14/kbuild-add-fno-builtin-wcslen.patch b/queue-6.14/kbuild-add-fno-builtin-wcslen.patch new file mode 100644 index 0000000000..b260e9f8cc --- /dev/null +++ b/queue-6.14/kbuild-add-fno-builtin-wcslen.patch @@ -0,0 +1,57 @@ +From 84ffc79bfbf70c779e60218563f2f3ad45288671 Mon Sep 17 00:00:00 2001 +From: Nathan Chancellor +Date: Mon, 7 Apr 2025 16:22:12 -0700 +Subject: kbuild: Add '-fno-builtin-wcslen' + +From: Nathan Chancellor + +commit 84ffc79bfbf70c779e60218563f2f3ad45288671 upstream. + +A recent optimization change in LLVM [1] aims to transform certain loop +idioms into calls to strlen() or wcslen(). This change transforms the +first while loop in UniStrcat() into a call to wcslen(), breaking the +build when UniStrcat() gets inlined into alloc_path_with_tree_prefix(): + + ld.lld: error: undefined symbol: wcslen + >>> referenced by nls_ucs2_utils.h:54 (fs/smb/client/../../nls/nls_ucs2_utils.h:54) + >>> vmlinux.o:(alloc_path_with_tree_prefix) + >>> referenced by nls_ucs2_utils.h:54 (fs/smb/client/../../nls/nls_ucs2_utils.h:54) + >>> vmlinux.o:(alloc_path_with_tree_prefix) + +Disable this optimization with '-fno-builtin-wcslen', which prevents the +compiler from assuming that wcslen() is available in the kernel's C +library. + +[ More to the point - it's not that we couldn't implement wcslen(), it's + that this isn't an optimization at all in the context of the kernel. + + Replacing a simple inlined loop with a function call to the same loop + is just stupid and pointless if you don't have long strings and fancy + libraries with vectorization support etc. + + For the regular 'strlen()' cases, we want the compiler to do this in + order to handle the trivial case of constant strings. And we do have + optimized versions of 'strlen()' on some architectures. But for + wcslen? Just no. - Linus ] + +Cc: stable@vger.kernel.org +Link: https://github.com/llvm/llvm-project/commit/9694844d7e36fd5e01011ab56b64f27b867aa72d [1] +Signed-off-by: Nathan Chancellor +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + Makefile | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/Makefile ++++ b/Makefile +@@ -1065,6 +1065,9 @@ ifdef CONFIG_CC_IS_GCC + KBUILD_CFLAGS += -fconserve-stack + endif + ++# Ensure compilers do not transform certain loops into calls to wcslen() ++KBUILD_CFLAGS += -fno-builtin-wcslen ++ + # change __FILE__ to the relative path to the source directory + ifdef building_out_of_srctree + KBUILD_CPPFLAGS += $(call cc-option,-fmacro-prefix-map=$(srcroot)/=) diff --git a/queue-6.14/kbuild-exclude-.rodata.-cst-str-when-building-ranges.patch b/queue-6.14/kbuild-exclude-.rodata.-cst-str-when-building-ranges.patch new file mode 100644 index 0000000000..ea1d616b86 --- /dev/null +++ b/queue-6.14/kbuild-exclude-.rodata.-cst-str-when-building-ranges.patch @@ -0,0 +1,42 @@ +From 87bb368d0637c466a8a77433837056f981d01991 Mon Sep 17 00:00:00 2001 +From: Kris Van Hees +Date: Fri, 7 Mar 2025 11:53:28 -0500 +Subject: kbuild: exclude .rodata.(cst|str)* when building ranges + +From: Kris Van Hees + +commit 87bb368d0637c466a8a77433837056f981d01991 upstream. + +The .rodata.(cst|str)* sections are often resized during the final +linking and since these sections do not cover actual symbols there is +no need to include them in the modules.builtin.ranges data. + +When these sections were included in processing and resizing occurred, +modules were reported with ranges that extended beyond their true end, +causing subsequent symbols (in address order) to be associated with +the wrong module. + +Fixes: 5f5e7344322f ("kbuild: generate offset range data for builtin modules") +Cc: stable@vger.kernel.org +Signed-off-by: Kris Van Hees +Reviewed-by: Jack Vogel +Signed-off-by: Masahiro Yamada +Signed-off-by: Greg Kroah-Hartman +--- + scripts/generate_builtin_ranges.awk | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/scripts/generate_builtin_ranges.awk ++++ b/scripts/generate_builtin_ranges.awk +@@ -282,6 +282,11 @@ ARGIND == 2 && !anchor && NF == 2 && $1 + # section. + # + ARGIND == 2 && sect && NF == 4 && /^ [^ \*]/ && !($1 in sect_addend) { ++ # There are a few sections with constant data (without symbols) that ++ # can get resized during linking, so it is best to ignore them. ++ if ($1 ~ /^\.rodata\.(cst|str)[0-9]/) ++ next; ++ + if (!($1 in sect_base)) { + sect_base[$1] = base; + diff --git a/queue-6.14/leds-rgb-leds-qcom-lpg-fix-calculation-of-best-period-hi-res-pwms.patch b/queue-6.14/leds-rgb-leds-qcom-lpg-fix-calculation-of-best-period-hi-res-pwms.patch new file mode 100644 index 0000000000..71dbb6f4b1 --- /dev/null +++ b/queue-6.14/leds-rgb-leds-qcom-lpg-fix-calculation-of-best-period-hi-res-pwms.patch @@ -0,0 +1,59 @@ +From 2528eec7da0ec58fcae6d12cfa79a622c933d86b Mon Sep 17 00:00:00 2001 +From: Abel Vesa +Date: Wed, 5 Mar 2025 15:09:06 +0200 +Subject: leds: rgb: leds-qcom-lpg: Fix calculation of best period Hi-Res PWMs + +From: Abel Vesa + +commit 2528eec7da0ec58fcae6d12cfa79a622c933d86b upstream. + +When determining the actual best period by looping through all +possible PWM configs, the resolution currently used is based on +bit shift value which is off-by-one above the possible maximum +PWM value allowed. + +So subtract one from the resolution before determining the best +period so that the maximum duty cycle requested by the PWM user +won't result in a value above the maximum allowed by the selected +resolution. + +Cc: stable@vger.kernel.org # 6.4 +Fixes: b00d2ed37617 ("leds: rgb: leds-qcom-lpg: Add support for high resolution PWM") +Signed-off-by: Abel Vesa +Reviewed-by: Sebastian Reichel +Link: https://lore.kernel.org/r/20250305-leds-qcom-lpg-fix-max-pwm-on-hi-res-v4-3-bfe124a53a9f@linaro.org +Signed-off-by: Lee Jones +Signed-off-by: Greg Kroah-Hartman +--- + drivers/leds/rgb/leds-qcom-lpg.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/drivers/leds/rgb/leds-qcom-lpg.c ++++ b/drivers/leds/rgb/leds-qcom-lpg.c +@@ -461,7 +461,7 @@ static int lpg_calc_freq(struct lpg_chan + max_res = LPG_RESOLUTION_9BIT; + } + +- min_period = div64_u64((u64)NSEC_PER_SEC * (1 << pwm_resolution_arr[0]), ++ min_period = div64_u64((u64)NSEC_PER_SEC * ((1 << pwm_resolution_arr[0]) - 1), + clk_rate_arr[clk_len - 1]); + if (period <= min_period) + return -EINVAL; +@@ -482,7 +482,7 @@ static int lpg_calc_freq(struct lpg_chan + */ + + for (i = 0; i < pwm_resolution_count; i++) { +- resolution = 1 << pwm_resolution_arr[i]; ++ resolution = (1 << pwm_resolution_arr[i]) - 1; + for (clk_sel = 1; clk_sel < clk_len; clk_sel++) { + u64 numerator = period * clk_rate_arr[clk_sel]; + +@@ -1291,7 +1291,7 @@ static int lpg_pwm_get_state(struct pwm_ + if (ret) + return ret; + +- state->period = DIV_ROUND_UP_ULL((u64)NSEC_PER_SEC * (1 << resolution) * ++ state->period = DIV_ROUND_UP_ULL((u64)NSEC_PER_SEC * ((1 << resolution) - 1) * + pre_div * (1 << m), refclk); + state->duty_cycle = DIV_ROUND_UP_ULL((u64)NSEC_PER_SEC * pwm_value * pre_div * (1 << m), refclk); + } else { diff --git a/queue-6.14/leds-rgb-leds-qcom-lpg-fix-pwm-resolution-max-for-hi-res-pwms.patch b/queue-6.14/leds-rgb-leds-qcom-lpg-fix-pwm-resolution-max-for-hi-res-pwms.patch new file mode 100644 index 0000000000..a8b3b48b02 --- /dev/null +++ b/queue-6.14/leds-rgb-leds-qcom-lpg-fix-pwm-resolution-max-for-hi-res-pwms.patch @@ -0,0 +1,54 @@ +From b7881eacc07fdf50be3f33c662997541bb59366d Mon Sep 17 00:00:00 2001 +From: Abel Vesa +Date: Wed, 5 Mar 2025 15:09:05 +0200 +Subject: leds: rgb: leds-qcom-lpg: Fix pwm resolution max for Hi-Res PWMs + +From: Abel Vesa + +commit b7881eacc07fdf50be3f33c662997541bb59366d upstream. + +Ideally, the requested duty cycle should never translate to a PWM +value higher than the selected resolution (PWM size), but currently the +best matched period is never reported back to the PWM consumer, so the +consumer will still be using the requested period which is higher than +the best matched one. This will result in PWM consumer requesting +duty cycle values higher than the allowed PWM value. + +For example, a consumer might request a period of 5ms while the best +(closest) period the PWM hardware will do is 4.26ms. For this best +matched resolution, if the selected resolution is 8-bit wide, when +the consumer asks for a duty cycle of 5ms, the PWM value will be 300, +which is outside of what the resolution allows. This will happen with +all possible resolutions when selected. + +Since for these Hi-Res PWMs, the current implementation is capping the PWM +value at a 15-bit resolution, even when lower resolutions are selected, +the value will be wrapped around by the HW internal logic to the selected +resolution. + +Fix the issue by capping the PWM value to the maximum value allowed by +the selected resolution. + +Cc: stable@vger.kernel.org # 6.4 +Fixes: b00d2ed37617 ("leds: rgb: leds-qcom-lpg: Add support for high resolution PWM") +Signed-off-by: Abel Vesa +Reviewed-by: Bjorn Andersson +Reviewed-by: Sebastian Reichel +Link: https://lore.kernel.org/r/20250305-leds-qcom-lpg-fix-max-pwm-on-hi-res-v4-2-bfe124a53a9f@linaro.org +Signed-off-by: Lee Jones +Signed-off-by: Greg Kroah-Hartman +--- + drivers/leds/rgb/leds-qcom-lpg.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/leds/rgb/leds-qcom-lpg.c ++++ b/drivers/leds/rgb/leds-qcom-lpg.c +@@ -529,7 +529,7 @@ static void lpg_calc_duty(struct lpg_cha + unsigned int clk_rate; + + if (chan->subtype == LPG_SUBTYPE_HI_RES_PWM) { +- max = LPG_RESOLUTION_15BIT - 1; ++ max = BIT(lpg_pwm_resolution_hi_res[chan->pwm_resolution_sel]) - 1; + clk_rate = lpg_clk_rates_hi_res[chan->clk_sel]; + } else { + max = LPG_RESOLUTION_9BIT - 1; diff --git a/queue-6.14/lib-scatterlist-fix-sg_split_phys-to-preserve-original-scatterlist-offsets.patch b/queue-6.14/lib-scatterlist-fix-sg_split_phys-to-preserve-original-scatterlist-offsets.patch new file mode 100644 index 0000000000..d921bdb250 --- /dev/null +++ b/queue-6.14/lib-scatterlist-fix-sg_split_phys-to-preserve-original-scatterlist-offsets.patch @@ -0,0 +1,56 @@ +From 8b46fdaea819a679da176b879e7b0674a1161a5e Mon Sep 17 00:00:00 2001 +From: T Pratham +Date: Wed, 19 Mar 2025 16:44:38 +0530 +Subject: lib: scatterlist: fix sg_split_phys to preserve original scatterlist offsets + +From: T Pratham + +commit 8b46fdaea819a679da176b879e7b0674a1161a5e upstream. + +The split_sg_phys function was incorrectly setting the offsets of all +scatterlist entries (except the first) to 0. Only the first scatterlist +entry's offset and length needs to be modified to account for the skip. +Setting the rest entries' offsets to 0 could lead to incorrect data +access. + +I am using this function in a crypto driver that I'm currently developing +(not yet sent to mailing list). During testing, it was observed that the +output scatterlists (except the first one) contained incorrect garbage +data. + +I narrowed this issue down to the call of sg_split(). Upon debugging +inside this function, I found that this resetting of offset is the cause +of the problem, causing the subsequent scatterlists to point to incorrect +memory locations in a page. By removing this code, I am obtaining +expected data in all the split output scatterlists. Thus, this was indeed +causing observable runtime effects! + +This patch removes the offending code, ensuring that the page offsets in +the input scatterlist are preserved in the output scatterlist. + +Link: https://lkml.kernel.org/r/20250319111437.1969903-1-t-pratham@ti.com +Fixes: f8bcbe62acd0 ("lib: scatterlist: add sg splitting function") +Signed-off-by: T Pratham +Cc: Robert Jarzmik +Cc: Jens Axboe +Cc: Kamlesh Gurudasani +Cc: Praneeth Bajjuri +Cc: Vignesh Raghavendra +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + lib/sg_split.c | 2 -- + 1 file changed, 2 deletions(-) + +--- a/lib/sg_split.c ++++ b/lib/sg_split.c +@@ -88,8 +88,6 @@ static void sg_split_phys(struct sg_spli + if (!j) { + out_sg->offset += split->skip_sg0; + out_sg->length -= split->skip_sg0; +- } else { +- out_sg->offset = 0; + } + sg_dma_address(out_sg) = 0; + sg_dma_len(out_sg) = 0; diff --git a/queue-6.14/locking-lockdep-decrease-nr_unused_locks-if-lock-unused-in-zap_class.patch b/queue-6.14/locking-lockdep-decrease-nr_unused_locks-if-lock-unused-in-zap_class.patch new file mode 100644 index 0000000000..50a0c8c12f --- /dev/null +++ b/queue-6.14/locking-lockdep-decrease-nr_unused_locks-if-lock-unused-in-zap_class.patch @@ -0,0 +1,47 @@ +From 495f53d5cca0f939eaed9dca90b67e7e6fb0e30c Mon Sep 17 00:00:00 2001 +From: Boqun Feng +Date: Wed, 26 Mar 2025 11:08:30 -0700 +Subject: locking/lockdep: Decrease nr_unused_locks if lock unused in zap_class() + +From: Boqun Feng + +commit 495f53d5cca0f939eaed9dca90b67e7e6fb0e30c upstream. + +Currently, when a lock class is allocated, nr_unused_locks will be +increased by 1, until it gets used: nr_unused_locks will be decreased by +1 in mark_lock(). However, one scenario is missed: a lock class may be +zapped without even being used once. This could result into a situation +that nr_unused_locks != 0 but no unused lock class is active in the +system, and when `cat /proc/lockdep_stats`, a WARN_ON() will +be triggered in a CONFIG_DEBUG_LOCKDEP=y kernel: + + [...] DEBUG_LOCKS_WARN_ON(debug_atomic_read(nr_unused_locks) != nr_unused) + [...] WARNING: CPU: 41 PID: 1121 at kernel/locking/lockdep_proc.c:283 lockdep_stats_show+0xba9/0xbd0 + +And as a result, lockdep will be disabled after this. + +Therefore, nr_unused_locks needs to be accounted correctly at +zap_class() time. + +Signed-off-by: Boqun Feng +Signed-off-by: Ingo Molnar +Reviewed-by: Waiman Long +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20250326180831.510348-1-boqun.feng@gmail.com +Signed-off-by: Greg Kroah-Hartman +--- + kernel/locking/lockdep.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/kernel/locking/lockdep.c ++++ b/kernel/locking/lockdep.c +@@ -6249,6 +6249,9 @@ static void zap_class(struct pending_fre + hlist_del_rcu(&class->hash_entry); + WRITE_ONCE(class->key, NULL); + WRITE_ONCE(class->name, NULL); ++ /* Class allocated but not used, -1 in nr_unused_locks */ ++ if (class->usage_mask == 0) ++ debug_atomic_dec(nr_unused_locks); + nr_lock_classes--; + __clear_bit(class - lock_classes, lock_classes_in_use); + if (class - lock_classes == max_lock_class_idx) diff --git a/queue-6.14/mailbox-tegra-hsp-define-dimensioning-masks-in-soc-data.patch b/queue-6.14/mailbox-tegra-hsp-define-dimensioning-masks-in-soc-data.patch new file mode 100644 index 0000000000..e6660e9036 --- /dev/null +++ b/queue-6.14/mailbox-tegra-hsp-define-dimensioning-masks-in-soc-data.patch @@ -0,0 +1,160 @@ +From bf0c9fb462038815f5f502653fb6dba06e6af415 Mon Sep 17 00:00:00 2001 +From: Kartik Rajput +Date: Thu, 23 Jan 2025 18:16:32 +0530 +Subject: mailbox: tegra-hsp: Define dimensioning masks in SoC data + +From: Kartik Rajput + +commit bf0c9fb462038815f5f502653fb6dba06e6af415 upstream. + +Tegra264 has updated HSP_INT_DIMENSIONING register as follows: + * nSI is now BIT17:BIT21. + * nDB is now BIT12:BIT16. + +Currently, we are using a static macro HSP_nINT_MASK to get the values +from HSP_INT_DIMENSIONING register. This results in wrong values for nSI +for HSP instances that supports 16 shared interrupts. + +Define dimensioning masks in soc data and use them to parse nSI, nDB, +nAS, nSS & nSM values. + +Fixes: 602dbbacc3ef ("mailbox: tegra: add support for Tegra264") +Cc: stable@vger.kernel.org +Signed-off-by: Kartik Rajput +Acked-by: Thierry Reding +Acked-by: Jon Hunter +Signed-off-by: Jassi Brar +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mailbox/tegra-hsp.c | 72 ++++++++++++++++++++++++++++++++++++-------- + 1 file changed, 60 insertions(+), 12 deletions(-) + +--- a/drivers/mailbox/tegra-hsp.c ++++ b/drivers/mailbox/tegra-hsp.c +@@ -1,6 +1,6 @@ + // SPDX-License-Identifier: GPL-2.0-only + /* +- * Copyright (c) 2016-2023, NVIDIA CORPORATION. All rights reserved. ++ * Copyright (c) 2016-2025, NVIDIA CORPORATION. All rights reserved. + */ + + #include +@@ -28,12 +28,6 @@ + #define HSP_INT_FULL_MASK 0xff + + #define HSP_INT_DIMENSIONING 0x380 +-#define HSP_nSM_SHIFT 0 +-#define HSP_nSS_SHIFT 4 +-#define HSP_nAS_SHIFT 8 +-#define HSP_nDB_SHIFT 12 +-#define HSP_nSI_SHIFT 16 +-#define HSP_nINT_MASK 0xf + + #define HSP_DB_TRIGGER 0x0 + #define HSP_DB_ENABLE 0x4 +@@ -97,6 +91,20 @@ struct tegra_hsp_soc { + bool has_per_mb_ie; + bool has_128_bit_mb; + unsigned int reg_stride; ++ ++ /* Shifts for dimensioning register. */ ++ unsigned int si_shift; ++ unsigned int db_shift; ++ unsigned int as_shift; ++ unsigned int ss_shift; ++ unsigned int sm_shift; ++ ++ /* Masks for dimensioning register. */ ++ unsigned int si_mask; ++ unsigned int db_mask; ++ unsigned int as_mask; ++ unsigned int ss_mask; ++ unsigned int sm_mask; + }; + + struct tegra_hsp { +@@ -747,11 +755,11 @@ static int tegra_hsp_probe(struct platfo + return PTR_ERR(hsp->regs); + + value = tegra_hsp_readl(hsp, HSP_INT_DIMENSIONING); +- hsp->num_sm = (value >> HSP_nSM_SHIFT) & HSP_nINT_MASK; +- hsp->num_ss = (value >> HSP_nSS_SHIFT) & HSP_nINT_MASK; +- hsp->num_as = (value >> HSP_nAS_SHIFT) & HSP_nINT_MASK; +- hsp->num_db = (value >> HSP_nDB_SHIFT) & HSP_nINT_MASK; +- hsp->num_si = (value >> HSP_nSI_SHIFT) & HSP_nINT_MASK; ++ hsp->num_sm = (value >> hsp->soc->sm_shift) & hsp->soc->sm_mask; ++ hsp->num_ss = (value >> hsp->soc->ss_shift) & hsp->soc->ss_mask; ++ hsp->num_as = (value >> hsp->soc->as_shift) & hsp->soc->as_mask; ++ hsp->num_db = (value >> hsp->soc->db_shift) & hsp->soc->db_mask; ++ hsp->num_si = (value >> hsp->soc->si_shift) & hsp->soc->si_mask; + + err = platform_get_irq_byname_optional(pdev, "doorbell"); + if (err >= 0) +@@ -915,6 +923,16 @@ static const struct tegra_hsp_soc tegra1 + .has_per_mb_ie = false, + .has_128_bit_mb = false, + .reg_stride = 0x100, ++ .si_shift = 16, ++ .db_shift = 12, ++ .as_shift = 8, ++ .ss_shift = 4, ++ .sm_shift = 0, ++ .si_mask = 0xf, ++ .db_mask = 0xf, ++ .as_mask = 0xf, ++ .ss_mask = 0xf, ++ .sm_mask = 0xf, + }; + + static const struct tegra_hsp_soc tegra194_hsp_soc = { +@@ -922,6 +940,16 @@ static const struct tegra_hsp_soc tegra1 + .has_per_mb_ie = true, + .has_128_bit_mb = false, + .reg_stride = 0x100, ++ .si_shift = 16, ++ .db_shift = 12, ++ .as_shift = 8, ++ .ss_shift = 4, ++ .sm_shift = 0, ++ .si_mask = 0xf, ++ .db_mask = 0xf, ++ .as_mask = 0xf, ++ .ss_mask = 0xf, ++ .sm_mask = 0xf, + }; + + static const struct tegra_hsp_soc tegra234_hsp_soc = { +@@ -929,6 +957,16 @@ static const struct tegra_hsp_soc tegra2 + .has_per_mb_ie = false, + .has_128_bit_mb = true, + .reg_stride = 0x100, ++ .si_shift = 16, ++ .db_shift = 12, ++ .as_shift = 8, ++ .ss_shift = 4, ++ .sm_shift = 0, ++ .si_mask = 0xf, ++ .db_mask = 0xf, ++ .as_mask = 0xf, ++ .ss_mask = 0xf, ++ .sm_mask = 0xf, + }; + + static const struct tegra_hsp_soc tegra264_hsp_soc = { +@@ -936,6 +974,16 @@ static const struct tegra_hsp_soc tegra2 + .has_per_mb_ie = false, + .has_128_bit_mb = true, + .reg_stride = 0x1000, ++ .si_shift = 17, ++ .db_shift = 12, ++ .as_shift = 8, ++ .ss_shift = 4, ++ .sm_shift = 0, ++ .si_mask = 0x1f, ++ .db_mask = 0x1f, ++ .as_mask = 0xf, ++ .ss_mask = 0xf, ++ .sm_mask = 0xf, + }; + + static const struct of_device_id tegra_hsp_match[] = { diff --git a/queue-6.14/mfd-ene-kb3930-fix-a-potential-null-pointer-dereference.patch b/queue-6.14/mfd-ene-kb3930-fix-a-potential-null-pointer-dereference.patch new file mode 100644 index 0000000000..2831e390dd --- /dev/null +++ b/queue-6.14/mfd-ene-kb3930-fix-a-potential-null-pointer-dereference.patch @@ -0,0 +1,37 @@ +From 4cdf1d2a816a93fa02f7b6b5492dc7f55af2a199 Mon Sep 17 00:00:00 2001 +From: Chenyuan Yang +Date: Mon, 24 Feb 2025 17:37:36 -0600 +Subject: mfd: ene-kb3930: Fix a potential NULL pointer dereference + +From: Chenyuan Yang + +commit 4cdf1d2a816a93fa02f7b6b5492dc7f55af2a199 upstream. + +The off_gpios could be NULL. Add missing check in the kb3930_probe(). +This is similar to the issue fixed in commit b1ba8bcb2d1f +("backlight: hx8357: Fix potential NULL pointer dereference"). + +This was detected by our static analysis tool. + +Cc: stable@vger.kernel.org +Fixes: ede6b2d1dfc0 ("mfd: ene-kb3930: Add driver for ENE KB3930 Embedded Controller") +Suggested-by: Lee Jones +Signed-off-by: Chenyuan Yang +Link: https://lore.kernel.org/r/20250224233736.1919739-1-chenyuan0y@gmail.com +Signed-off-by: Lee Jones +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mfd/ene-kb3930.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/mfd/ene-kb3930.c ++++ b/drivers/mfd/ene-kb3930.c +@@ -162,7 +162,7 @@ static int kb3930_probe(struct i2c_clien + devm_gpiod_get_array_optional(dev, "off", GPIOD_IN); + if (IS_ERR(ddata->off_gpios)) + return PTR_ERR(ddata->off_gpios); +- if (ddata->off_gpios->ndescs < 2) { ++ if (ddata->off_gpios && ddata->off_gpios->ndescs < 2) { + dev_err(dev, "invalid off-gpios property\n"); + return -EINVAL; + } diff --git a/queue-6.14/mptcp-fix-null-pointer-in-can_accept_new_subflow.patch b/queue-6.14/mptcp-fix-null-pointer-in-can_accept_new_subflow.patch new file mode 100644 index 0000000000..4ea5312267 --- /dev/null +++ b/queue-6.14/mptcp-fix-null-pointer-in-can_accept_new_subflow.patch @@ -0,0 +1,92 @@ +From 443041deb5ef6a1289a99ed95015ec7442f141dc Mon Sep 17 00:00:00 2001 +From: Gang Yan +Date: Fri, 28 Mar 2025 15:27:16 +0100 +Subject: mptcp: fix NULL pointer in can_accept_new_subflow + +From: Gang Yan + +commit 443041deb5ef6a1289a99ed95015ec7442f141dc upstream. + +When testing valkey benchmark tool with MPTCP, the kernel panics in +'mptcp_can_accept_new_subflow' because subflow_req->msk is NULL. + +Call trace: + + mptcp_can_accept_new_subflow (./net/mptcp/subflow.c:63 (discriminator 4)) (P) + subflow_syn_recv_sock (./net/mptcp/subflow.c:854) + tcp_check_req (./net/ipv4/tcp_minisocks.c:863) + tcp_v4_rcv (./net/ipv4/tcp_ipv4.c:2268) + ip_protocol_deliver_rcu (./net/ipv4/ip_input.c:207) + ip_local_deliver_finish (./net/ipv4/ip_input.c:234) + ip_local_deliver (./net/ipv4/ip_input.c:254) + ip_rcv_finish (./net/ipv4/ip_input.c:449) + ... + +According to the debug log, the same req received two SYN-ACK in a very +short time, very likely because the client retransmits the syn ack due +to multiple reasons. + +Even if the packets are transmitted with a relevant time interval, they +can be processed by the server on different CPUs concurrently). The +'subflow_req->msk' ownership is transferred to the subflow the first, +and there will be a risk of a null pointer dereference here. + +This patch fixes this issue by moving the 'subflow_req->msk' under the +`own_req == true` conditional. + +Note that the !msk check in subflow_hmac_valid() can be dropped, because +the same check already exists under the own_req mpj branch where the +code has been moved to. + +Fixes: 9466a1ccebbe ("mptcp: enable JOIN requests even if cookies are in use") +Cc: stable@vger.kernel.org +Suggested-by: Paolo Abeni +Signed-off-by: Gang Yan +Reviewed-by: Matthieu Baerts (NGI0) +Signed-off-by: Matthieu Baerts (NGI0) +Link: https://patch.msgid.link/20250328-net-mptcp-misc-fixes-6-15-v1-1-34161a482a7f@kernel.org +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/mptcp/subflow.c | 15 ++++++++------- + 1 file changed, 8 insertions(+), 7 deletions(-) + +--- a/net/mptcp/subflow.c ++++ b/net/mptcp/subflow.c +@@ -754,8 +754,6 @@ static bool subflow_hmac_valid(const str + + subflow_req = mptcp_subflow_rsk(req); + msk = subflow_req->msk; +- if (!msk) +- return false; + + subflow_generate_hmac(READ_ONCE(msk->remote_key), + READ_ONCE(msk->local_key), +@@ -853,12 +851,8 @@ static struct sock *subflow_syn_recv_soc + + } else if (subflow_req->mp_join) { + mptcp_get_options(skb, &mp_opt); +- if (!(mp_opt.suboptions & OPTION_MPTCP_MPJ_ACK) || +- !subflow_hmac_valid(req, &mp_opt) || +- !mptcp_can_accept_new_subflow(subflow_req->msk)) { +- SUBFLOW_REQ_INC_STATS(req, MPTCP_MIB_JOINACKMAC); ++ if (!(mp_opt.suboptions & OPTION_MPTCP_MPJ_ACK)) + fallback = true; +- } + } + + create_child: +@@ -907,6 +901,13 @@ create_child: + subflow_add_reset_reason(skb, MPTCP_RST_EPROHIBIT); + goto dispose_child; + } ++ ++ if (!subflow_hmac_valid(req, &mp_opt) || ++ !mptcp_can_accept_new_subflow(subflow_req->msk)) { ++ SUBFLOW_REQ_INC_STATS(req, MPTCP_MIB_JOINACKMAC); ++ subflow_add_reset_reason(skb, MPTCP_RST_EPROHIBIT); ++ goto dispose_child; ++ } + + /* move the msk reference ownership to the subflow */ + subflow_req->msk = NULL; diff --git a/queue-6.14/mptcp-only-inc-mpjoinackhmacfailure-for-hmac-failures.patch b/queue-6.14/mptcp-only-inc-mpjoinackhmacfailure-for-hmac-failures.patch new file mode 100644 index 0000000000..14a465901b --- /dev/null +++ b/queue-6.14/mptcp-only-inc-mpjoinackhmacfailure-for-hmac-failures.patch @@ -0,0 +1,50 @@ +From 21c02e8272bc95ba0dd44943665c669029b42760 Mon Sep 17 00:00:00 2001 +From: "Matthieu Baerts (NGI0)" +Date: Mon, 7 Apr 2025 20:26:32 +0200 +Subject: mptcp: only inc MPJoinAckHMacFailure for HMAC failures + +From: Matthieu Baerts (NGI0) + +commit 21c02e8272bc95ba0dd44943665c669029b42760 upstream. + +Recently, during a debugging session using local MPTCP connections, I +noticed MPJoinAckHMacFailure was not zero on the server side. The +counter was in fact incremented when the PM rejected new subflows, +because the 'subflow' limit was reached. + +The fix is easy, simply dissociating the two cases: only the HMAC +validation check should increase MPTCP_MIB_JOINACKMAC counter. + +Fixes: 4cf8b7e48a09 ("subflow: introduce and use mptcp_can_accept_new_subflow()") +Cc: stable@vger.kernel.org +Reviewed-by: Geliang Tang +Signed-off-by: Matthieu Baerts (NGI0) +Reviewed-by: Simon Horman +Link: https://patch.msgid.link/20250407-net-mptcp-hmac-failure-mib-v1-1-3c9ecd0a3a50@kernel.org +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/mptcp/subflow.c | 8 ++++++-- + 1 file changed, 6 insertions(+), 2 deletions(-) + +--- a/net/mptcp/subflow.c ++++ b/net/mptcp/subflow.c +@@ -902,12 +902,16 @@ create_child: + goto dispose_child; + } + +- if (!subflow_hmac_valid(req, &mp_opt) || +- !mptcp_can_accept_new_subflow(subflow_req->msk)) { ++ if (!subflow_hmac_valid(req, &mp_opt)) { + SUBFLOW_REQ_INC_STATS(req, MPTCP_MIB_JOINACKMAC); + subflow_add_reset_reason(skb, MPTCP_RST_EPROHIBIT); + goto dispose_child; + } ++ ++ if (!mptcp_can_accept_new_subflow(owner)) { ++ subflow_add_reset_reason(skb, MPTCP_RST_EPROHIBIT); ++ goto dispose_child; ++ } + + /* move the msk reference ownership to the subflow */ + subflow_req->msk = NULL; diff --git a/queue-6.14/mtd-inftlcore-add-error-check-for-inftl_read_oob.patch b/queue-6.14/mtd-inftlcore-add-error-check-for-inftl_read_oob.patch new file mode 100644 index 0000000000..b086152bbe --- /dev/null +++ b/queue-6.14/mtd-inftlcore-add-error-check-for-inftl_read_oob.patch @@ -0,0 +1,42 @@ +From d027951dc85cb2e15924c980dc22a6754d100c7c Mon Sep 17 00:00:00 2001 +From: Wentao Liang +Date: Wed, 2 Apr 2025 11:16:43 +0800 +Subject: mtd: inftlcore: Add error check for inftl_read_oob() + +From: Wentao Liang + +commit d027951dc85cb2e15924c980dc22a6754d100c7c upstream. + +In INFTL_findwriteunit(), the return value of inftl_read_oob() +need to be checked. A proper implementation can be +found in INFTL_deleteblock(). The status will be set as +SECTOR_IGNORE to break from the while-loop correctly +if the inftl_read_oob() fails. + +Fixes: 8593fbc68b0d ("[MTD] Rework the out of band handling completely") +Cc: stable@vger.kernel.org # v2.6+ +Signed-off-by: Wentao Liang +Signed-off-by: Miquel Raynal +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mtd/inftlcore.c | 9 +++++---- + 1 file changed, 5 insertions(+), 4 deletions(-) + +--- a/drivers/mtd/inftlcore.c ++++ b/drivers/mtd/inftlcore.c +@@ -482,10 +482,11 @@ static inline u16 INFTL_findwriteunit(st + silly = MAX_LOOPS; + + while (thisEUN <= inftl->lastEUN) { +- inftl_read_oob(mtd, (thisEUN * inftl->EraseSize) + +- blockofs, 8, &retlen, (char *)&bci); +- +- status = bci.Status | bci.Status1; ++ if (inftl_read_oob(mtd, (thisEUN * inftl->EraseSize) + ++ blockofs, 8, &retlen, (char *)&bci) < 0) ++ status = SECTOR_IGNORE; ++ else ++ status = bci.Status | bci.Status1; + pr_debug("INFTL: status of block %d in EUN %d is %x\n", + block , writeEUN, status); + diff --git a/queue-6.14/mtd-rawnand-add-status-chack-in-r852_ready.patch b/queue-6.14/mtd-rawnand-add-status-chack-in-r852_ready.patch new file mode 100644 index 0000000000..316a863877 --- /dev/null +++ b/queue-6.14/mtd-rawnand-add-status-chack-in-r852_ready.patch @@ -0,0 +1,35 @@ +From b79fe1829975556854665258cf4d2476784a89db Mon Sep 17 00:00:00 2001 +From: Wentao Liang +Date: Wed, 2 Apr 2025 15:56:23 +0800 +Subject: mtd: rawnand: Add status chack in r852_ready() + +From: Wentao Liang + +commit b79fe1829975556854665258cf4d2476784a89db upstream. + +In r852_ready(), the dev get from r852_get_dev() need to be checked. +An unstable device should not be ready. A proper implementation can +be found in r852_read_byte(). Add a status check and return 0 when it is +unstable. + +Fixes: 50a487e7719c ("mtd: rawnand: Pass a nand_chip object to chip->dev_ready()") +Cc: stable@vger.kernel.org # v4.20+ +Signed-off-by: Wentao Liang +Signed-off-by: Miquel Raynal +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mtd/nand/raw/r852.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/mtd/nand/raw/r852.c ++++ b/drivers/mtd/nand/raw/r852.c +@@ -387,6 +387,9 @@ static int r852_wait(struct nand_chip *c + static int r852_ready(struct nand_chip *chip) + { + struct r852_device *dev = r852_get_dev(nand_to_mtd(chip)); ++ if (dev->card_unstable) ++ return 0; ++ + return !(r852_read_reg(dev, R852_CARD_STA) & R852_CARD_STA_BUSY); + } + diff --git a/queue-6.14/mtd-spinand-fix-build-with-gcc-7.5.patch b/queue-6.14/mtd-spinand-fix-build-with-gcc-7.5.patch new file mode 100644 index 0000000000..6a91f8769d --- /dev/null +++ b/queue-6.14/mtd-spinand-fix-build-with-gcc-7.5.patch @@ -0,0 +1,44 @@ +From 1c1fd374a2fe72b8a6dde62d3c3a9fd153e7581c Mon Sep 17 00:00:00 2001 +From: Miquel Raynal +Date: Tue, 1 Apr 2025 15:36:37 +0200 +Subject: mtd: spinand: Fix build with gcc < 7.5 + +From: Miquel Raynal + +commit 1c1fd374a2fe72b8a6dde62d3c3a9fd153e7581c upstream. + +__VA_OPT__ is a macro that is useful when some arguments can be present +or not to entirely skip some part of a definition. Unfortunately, it +is a too recent addition that some of the still supported old GCC +versions do not know about, and is anyway not part of C11 that is the +version used in the kernel. + +Find a trick to remove this macro, typically '__VA_ARGS__ + 0' is a +workaround used in netlink.h which works very well here, as we either +expect: +- 0 +- A positive value +- No value, which means the field should be 0. + +Reported-by: kernel test robot +Closes: https://lore.kernel.org/oe-kbuild-all/202503181330.YcDXGy7F-lkp@intel.com/ +Fixes: 7ce0d16d5802 ("mtd: spinand: Add an optional frequency to read from cache macros") +Cc: stable@vger.kernel.org +Tested-by: Jean Delvare +Signed-off-by: Miquel Raynal +Signed-off-by: Greg Kroah-Hartman +--- + include/linux/mtd/spinand.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/include/linux/mtd/spinand.h ++++ b/include/linux/mtd/spinand.h +@@ -67,7 +67,7 @@ + SPI_MEM_OP_ADDR(2, addr, 1), \ + SPI_MEM_OP_DUMMY(ndummy, 1), \ + SPI_MEM_OP_DATA_IN(len, buf, 1), \ +- __VA_OPT__(SPI_MEM_OP_MAX_FREQ(__VA_ARGS__))) ++ SPI_MEM_OP_MAX_FREQ(__VA_ARGS__ + 0)) + + #define SPINAND_PAGE_READ_FROM_CACHE_FAST_OP(addr, ndummy, buf, len) \ + SPI_MEM_OP(SPI_MEM_OP_CMD(0x0b, 1), \ diff --git a/queue-6.14/series b/queue-6.14/series index cd8184404a..f429e8e570 100644 --- a/queue-6.14/series +++ b/queue-6.14/series @@ -312,3 +312,35 @@ tpm-do-not-start-chip-while-suspended.patch svcrdma-do-not-unregister-device-for-listeners.patch soc-samsung-exynos-chipid-add-null-pointer-check-in-exynos_chipid_probe.patch smb311-client-fix-missing-tcon-check-when-mounting-with-linux-posix-extensions.patch +ima-limit-the-number-of-open-writers-integrity-violations.patch +ima-limit-the-number-of-tomtou-integrity-violations.patch +igc-fix-xsk-queue-napi-id-mapping.patch +i3c-master-svc-use-readsb-helper-for-reading-mdb.patch +i3c-add-null-pointer-check-in-i3c_master_queue_ibi.patch +jbd2-remove-wrong-sb-s_sequence-check.patch +kbuild-exclude-.rodata.-cst-str-when-building-ranges.patch +kbuild-add-fno-builtin-wcslen.patch +leds-rgb-leds-qcom-lpg-fix-pwm-resolution-max-for-hi-res-pwms.patch +leds-rgb-leds-qcom-lpg-fix-calculation-of-best-period-hi-res-pwms.patch +mfd-ene-kb3930-fix-a-potential-null-pointer-dereference.patch +mailbox-tegra-hsp-define-dimensioning-masks-in-soc-data.patch +locking-lockdep-decrease-nr_unused_locks-if-lock-unused-in-zap_class.patch +lib-scatterlist-fix-sg_split_phys-to-preserve-original-scatterlist-offsets.patch +mptcp-fix-null-pointer-in-can_accept_new_subflow.patch +mptcp-only-inc-mpjoinackhmacfailure-for-hmac-failures.patch +mtd-inftlcore-add-error-check-for-inftl_read_oob.patch +mtd-rawnand-add-status-chack-in-r852_ready.patch +mtd-spinand-fix-build-with-gcc-7.5.patch +arm64-mops-do-not-dereference-src-reg-for-a-set-operation.patch +arm64-tegra-remove-the-orin-nx-nano-suspend-key.patch +arm64-mm-correct-the-update-of-max_pfn.patch +arm64-dts-ti-k3-j784s4-j742s2-main-common-correct-the-gicd-size.patch +arm64-dts-ti-k3-j784s4-j742s2-main-common-fix-serdes_ln_ctrl-reg-masks.patch +arm64-dts-mediatek-mt8188-assign-apll1-clock-as-parent-to-avoid-hang.patch +arm64-dts-mediatek-mt8173-fix-disp-pwm-compatible-string.patch +arm64-dts-exynos-gs101-disable-pinctrl_gsacore-node.patch +backlight-led_bl-hold-led_access-lock-when-calling-led_sysfs_disable.patch +btrfs-fix-non-empty-delayed-iputs-list-on-unmount-due-to-compressed-write-workers.patch +btrfs-tests-fix-chunk-map-leak-after-failure-to-add-it-to-the-tree.patch +btrfs-zoned-fix-zone-activation-with-missing-devices.patch +btrfs-zoned-fix-zone-finishing-with-missing-devices.patch