From: Greg Kroah-Hartman Date: Mon, 26 Jan 2026 13:29:28 +0000 (+0100) Subject: 6.18-stable patches X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=7348af480abb1c749914a95e9757104b675fb30e;p=thirdparty%2Fkernel%2Fstable-queue.git 6.18-stable patches added patches: arm-dts-microchip-sama7d65-fix-size-cells-property-for-i2c3.patch arm-dts-microchip-sama7d65-fix-the-ranges-property-for-flx9.patch arm64-dts-rockchip-configure-mclk-for-analog-sound-on-nanopi-m5.patch arm64-dts-rockchip-fix-headphones-widget-name-on-nanopi-m5.patch arm64-dts-rockchip-fix-unit-address-for-rk3588-npu-s-core1-and-core2-s-iommu.patch arm64-dts-rockchip-fix-voltage-threshold-for-volume-keys-for-pinephone-pro.patch arm64-dts-rockchip-remove-dangerous-max-link-speed-from-helios64.patch arm64-dts-rockchip-remove-redundant-max-link-speed-from-nanopi-r4s.patch comedi-fix-getting-range-information-for-subdevices-16-to-255.patch drm-drm-xe-fix-xe-userptr-in-the-absence-of-config_device_private.patch fs-writeback-skip-as_no_data_integrity-mappings-in-wait_sb_inodes.patch i2c-spacemit-drop-irqf_oneshot-flag-from-irq-request.patch iio-imu-st_lsm6dsx-fix-iio_chan_spec-for-sensors-without-event-detection.patch input-i8042-add-quirk-for-asus-zenbook-ux425qa_um425qa.patch input-i8042-add-quirks-for-mechrevo-wujie-15x-pro.patch io_uring-io-wq-check-io_wq_bit_exit-inside-work-run-loop.patch mm-hugetlb-fix-hugetlb_pmd_shared.patch mm-restore-per-memcg-proactive-reclaim-with-config_numa.patch mm-rmap-fix-two-comments-related-to-huge_pmd_unshare.patch platform-x86-hp-bioscfg-fix-kernel-panic-in-get_instance_id-macro.patch platform-x86-hp-bioscfg-fix-kobject-warnings-for-empty-attribute-names.patch revert-nfc-nci-add-the-inconsistency-check-between-the-input-data-length-and-count.patch rxrpc-fix-recvmsg-unconditional-requeue.patch scsi-storvsc-process-unsupported-mode_sense_10.patch scsi-xen-scsiback-fix-potential-memory-leak-in-scsiback_remove.patch slab-fix-kmalloc_nolock-context-check-for-preempt_rt.patch timekeeping-adjust-the-leap-state-for-the-correct-auxiliary-timekeeper.patch x86-kfence-avoid-writing-l1tf-vulnerable-ptes.patch --- diff --git a/queue-6.18/arm-dts-microchip-sama7d65-fix-size-cells-property-for-i2c3.patch b/queue-6.18/arm-dts-microchip-sama7d65-fix-size-cells-property-for-i2c3.patch new file mode 100644 index 0000000000..3459e2d80b --- /dev/null +++ b/queue-6.18/arm-dts-microchip-sama7d65-fix-size-cells-property-for-i2c3.patch @@ -0,0 +1,39 @@ +From 94ad504e67cd3be94fa1b2fed0cb87da0d8f9396 Mon Sep 17 00:00:00 2001 +From: Nicolas Ferre +Date: Fri, 2 Jan 2026 18:01:31 +0100 +Subject: ARM: dts: microchip: sama7d65: fix size-cells property for i2c3 + +From: Nicolas Ferre + +commit 94ad504e67cd3be94fa1b2fed0cb87da0d8f9396 upstream. + +Fix the #size-cells property for i2c3 node and remove the dtbs_check +error telling that "#size-cells: 0 was expected" from schema +atmel,at91sam-i2c.yaml and i2c-controller.yaml. + +Fixes: b51e4aea3ecf ("ARM: dts: microchip: sama7d65: Add FLEXCOMs to sama7d65 SoC") +Cc: stable@vger.kernel.org # 6.16+ +Signed-off-by: Nicolas Ferre +Link: https://lore.kernel.org/r/20260102170135.70717-3-nicolas.ferre@microchip.com +Signed-off-by: Claudiu Beznea +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm/boot/dts/microchip/sama7d65.dtsi | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/arch/arm/boot/dts/microchip/sama7d65.dtsi b/arch/arm/boot/dts/microchip/sama7d65.dtsi +index 5f3a7b178aa7..868045c650a7 100644 +--- a/arch/arm/boot/dts/microchip/sama7d65.dtsi ++++ b/arch/arm/boot/dts/microchip/sama7d65.dtsi +@@ -527,7 +527,7 @@ i2c3: i2c@600 { + interrupts = ; + clocks = <&pmc PMC_TYPE_PERIPHERAL 37>; + #address-cells = <1>; +- #size-cells = <1>; ++ #size-cells = <0>; + dmas = <&dma0 AT91_XDMAC_DT_PERID(12)>, + <&dma0 AT91_XDMAC_DT_PERID(11)>; + dma-names = "tx", "rx"; +-- +2.52.0 + diff --git a/queue-6.18/arm-dts-microchip-sama7d65-fix-the-ranges-property-for-flx9.patch b/queue-6.18/arm-dts-microchip-sama7d65-fix-the-ranges-property-for-flx9.patch new file mode 100644 index 0000000000..b69c7e66cb --- /dev/null +++ b/queue-6.18/arm-dts-microchip-sama7d65-fix-the-ranges-property-for-flx9.patch @@ -0,0 +1,39 @@ +From aabc977aa472ccf756372ae594d890022c19c9c8 Mon Sep 17 00:00:00 2001 +From: Hari Prasath Gujulan Elango +Date: Fri, 2 Jan 2026 18:01:30 +0100 +Subject: ARM: dts: microchip: sama7d65: fix the ranges property for flx9 + +From: Hari Prasath Gujulan Elango + +commit aabc977aa472ccf756372ae594d890022c19c9c8 upstream. + +Update the ranges property for the flexcom9 as per the datasheet and +align with the reg property. + +Fixes: b51e4aea3ecf ("ARM: dts: microchip: sama7d65: Add FLEXCOMs to sama7d65 SoC") +Cc: stable@vger.kernel.org # 6.16+ +Signed-off-by: Hari Prasath Gujulan Elango +Signed-off-by: Nicolas Ferre +Link: https://lore.kernel.org/r/20260102170135.70717-2-nicolas.ferre@microchip.com +Signed-off-by: Claudiu Beznea +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm/boot/dts/microchip/sama7d65.dtsi | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/arch/arm/boot/dts/microchip/sama7d65.dtsi b/arch/arm/boot/dts/microchip/sama7d65.dtsi +index cd2cf9a6f40b..5f3a7b178aa7 100644 +--- a/arch/arm/boot/dts/microchip/sama7d65.dtsi ++++ b/arch/arm/boot/dts/microchip/sama7d65.dtsi +@@ -676,7 +676,7 @@ i2c8: i2c@600 { + flx9: flexcom@e2820000 { + compatible = "microchip,sama7d65-flexcom", "atmel,sama5d2-flexcom"; + reg = <0xe2820000 0x200>; +- ranges = <0x0 0xe281c000 0x800>; ++ ranges = <0x0 0xe2820000 0x800>; + clocks = <&pmc PMC_TYPE_PERIPHERAL 43>; + #address-cells = <1>; + #size-cells = <1>; +-- +2.52.0 + diff --git a/queue-6.18/arm64-dts-rockchip-configure-mclk-for-analog-sound-on-nanopi-m5.patch b/queue-6.18/arm64-dts-rockchip-configure-mclk-for-analog-sound-on-nanopi-m5.patch new file mode 100644 index 0000000000..329a9e9b35 --- /dev/null +++ b/queue-6.18/arm64-dts-rockchip-configure-mclk-for-analog-sound-on-nanopi-m5.patch @@ -0,0 +1,67 @@ +From 3e4a81881c0929b21a0577bc6e69514c09da5c3f Mon Sep 17 00:00:00 2001 +From: Alexey Charkov +Date: Mon, 29 Dec 2025 14:11:59 +0400 +Subject: arm64: dts: rockchip: Configure MCLK for analog sound on NanoPi M5 + +From: Alexey Charkov + +commit 3e4a81881c0929b21a0577bc6e69514c09da5c3f upstream. + +NanoPi M5 derives its analog sound signal from SAI2 in M0 pin mode, so the +MCLK pin should be configured accordingly for the sound codec to get its +I2S signal from the SoC. Request the required pin config. + +The clock itself should also be CLK_SAI2_MCLKOUT_TO_IO for the sound to +work (otherwise there is only silence out of the audio out jack). + +Fixes: 96cbdfdd3ac2 ("arm64: dts: rockchip: Add FriendlyElec NanoPi M5 support") +Cc: stable@vger.kernel.org +Signed-off-by: Alexey Charkov +Link: https://patch.msgid.link/20251229-rk3576-sound-v1-2-2f59ef0d19b1@gmail.com +Signed-off-by: Heiko Stuebner +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/boot/dts/rockchip/rk3576-nanopi-m5.dts | 10 +++++++--- + 1 file changed, 7 insertions(+), 3 deletions(-) + +diff --git a/arch/arm64/boot/dts/rockchip/rk3576-nanopi-m5.dts b/arch/arm64/boot/dts/rockchip/rk3576-nanopi-m5.dts +index 37184913f918..bb2cc2814b83 100644 +--- a/arch/arm64/boot/dts/rockchip/rk3576-nanopi-m5.dts ++++ b/arch/arm64/boot/dts/rockchip/rk3576-nanopi-m5.dts +@@ -201,6 +201,7 @@ sound { + pinctrl-names = "default"; + pinctrl-0 = <&hp_det_l>; + ++ simple-audio-card,bitclock-master = <&masterdai>; + simple-audio-card,format = "i2s"; + simple-audio-card,hp-det-gpios = <&gpio2 RK_PD6 GPIO_ACTIVE_LOW>; + simple-audio-card,mclk-fs = <256>; +@@ -218,8 +219,9 @@ simple-audio-card,codec { + sound-dai = <&rt5616>; + }; + +- simple-audio-card,cpu { ++ masterdai: simple-audio-card,cpu { + sound-dai = <&sai2>; ++ system-clock-frequency = <12288000>; + }; + }; + }; +@@ -727,10 +729,12 @@ &i2c5 { + rt5616: audio-codec@1b { + compatible = "realtek,rt5616"; + reg = <0x1b>; +- assigned-clocks = <&cru CLK_SAI2_MCLKOUT>; ++ assigned-clocks = <&cru CLK_SAI2_MCLKOUT_TO_IO>; + assigned-clock-rates = <12288000>; +- clocks = <&cru CLK_SAI2_MCLKOUT>; ++ clocks = <&cru CLK_SAI2_MCLKOUT_TO_IO>; + clock-names = "mclk"; ++ pinctrl-0 = <&sai2m0_mclk>; ++ pinctrl-names = "default"; + #sound-dai-cells = <0>; + }; + }; +-- +2.52.0 + diff --git a/queue-6.18/arm64-dts-rockchip-fix-headphones-widget-name-on-nanopi-m5.patch b/queue-6.18/arm64-dts-rockchip-fix-headphones-widget-name-on-nanopi-m5.patch new file mode 100644 index 0000000000..6324f79d2e --- /dev/null +++ b/queue-6.18/arm64-dts-rockchip-fix-headphones-widget-name-on-nanopi-m5.patch @@ -0,0 +1,43 @@ +From 5ab3dd9d0a63af66377f58633fec9dad650e6827 Mon Sep 17 00:00:00 2001 +From: Alexey Charkov +Date: Mon, 29 Dec 2025 14:11:58 +0400 +Subject: arm64: dts: rockchip: Fix headphones widget name on NanoPi M5 + +From: Alexey Charkov + +commit 5ab3dd9d0a63af66377f58633fec9dad650e6827 upstream. + +Fix the mismatch between the simple-audio-card routing table vs. widget +names, which caused the following error at boot preventing the sound +card from getting added: + +[ 6.625634] asoc-simple-card sound: ASoC: DAPM unknown pin Headphones +[ 6.627247] asoc-simple-card sound: ASoC: Failed to add route HPOL -> Headphones(*) +[ 6.627988] asoc-simple-card sound: ASoC: Failed to add route HPOR -> Headphones(*) + +Fixes: 96cbdfdd3ac2 ("arm64: dts: rockchip: Add FriendlyElec NanoPi M5 support") +Cc: stable@vger.kernel.org +Signed-off-by: Alexey Charkov +Link: https://patch.msgid.link/20251229-rk3576-sound-v1-1-2f59ef0d19b1@gmail.com +Signed-off-by: Heiko Stuebner +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/boot/dts/rockchip/rk3576-nanopi-m5.dts | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/arch/arm64/boot/dts/rockchip/rk3576-nanopi-m5.dts b/arch/arm64/boot/dts/rockchip/rk3576-nanopi-m5.dts +index cce34c541f7c..37184913f918 100644 +--- a/arch/arm64/boot/dts/rockchip/rk3576-nanopi-m5.dts ++++ b/arch/arm64/boot/dts/rockchip/rk3576-nanopi-m5.dts +@@ -211,7 +211,7 @@ sound { + "Headphones", "HPOR", + "IN1P", "Microphone Jack"; + simple-audio-card,widgets = +- "Headphone", "Headphone Jack", ++ "Headphone", "Headphones", + "Microphone", "Microphone Jack"; + + simple-audio-card,codec { +-- +2.52.0 + diff --git a/queue-6.18/arm64-dts-rockchip-fix-unit-address-for-rk3588-npu-s-core1-and-core2-s-iommu.patch b/queue-6.18/arm64-dts-rockchip-fix-unit-address-for-rk3588-npu-s-core1-and-core2-s-iommu.patch new file mode 100644 index 0000000000..f455b8a9b5 --- /dev/null +++ b/queue-6.18/arm64-dts-rockchip-fix-unit-address-for-rk3588-npu-s-core1-and-core2-s-iommu.patch @@ -0,0 +1,63 @@ +From cd8967ea3105d30adb878a9fea0e34a9378df610 Mon Sep 17 00:00:00 2001 +From: Quentin Schulz +Date: Mon, 15 Dec 2025 17:45:56 +0100 +Subject: arm64: dts: rockchip: fix unit-address for RK3588 NPU's core1 and core2's IOMMU + +From: Quentin Schulz + +commit cd8967ea3105d30adb878a9fea0e34a9378df610 upstream. + +The Device Tree specification specifies[1] that + +""" +Each node in the devicetree is named according to the following +convention: + node-name@unit-address +[...] +The unit-address must match the first address specified in the reg +property of the node. +""" + +The first address in the reg property is fdaXa000 and not fdaX9000. This +is likely a copy-paste error as the IOMMU for core0 has two entries in +the reg property, the first one being fdab9000 and the second fdaba000. + +Let's fix this oversight to match what the spec is expecting. + +[1] https://github.com/devicetree-org/devicetree-specification/releases/download/v0.4/devicetree-specification-v0.4.pdf 2.2.1 Node Names + +Fixes: a31dfc060a74 ("arm64: dts: rockchip: Add nodes for NPU and its MMU to rk3588-base") +Cc: stable@vger.kernel.org +Signed-off-by: Quentin Schulz +Link: https://patch.msgid.link/20251215-npu-dt-node-address-v1-1-840093e8a2bf@cherry.de +Signed-off-by: Heiko Stuebner +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi +index 2a7921793020..7ab12d1054a7 100644 +--- a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi ++++ b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi +@@ -1200,7 +1200,7 @@ rknn_core_1: npu@fdac0000 { + status = "disabled"; + }; + +- rknn_mmu_1: iommu@fdac9000 { ++ rknn_mmu_1: iommu@fdaca000 { + compatible = "rockchip,rk3588-iommu", "rockchip,rk3568-iommu"; + reg = <0x0 0xfdaca000 0x0 0x100>; + interrupts = ; +@@ -1230,7 +1230,7 @@ rknn_core_2: npu@fdad0000 { + status = "disabled"; + }; + +- rknn_mmu_2: iommu@fdad9000 { ++ rknn_mmu_2: iommu@fdada000 { + compatible = "rockchip,rk3588-iommu", "rockchip,rk3568-iommu"; + reg = <0x0 0xfdada000 0x0 0x100>; + interrupts = ; +-- +2.52.0 + diff --git a/queue-6.18/arm64-dts-rockchip-fix-voltage-threshold-for-volume-keys-for-pinephone-pro.patch b/queue-6.18/arm64-dts-rockchip-fix-voltage-threshold-for-volume-keys-for-pinephone-pro.patch new file mode 100644 index 0000000000..9bbb00bc5f --- /dev/null +++ b/queue-6.18/arm64-dts-rockchip-fix-voltage-threshold-for-volume-keys-for-pinephone-pro.patch @@ -0,0 +1,53 @@ +From 5497ffe305b2ea31ae62d4a311d7cabfb671f54a Mon Sep 17 00:00:00 2001 +From: Ondrej Jirman +Date: Mon, 24 Nov 2025 19:47:03 -0800 +Subject: arm64: dts: rockchip: Fix voltage threshold for volume keys for Pinephone Pro + +From: Ondrej Jirman + +commit 5497ffe305b2ea31ae62d4a311d7cabfb671f54a upstream. + +Previously sometimes pressing the volume-down button would register as +a volume-up button. Match the thresholds as shown in the Pinephone Pro +schematic. + +Tests: + +~ $ evtest + // Mashed the volume down ~100 times with varying intensity + Event: time xxx, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 1 + Event: time xxx, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 0 + // Mashed the volume up ~100 times with varying intensity + Event: time xxx, type 1 (EV_KEY), code 115 (KEY_VOLUMEUP), value 1 + Event: time xxx, type 1 (EV_KEY), code 115 (KEY_VOLUMEUP), value 0 + +Fixes: d3150ed53580 ("arm64: dts: rockchip: Add support for volume keys to rk3399-pinephone-pro") +Cc: stable@vger.kernel.org +Signed-off-by: Ondrej Jirman +Signed-off-by: Rudraksha Gupta +Reviewed-by: Pavel Machek +Link: https://patch.msgid.link/20251124-ppp_light_accel_mag_vol-down-v5-4-f9a10a0a50eb@gmail.com +Signed-off-by: Heiko Stuebner +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts ++++ b/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts +@@ -40,13 +40,13 @@ + button-up { + label = "Volume Up"; + linux,code = ; +- press-threshold-microvolt = <100000>; ++ press-threshold-microvolt = <2000>; + }; + + button-down { + label = "Volume Down"; + linux,code = ; +- press-threshold-microvolt = <600000>; ++ press-threshold-microvolt = <300000>; + }; + }; + diff --git a/queue-6.18/arm64-dts-rockchip-remove-dangerous-max-link-speed-from-helios64.patch b/queue-6.18/arm64-dts-rockchip-remove-dangerous-max-link-speed-from-helios64.patch new file mode 100644 index 0000000000..2e00a81647 --- /dev/null +++ b/queue-6.18/arm64-dts-rockchip-remove-dangerous-max-link-speed-from-helios64.patch @@ -0,0 +1,39 @@ +From 0368e4afcf20f377c81fa77b1c7d0dee4a625a44 Mon Sep 17 00:00:00 2001 +From: Geraldo Nascimento +Date: Mon, 17 Nov 2025 18:47:43 -0300 +Subject: arm64: dts: rockchip: remove dangerous max-link-speed from helios64 + +From: Geraldo Nascimento + +commit 0368e4afcf20f377c81fa77b1c7d0dee4a625a44 upstream. + +Shawn Lin from Rockchip strongly discourages attempts to use their +RK3399 PCIe core at 5.0 GT/s speed, citing concerns about catastrophic +failures that may happen. Even if the odds are low, drop from last user +of this non-default property for the RK3399 platform, helios64 board +dts. + +Fixes: 755fff528b1b ("arm64: dts: rockchip: add variables for pcie completion to helios64") +Link: https://lore.kernel.org/all/e8524bf8-a90c-423f-8a58-9ef05a3db1dd@rock-chips.com/ +Cc: stable@vger.kernel.org +Reported-by: Shawn Lin +Reviewed-by: Dragan Simic +Signed-off-by: Geraldo Nascimento +Acked-by: Shawn Lin +Link: https://patch.msgid.link/43bb639c120f599106fca2deee6c6599b2692c5c.1763415706.git.geraldogabriel@gmail.com +Signed-off-by: Heiko Stuebner +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/boot/dts/rockchip/rk3399-kobol-helios64.dts | 1 - + 1 file changed, 1 deletion(-) + +--- a/arch/arm64/boot/dts/rockchip/rk3399-kobol-helios64.dts ++++ b/arch/arm64/boot/dts/rockchip/rk3399-kobol-helios64.dts +@@ -424,7 +424,6 @@ + + &pcie0 { + ep-gpios = <&gpio2 RK_PD4 GPIO_ACTIVE_HIGH>; +- max-link-speed = <2>; + num-lanes = <2>; + pinctrl-names = "default"; + status = "okay"; diff --git a/queue-6.18/arm64-dts-rockchip-remove-redundant-max-link-speed-from-nanopi-r4s.patch b/queue-6.18/arm64-dts-rockchip-remove-redundant-max-link-speed-from-nanopi-r4s.patch new file mode 100644 index 0000000000..44da939e57 --- /dev/null +++ b/queue-6.18/arm64-dts-rockchip-remove-redundant-max-link-speed-from-nanopi-r4s.patch @@ -0,0 +1,35 @@ +From ce652c98a7bfa0b7c675ef5cd85c44c186db96af Mon Sep 17 00:00:00 2001 +From: Geraldo Nascimento +Date: Mon, 17 Nov 2025 18:47:59 -0300 +Subject: arm64: dts: rockchip: remove redundant max-link-speed from nanopi-r4s + +From: Geraldo Nascimento + +commit ce652c98a7bfa0b7c675ef5cd85c44c186db96af upstream. + +This is already the default in rk3399-base.dtsi, remove redundant +declaration from rk3399-nanopi-r4s.dtsi. + +Fixes: db792e9adbf8 ("rockchip: rk3399: Add support for FriendlyARM NanoPi R4S") +Cc: stable@vger.kernel.org +Reported-by: Dragan Simic +Reviewed-by: Dragan Simic +Signed-off-by: Geraldo Nascimento +Acked-by: Shawn Lin +Link: https://patch.msgid.link/6694456a735844177c897581f785cc00c064c7d1.1763415706.git.geraldogabriel@gmail.com +Signed-off-by: Heiko Stuebner +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dtsi | 1 - + 1 file changed, 1 deletion(-) + +--- a/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dtsi ++++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dtsi +@@ -71,7 +71,6 @@ + }; + + &pcie0 { +- max-link-speed = <1>; + num-lanes = <1>; + vpcie3v3-supply = <&vcc3v3_sys>; + }; diff --git a/queue-6.18/comedi-fix-getting-range-information-for-subdevices-16-to-255.patch b/queue-6.18/comedi-fix-getting-range-information-for-subdevices-16-to-255.patch new file mode 100644 index 0000000000..0741eebc19 --- /dev/null +++ b/queue-6.18/comedi-fix-getting-range-information-for-subdevices-16-to-255.patch @@ -0,0 +1,101 @@ +From 10d28cffb3f6ec7ad67f0a4cd32c2afa92909452 Mon Sep 17 00:00:00 2001 +From: Ian Abbott +Date: Wed, 3 Dec 2025 16:24:38 +0000 +Subject: comedi: Fix getting range information for subdevices 16 to 255 + +From: Ian Abbott + +commit 10d28cffb3f6ec7ad67f0a4cd32c2afa92909452 upstream. + +The `COMEDI_RANGEINFO` ioctl does not work properly for subdevice +indices above 15. Currently, the only in-tree COMEDI drivers that +support more than 16 subdevices are the "8255" driver and the +"comedi_bond" driver. Making the ioctl work for subdevice indices up to +255 is achievable. It needs minor changes to the handling of the +`COMEDI_RANGEINFO` and `COMEDI_CHANINFO` ioctls that should be mostly +harmless to user-space, apart from making them less broken. Details +follow... + +The `COMEDI_RANGEINFO` ioctl command gets the list of supported ranges +(usually with units of volts or milliamps) for a COMEDI subdevice or +channel. (Only some subdevices have per-channel range tables, indicated +by the `SDF_RANGETYPE` flag in the subdevice information.) It uses a +`range_type` value and a user-space pointer, both supplied by +user-space, but the `range_type` value should match what was obtained +using the `COMEDI_CHANINFO` ioctl (if the subdevice has per-channel +range tables) or `COMEDI_SUBDINFO` ioctl (if the subdevice uses a +single range table for all channels). Bits 15 to 0 of the `range_type` +value contain the length of the range table, which is the only part that +user-space should care about (so it can use a suitably sized buffer to +fetch the range table). Bits 23 to 16 store the channel index, which is +assumed to be no more than 255 if the subdevice has per-channel range +tables, and is set to 0 if the subdevice has a single range table. For +`range_type` values produced by the `COMEDI_SUBDINFO` ioctl, bits 31 to +24 contain the subdevice index, which is assumed to be no more than 255. +But for `range_type` values produced by the `COMEDI_CHANINFO` ioctl, +bits 27 to 24 contain the subdevice index, which is assumed to be no +more than 15, and bits 31 to 28 contain the COMEDI device's minor device +number for some unknown reason lost in the mists of time. The +`COMEDI_RANGEINFO` ioctl extract the length from bits 15 to 0 of the +user-supplied `range_type` value, extracts the channel index from bits +23 to 16 (only used if the subdevice has per-channel range tables), +extracts the subdevice index from bits 27 to 24, and ignores bits 31 to +28. So for subdevice indices 16 to 255, the `COMEDI_SUBDINFO` or +`COMEDI_CHANINFO` ioctl will report a `range_type` value that doesn't +work with the `COMEDI_RANGEINFO` ioctl. It will either get the range +table for the subdevice index modulo 16, or will fail with `-EINVAL`. + +To fix this, always use bits 31 to 24 of the `range_type` value to hold +the subdevice index (assumed to be no more than 255). This affects the +`COMEDI_CHANINFO` and `COMEDI_RANGEINFO` ioctls. There should not be +anything in user-space that depends on the old, broken usage, although +it may now see different values in bits 31 to 28 of the `range_type` +values reported by the `COMEDI_CHANINFO` ioctl for subdevices that have +per-channel subdevices. User-space should not be trying to decode bits +31 to 16 of the `range_type` values anyway. + +Fixes: ed9eccbe8970 ("Staging: add comedi core") +Cc: stable@vger.kernel.org #5.17+ +Signed-off-by: Ian Abbott +Link: https://patch.msgid.link/20251203162438.176841-1-abbotti@mev.co.uk +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Greg Kroah-Hartman +--- + drivers/comedi/comedi_fops.c | 2 +- + drivers/comedi/range.c | 2 +- + include/uapi/linux/comedi.h | 2 +- + 3 files changed, 3 insertions(+), 3 deletions(-) + +--- a/drivers/comedi/comedi_fops.c ++++ b/drivers/comedi/comedi_fops.c +@@ -1099,7 +1099,7 @@ static int do_chaninfo_ioctl(struct come + for (i = 0; i < s->n_chan; i++) { + int x; + +- x = (dev->minor << 28) | (it->subdev << 24) | (i << 16) | ++ x = (it->subdev << 24) | (i << 16) | + (s->range_table_list[i]->length); + if (put_user(x, it->rangelist + i)) + return -EFAULT; +--- a/drivers/comedi/range.c ++++ b/drivers/comedi/range.c +@@ -52,7 +52,7 @@ int do_rangeinfo_ioctl(struct comedi_dev + const struct comedi_lrange *lr; + struct comedi_subdevice *s; + +- subd = (it->range_type >> 24) & 0xf; ++ subd = (it->range_type >> 24) & 0xff; + chan = (it->range_type >> 16) & 0xff; + + if (!dev->attached) +--- a/include/uapi/linux/comedi.h ++++ b/include/uapi/linux/comedi.h +@@ -640,7 +640,7 @@ struct comedi_chaninfo { + + /** + * struct comedi_rangeinfo - used to retrieve the range table for a channel +- * @range_type: Encodes subdevice index (bits 27:24), channel index ++ * @range_type: Encodes subdevice index (bits 31:24), channel index + * (bits 23:16) and range table length (bits 15:0). + * @range_ptr: Pointer to array of @struct comedi_krange to be filled + * in with the range table for the channel or subdevice. diff --git a/queue-6.18/drm-drm-xe-fix-xe-userptr-in-the-absence-of-config_device_private.patch b/queue-6.18/drm-drm-xe-fix-xe-userptr-in-the-absence-of-config_device_private.patch new file mode 100644 index 0000000000..1cf120f304 --- /dev/null +++ b/queue-6.18/drm-drm-xe-fix-xe-userptr-in-the-absence-of-config_device_private.patch @@ -0,0 +1,133 @@ +From bdcdf968be314b6fc8835b99fb4519e7619671e6 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Thomas=20Hellstr=C3=B6m?= +Date: Wed, 21 Jan 2026 10:10:47 +0100 +Subject: drm, drm/xe: Fix xe userptr in the absence of CONFIG_DEVICE_PRIVATE +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Thomas Hellström + +commit bdcdf968be314b6fc8835b99fb4519e7619671e6 upstream. + +CONFIG_DEVICE_PRIVATE is not selected by default by some distros, +for example Fedora, and that leads to a regression in the xe driver +since userptr support gets compiled out. + +It turns out that DRM_GPUSVM, which is needed for xe userptr support +compiles also without CONFIG_DEVICE_PRIVATE, but doesn't compile +without CONFIG_ZONE_DEVICE. +Exclude the drm_pagemap files from compilation with !CONFIG_ZONE_DEVICE, +and remove the CONFIG_DEVICE_PRIVATE dependency from CONFIG_DRM_GPUSVM and +the xe driver's selection of it, re-enabling xe userptr for those configs. + +v2: +- Don't compile the drm_pagemap files unless CONFIG_ZONE_DEVICE is set. +- Adjust the drm_pagemap.h header accordingly. + +Fixes: 9e9787414882 ("drm/xe/userptr: replace xe_hmm with gpusvm") +Cc: Matthew Auld +Cc: Himal Prasad Ghimiray +Cc: Thomas Hellström +Cc: Matthew Brost +Cc: "Thomas Hellström" +Cc: Rodrigo Vivi +Cc: dri-devel@lists.freedesktop.org +Cc: # v6.18+ +Signed-off-by: Thomas Hellström +Reviewed-by: Matthew Auld +Acked-by: Maarten Lankhorst +Link: https://patch.msgid.link/20260121091048.41371-2-thomas.hellstrom@linux.intel.com +(cherry picked from commit 1e372b246199ca7a35f930177fea91b557dac16e) +Signed-off-by: Thomas Hellström +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/Kconfig | 2 +- + drivers/gpu/drm/Makefile | 4 +++- + drivers/gpu/drm/xe/Kconfig | 2 +- + include/drm/drm_pagemap.h | 19 +++++++++++++++++-- + 4 files changed, 22 insertions(+), 5 deletions(-) + +--- a/drivers/gpu/drm/Kconfig ++++ b/drivers/gpu/drm/Kconfig +@@ -210,7 +210,7 @@ config DRM_GPUVM + + config DRM_GPUSVM + tristate +- depends on DRM && DEVICE_PRIVATE ++ depends on DRM + select HMM_MIRROR + select MMU_NOTIFIER + help +--- a/drivers/gpu/drm/Makefile ++++ b/drivers/gpu/drm/Makefile +@@ -106,8 +106,10 @@ obj-$(CONFIG_DRM_EXEC) += drm_exec.o + obj-$(CONFIG_DRM_GPUVM) += drm_gpuvm.o + + drm_gpusvm_helper-y := \ +- drm_gpusvm.o\ ++ drm_gpusvm.o ++drm_gpusvm_helper-$(CONFIG_ZONE_DEVICE) += \ + drm_pagemap.o ++ + obj-$(CONFIG_DRM_GPUSVM) += drm_gpusvm_helper.o + + obj-$(CONFIG_DRM_BUDDY) += drm_buddy.o +--- a/drivers/gpu/drm/xe/Kconfig ++++ b/drivers/gpu/drm/xe/Kconfig +@@ -39,7 +39,7 @@ config DRM_XE + select DRM_TTM + select DRM_TTM_HELPER + select DRM_EXEC +- select DRM_GPUSVM if !UML && DEVICE_PRIVATE ++ select DRM_GPUSVM if !UML + select DRM_GPUVM + select DRM_SCHED + select MMU_NOTIFIER +--- a/include/drm/drm_pagemap.h ++++ b/include/drm/drm_pagemap.h +@@ -209,6 +209,19 @@ struct drm_pagemap_devmem_ops { + struct dma_fence *pre_migrate_fence); + }; + ++#if IS_ENABLED(CONFIG_ZONE_DEVICE) ++ ++struct drm_pagemap *drm_pagemap_page_to_dpagemap(struct page *page); ++ ++#else ++ ++static inline struct drm_pagemap *drm_pagemap_page_to_dpagemap(struct page *page) ++{ ++ return NULL; ++} ++ ++#endif /* IS_ENABLED(CONFIG_ZONE_DEVICE) */ ++ + /** + * struct drm_pagemap_devmem - Structure representing a GPU SVM device memory allocation + * +@@ -233,6 +246,8 @@ struct drm_pagemap_devmem { + struct dma_fence *pre_migrate_fence; + }; + ++#if IS_ENABLED(CONFIG_ZONE_DEVICE) ++ + int drm_pagemap_migrate_to_devmem(struct drm_pagemap_devmem *devmem_allocation, + struct mm_struct *mm, + unsigned long start, unsigned long end, +@@ -243,8 +258,6 @@ int drm_pagemap_evict_to_ram(struct drm_ + + const struct dev_pagemap_ops *drm_pagemap_pagemap_ops_get(void); + +-struct drm_pagemap *drm_pagemap_page_to_dpagemap(struct page *page); +- + void drm_pagemap_devmem_init(struct drm_pagemap_devmem *devmem_allocation, + struct device *dev, struct mm_struct *mm, + const struct drm_pagemap_devmem_ops *ops, +@@ -256,4 +269,6 @@ int drm_pagemap_populate_mm(struct drm_p + struct mm_struct *mm, + unsigned long timeslice_ms); + ++#endif /* IS_ENABLED(CONFIG_ZONE_DEVICE) */ ++ + #endif diff --git a/queue-6.18/fs-writeback-skip-as_no_data_integrity-mappings-in-wait_sb_inodes.patch b/queue-6.18/fs-writeback-skip-as_no_data_integrity-mappings-in-wait_sb_inodes.patch new file mode 100644 index 0000000000..0ab27fb1dc --- /dev/null +++ b/queue-6.18/fs-writeback-skip-as_no_data_integrity-mappings-in-wait_sb_inodes.patch @@ -0,0 +1,110 @@ +From f9a49aa302a05e91ca01f69031cb79a0ea33031f Mon Sep 17 00:00:00 2001 +From: Joanne Koong +Date: Mon, 5 Jan 2026 13:17:27 -0800 +Subject: fs/writeback: skip AS_NO_DATA_INTEGRITY mappings in wait_sb_inodes() +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Joanne Koong + +commit f9a49aa302a05e91ca01f69031cb79a0ea33031f upstream. + +Above the while() loop in wait_sb_inodes(), we document that we must wait +for all pages under writeback for data integrity. Consequently, if a +mapping, like fuse, traditionally does not have data integrity semantics, +there is no need to wait at all; we can simply skip these inodes. + +This restores fuse back to prior behavior where syncs are no-ops. This +fixes a user regression where if a system is running a faulty fuse server +that does not reply to issued write requests, this causes wait_sb_inodes() +to wait forever. + +Link: https://lkml.kernel.org/r/20260105211737.4105620-2-joannelkoong@gmail.com +Fixes: 0c58a97f919c ("fuse: remove tmp folio for writebacks and internal rb tree") +Signed-off-by: Joanne Koong +Reported-by: Athul Krishna +Reported-by: J. Neuschäfer +Reviewed-by: Bernd Schubert +Tested-by: J. Neuschäfer +Cc: Alexander Viro +Cc: Bernd Schubert +Cc: Bonaccorso Salvatore +Cc: Christian Brauner +Cc: David Hildenbrand +Cc: Jan Kara +Cc: "Liam R. Howlett" +Cc: Lorenzo Stoakes +Cc: "Matthew Wilcox (Oracle)" +Cc: Michal Hocko +Cc: Mike Rapoport +Cc: Miklos Szeredi +Cc: Suren Baghdasaryan +Cc: Vlastimil Babka +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + fs/fs-writeback.c | 7 ++++++- + fs/fuse/file.c | 4 +++- + include/linux/pagemap.h | 11 +++++++++++ + 3 files changed, 20 insertions(+), 2 deletions(-) + +--- a/fs/fs-writeback.c ++++ b/fs/fs-writeback.c +@@ -2729,8 +2729,13 @@ static void wait_sb_inodes(struct super_ + * The mapping can appear untagged while still on-list since we + * do not have the mapping lock. Skip it here, wb completion + * will remove it. ++ * ++ * If the mapping does not have data integrity semantics, ++ * there's no need to wait for the writeout to complete, as the ++ * mapping cannot guarantee that data is persistently stored. + */ +- if (!mapping_tagged(mapping, PAGECACHE_TAG_WRITEBACK)) ++ if (!mapping_tagged(mapping, PAGECACHE_TAG_WRITEBACK) || ++ mapping_no_data_integrity(mapping)) + continue; + + spin_unlock_irq(&sb->s_inode_wblist_lock); +--- a/fs/fuse/file.c ++++ b/fs/fuse/file.c +@@ -3146,8 +3146,10 @@ void fuse_init_file_inode(struct inode * + + inode->i_fop = &fuse_file_operations; + inode->i_data.a_ops = &fuse_file_aops; +- if (fc->writeback_cache) ++ if (fc->writeback_cache) { + mapping_set_writeback_may_deadlock_on_reclaim(&inode->i_data); ++ mapping_set_no_data_integrity(&inode->i_data); ++ } + + INIT_LIST_HEAD(&fi->write_files); + INIT_LIST_HEAD(&fi->queued_writes); +--- a/include/linux/pagemap.h ++++ b/include/linux/pagemap.h +@@ -213,6 +213,7 @@ enum mapping_flags { + AS_WRITEBACK_MAY_DEADLOCK_ON_RECLAIM = 9, + AS_KERNEL_FILE = 10, /* mapping for a fake kernel file that shouldn't + account usage to user cgroups */ ++ AS_NO_DATA_INTEGRITY = 11, /* no data integrity guarantees */ + /* Bits 16-25 are used for FOLIO_ORDER */ + AS_FOLIO_ORDER_BITS = 5, + AS_FOLIO_ORDER_MIN = 16, +@@ -348,6 +349,16 @@ static inline bool mapping_writeback_may + return test_bit(AS_WRITEBACK_MAY_DEADLOCK_ON_RECLAIM, &mapping->flags); + } + ++static inline void mapping_set_no_data_integrity(struct address_space *mapping) ++{ ++ set_bit(AS_NO_DATA_INTEGRITY, &mapping->flags); ++} ++ ++static inline bool mapping_no_data_integrity(const struct address_space *mapping) ++{ ++ return test_bit(AS_NO_DATA_INTEGRITY, &mapping->flags); ++} ++ + static inline gfp_t mapping_gfp_mask(const struct address_space *mapping) + { + return mapping->gfp_mask; diff --git a/queue-6.18/i2c-spacemit-drop-irqf_oneshot-flag-from-irq-request.patch b/queue-6.18/i2c-spacemit-drop-irqf_oneshot-flag-from-irq-request.patch new file mode 100644 index 0000000000..f168ea9043 --- /dev/null +++ b/queue-6.18/i2c-spacemit-drop-irqf_oneshot-flag-from-irq-request.patch @@ -0,0 +1,38 @@ +From e351836a54e3b0b4483f896abcd6a0dc71097693 Mon Sep 17 00:00:00 2001 +From: Yixun Lan +Date: Thu, 22 Jan 2026 07:52:00 +0800 +Subject: i2c: spacemit: drop IRQF_ONESHOT flag from IRQ request + +From: Yixun Lan + +commit e351836a54e3b0b4483f896abcd6a0dc71097693 upstream. + +In commit aef30c8d569c ("genirq: Warn about using IRQF_ONESHOT without a +threaded handler")[1], it will check IRQF_ONESHOT flag in IRQ request, +and gives a warning if there is no threaded handler. Drop this flag to +fix this warning. + +Link: https://lore.kernel.org/r/20260112134013.eQWyReHR@linutronix.de/ [1] +Fixes: 5ea558473fa3 ("i2c: spacemit: add support for SpacemiT K1 SoC") +Signed-off-by: Yixun Lan +Cc: # v6.15+ +Reviewed-by: Javier Martinez Canillas +Reviewed-by: Troy Mitchell +Signed-off-by: Andi Shyti +Link: https://lore.kernel.org/r/20260122-05-k1-i2c-irq-v1-1-9b8d94bbcd22@kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/i2c/busses/i2c-k1.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/i2c/busses/i2c-k1.c ++++ b/drivers/i2c/busses/i2c-k1.c +@@ -566,7 +566,7 @@ static int spacemit_i2c_probe(struct pla + return dev_err_probe(dev, i2c->irq, "failed to get irq resource"); + + ret = devm_request_irq(i2c->dev, i2c->irq, spacemit_i2c_irq_handler, +- IRQF_NO_SUSPEND | IRQF_ONESHOT, dev_name(i2c->dev), i2c); ++ IRQF_NO_SUSPEND, dev_name(i2c->dev), i2c); + if (ret) + return dev_err_probe(dev, ret, "failed to request irq"); + diff --git a/queue-6.18/iio-imu-st_lsm6dsx-fix-iio_chan_spec-for-sensors-without-event-detection.patch b/queue-6.18/iio-imu-st_lsm6dsx-fix-iio_chan_spec-for-sensors-without-event-detection.patch new file mode 100644 index 0000000000..f21ea18261 --- /dev/null +++ b/queue-6.18/iio-imu-st_lsm6dsx-fix-iio_chan_spec-for-sensors-without-event-detection.patch @@ -0,0 +1,68 @@ +From c34e2e2d67b3bb8d5a6d09b0d6dac845cdd13fb3 Mon Sep 17 00:00:00 2001 +From: Francesco Lavra +Date: Mon, 1 Dec 2025 11:00:10 +0100 +Subject: iio: imu: st_lsm6dsx: fix iio_chan_spec for sensors without event detection + +From: Francesco Lavra + +commit c34e2e2d67b3bb8d5a6d09b0d6dac845cdd13fb3 upstream. + +The st_lsm6dsx_acc_channels array of struct iio_chan_spec has a non-NULL +event_spec field, indicating support for IIO events. However, event +detection is not supported for all sensors, and if userspace tries to +configure accelerometer wakeup events on a sensor device that does not +support them (e.g. LSM6DS0), st_lsm6dsx_write_event() dereferences a NULL +pointer when trying to write to the wakeup register. +Define an additional struct iio_chan_spec array whose members have a NULL +event_spec field, and use this array instead of st_lsm6dsx_acc_channels for +sensors without event detection capability. + +Fixes: b5969abfa8b8 ("iio: imu: st_lsm6dsx: add motion events") +Signed-off-by: Francesco Lavra +Reviewed-by: Andy Shevchenko +Acked-by: Lorenzo Bianconi +Cc: stable@vger.kernel.org +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c | 15 +++++++++++---- + 1 file changed, 11 insertions(+), 4 deletions(-) + +--- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c ++++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx_core.c +@@ -101,6 +101,13 @@ static const struct iio_chan_spec st_lsm + IIO_CHAN_SOFT_TIMESTAMP(3), + }; + ++static const struct iio_chan_spec st_lsm6ds0_acc_channels[] = { ++ ST_LSM6DSX_CHANNEL(IIO_ACCEL, 0x28, IIO_MOD_X, 0), ++ ST_LSM6DSX_CHANNEL(IIO_ACCEL, 0x2a, IIO_MOD_Y, 1), ++ ST_LSM6DSX_CHANNEL(IIO_ACCEL, 0x2c, IIO_MOD_Z, 2), ++ IIO_CHAN_SOFT_TIMESTAMP(3), ++}; ++ + static const struct iio_chan_spec st_lsm6dsx_gyro_channels[] = { + ST_LSM6DSX_CHANNEL(IIO_ANGL_VEL, 0x22, IIO_MOD_X, 0), + ST_LSM6DSX_CHANNEL(IIO_ANGL_VEL, 0x24, IIO_MOD_Y, 1), +@@ -142,8 +149,8 @@ static const struct st_lsm6dsx_settings + }, + .channels = { + [ST_LSM6DSX_ID_ACC] = { +- .chan = st_lsm6dsx_acc_channels, +- .len = ARRAY_SIZE(st_lsm6dsx_acc_channels), ++ .chan = st_lsm6ds0_acc_channels, ++ .len = ARRAY_SIZE(st_lsm6ds0_acc_channels), + }, + [ST_LSM6DSX_ID_GYRO] = { + .chan = st_lsm6ds0_gyro_channels, +@@ -1449,8 +1456,8 @@ static const struct st_lsm6dsx_settings + }, + .channels = { + [ST_LSM6DSX_ID_ACC] = { +- .chan = st_lsm6dsx_acc_channels, +- .len = ARRAY_SIZE(st_lsm6dsx_acc_channels), ++ .chan = st_lsm6ds0_acc_channels, ++ .len = ARRAY_SIZE(st_lsm6ds0_acc_channels), + }, + [ST_LSM6DSX_ID_GYRO] = { + .chan = st_lsm6dsx_gyro_channels, diff --git a/queue-6.18/input-i8042-add-quirk-for-asus-zenbook-ux425qa_um425qa.patch b/queue-6.18/input-i8042-add-quirk-for-asus-zenbook-ux425qa_um425qa.patch new file mode 100644 index 0000000000..e189baf5e4 --- /dev/null +++ b/queue-6.18/input-i8042-add-quirk-for-asus-zenbook-ux425qa_um425qa.patch @@ -0,0 +1,48 @@ +From 2934325f56150ad8dab8ab92cbe2997242831396 Mon Sep 17 00:00:00 2001 +From: feng +Date: Sat, 24 Jan 2026 21:44:12 -0800 +Subject: Input: i8042 - add quirk for ASUS Zenbook UX425QA_UM425QA + +From: feng + +commit 2934325f56150ad8dab8ab92cbe2997242831396 upstream. + +The ASUS Zenbook UX425QA_UM425QA fails to initialize the keyboard after +a cold boot. + +A quirk already exists for "ZenBook UX425", but some Zenbooks report +"Zenbook" with a lowercase 'b'. Since DMI matching is case-sensitive, +the existing quirk is not applied to these "extra special" Zenbooks. + +Testing confirms that this model needs the same quirks as the ZenBook +UX425 variants. + +Signed-off-by: feng +Link: https://patch.msgid.link/20260122013957.11184-1-alec.jiang@gmail.com +Cc: stable@vger.kernel.org +Signed-off-by: Dmitry Torokhov +Signed-off-by: Greg Kroah-Hartman +--- + drivers/input/serio/i8042-acpipnpio.h | 11 +++++++++++ + 1 file changed, 11 insertions(+) + +--- a/drivers/input/serio/i8042-acpipnpio.h ++++ b/drivers/input/serio/i8042-acpipnpio.h +@@ -116,6 +116,17 @@ static const struct dmi_system_id i8042_ + .driver_data = (void *)(SERIO_QUIRK_NOMUX | SERIO_QUIRK_RESET_NEVER) + }, + { ++ /* ++ * ASUS Zenbook UX425QA_UM425QA ++ * Some Zenbooks report "Zenbook" with a lowercase b. ++ */ ++ .matches = { ++ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."), ++ DMI_MATCH(DMI_PRODUCT_NAME, "Zenbook UX425QA_UM425QA"), ++ }, ++ .driver_data = (void *)(SERIO_QUIRK_PROBE_DEFER | SERIO_QUIRK_RESET_NEVER) ++ }, ++ { + /* ASUS ZenBook UX425UA/QA */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."), diff --git a/queue-6.18/input-i8042-add-quirks-for-mechrevo-wujie-15x-pro.patch b/queue-6.18/input-i8042-add-quirks-for-mechrevo-wujie-15x-pro.patch new file mode 100644 index 0000000000..6895b9e624 --- /dev/null +++ b/queue-6.18/input-i8042-add-quirks-for-mechrevo-wujie-15x-pro.patch @@ -0,0 +1,38 @@ +From 19a5d9ba6208e9006a2a9d5962aea4d6e427d8ab Mon Sep 17 00:00:00 2001 +From: gongqi <550230171hxy@gmail.com> +Date: Thu, 22 Jan 2026 23:54:59 +0800 +Subject: Input: i8042 - add quirks for MECHREVO Wujie 15X Pro + +From: gongqi <550230171hxy@gmail.com> + +commit 19a5d9ba6208e9006a2a9d5962aea4d6e427d8ab upstream. + +The MECHREVO Wujie 15X Pro requires several i8042 quirks to function +correctly. Specifically, NOMUX, RESET_ALWAYS, NOLOOP, and NOPNP are +needed to ensure the keyboard and touchpad work reliably. + +Signed-off-by: gongqi <550230171hxy@gmail.com> +Link: https://patch.msgid.link/20260122155501.376199-3-550230171hxy@gmail.com +Cc: stable@vger.kernel.org +Signed-off-by: Dmitry Torokhov +Signed-off-by: Greg Kroah-Hartman +--- + drivers/input/serio/i8042-acpipnpio.h | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/drivers/input/serio/i8042-acpipnpio.h ++++ b/drivers/input/serio/i8042-acpipnpio.h +@@ -1176,6 +1176,13 @@ static const struct dmi_system_id i8042_ + .driver_data = (void *)(SERIO_QUIRK_NOMUX | SERIO_QUIRK_RESET_ALWAYS | + SERIO_QUIRK_NOLOOP | SERIO_QUIRK_NOPNP) + }, ++ { ++ .matches = { ++ DMI_MATCH(DMI_BOARD_NAME, "WUJIE Series-X5SP4NAG"), ++ }, ++ .driver_data = (void *)(SERIO_QUIRK_NOMUX | SERIO_QUIRK_RESET_ALWAYS | ++ SERIO_QUIRK_NOLOOP | SERIO_QUIRK_NOPNP) ++ }, + /* + * A lot of modern Clevo barebones have touchpad and/or keyboard issues + * after suspend fixable with the forcenorestore quirk. diff --git a/queue-6.18/io_uring-io-wq-check-io_wq_bit_exit-inside-work-run-loop.patch b/queue-6.18/io_uring-io-wq-check-io_wq_bit_exit-inside-work-run-loop.patch new file mode 100644 index 0000000000..0d899673c3 --- /dev/null +++ b/queue-6.18/io_uring-io-wq-check-io_wq_bit_exit-inside-work-run-loop.patch @@ -0,0 +1,89 @@ +From 10dc959398175736e495f71c771f8641e1ca1907 Mon Sep 17 00:00:00 2001 +From: Jens Axboe +Date: Tue, 20 Jan 2026 07:42:50 -0700 +Subject: io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop + +From: Jens Axboe + +commit 10dc959398175736e495f71c771f8641e1ca1907 upstream. + +Currently this is checked before running the pending work. Normally this +is quite fine, as work items either end up blocking (which will create a +new worker for other items), or they complete fairly quickly. But syzbot +reports an issue where io-wq takes seemingly forever to exit, and with a +bit of debugging, this turns out to be because it queues a bunch of big +(2GB - 4096b) reads with a /dev/msr* file. Since this file type doesn't +support ->read_iter(), loop_rw_iter() ends up handling them. Each read +returns 16MB of data read, which takes 20 (!!) seconds. With a bunch of +these pending, processing the whole chain can take a long time. Easily +longer than the syzbot uninterruptible sleep timeout of 140 seconds. +This then triggers a complaint off the io-wq exit path: + +INFO: task syz.4.135:6326 blocked for more than 143 seconds. + Not tainted syzkaller #0 + Blocked by coredump. +"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. +task:syz.4.135 state:D stack:26824 pid:6326 tgid:6324 ppid:5957 task_flags:0x400548 flags:0x00080000 +Call Trace: + + context_switch kernel/sched/core.c:5256 [inline] + __schedule+0x1139/0x6150 kernel/sched/core.c:6863 + __schedule_loop kernel/sched/core.c:6945 [inline] + schedule+0xe7/0x3a0 kernel/sched/core.c:6960 + schedule_timeout+0x257/0x290 kernel/time/sleep_timeout.c:75 + do_wait_for_common kernel/sched/completion.c:100 [inline] + __wait_for_common+0x2fc/0x4e0 kernel/sched/completion.c:121 + io_wq_exit_workers io_uring/io-wq.c:1328 [inline] + io_wq_put_and_exit+0x271/0x8a0 io_uring/io-wq.c:1356 + io_uring_clean_tctx+0x10d/0x190 io_uring/tctx.c:203 + io_uring_cancel_generic+0x69c/0x9a0 io_uring/cancel.c:651 + io_uring_files_cancel include/linux/io_uring.h:19 [inline] + do_exit+0x2ce/0x2bd0 kernel/exit.c:911 + do_group_exit+0xd3/0x2a0 kernel/exit.c:1112 + get_signal+0x2671/0x26d0 kernel/signal.c:3034 + arch_do_signal_or_restart+0x8f/0x7e0 arch/x86/kernel/signal.c:337 + __exit_to_user_mode_loop kernel/entry/common.c:41 [inline] + exit_to_user_mode_loop+0x8c/0x540 kernel/entry/common.c:75 + __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline] + syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline] + syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline] + syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline] + do_syscall_64+0x4ee/0xf80 arch/x86/entry/syscall_64.c:100 + entry_SYSCALL_64_after_hwframe+0x77/0x7f +RIP: 0033:0x7fa02738f749 +RSP: 002b:00007fa0281ae0e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca +RAX: fffffffffffffe00 RBX: 00007fa0275e6098 RCX: 00007fa02738f749 +RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007fa0275e6098 +RBP: 00007fa0275e6090 R08: 0000000000000000 R09: 0000000000000000 +R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 +R13: 00007fa0275e6128 R14: 00007fff14e4fcb0 R15: 00007fff14e4fd98 + +There's really nothing wrong here, outside of processing these reads +will take a LONG time. However, we can speed up the exit by checking the +IO_WQ_BIT_EXIT inside the io_worker_handle_work() loop, as syzbot will +exit the ring after queueing up all of these reads. Then once the first +item is processed, io-wq will simply cancel the rest. That should avoid +syzbot running into this complaint again. + +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/all/68a2decc.050a0220.e29e5.0099.GAE@google.com/ +Reported-by: syzbot+4eb282331cab6d5b6588@syzkaller.appspotmail.com +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + io_uring/io-wq.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/io_uring/io-wq.c ++++ b/io_uring/io-wq.c +@@ -598,9 +598,9 @@ static void io_worker_handle_work(struct + __releases(&acct->lock) + { + struct io_wq *wq = worker->wq; +- bool do_kill = test_bit(IO_WQ_BIT_EXIT, &wq->state); + + do { ++ bool do_kill = test_bit(IO_WQ_BIT_EXIT, &wq->state); + struct io_wq_work *work; + + /* diff --git a/queue-6.18/mm-hugetlb-fix-hugetlb_pmd_shared.patch b/queue-6.18/mm-hugetlb-fix-hugetlb_pmd_shared.patch new file mode 100644 index 0000000000..6a1226244d --- /dev/null +++ b/queue-6.18/mm-hugetlb-fix-hugetlb_pmd_shared.patch @@ -0,0 +1,89 @@ +From ca1a47cd3f5f4c46ca188b1c9a27af87d1ab2216 Mon Sep 17 00:00:00 2001 +From: "David Hildenbrand (Red Hat)" +Date: Tue, 23 Dec 2025 22:40:34 +0100 +Subject: mm/hugetlb: fix hugetlb_pmd_shared() + +From: David Hildenbrand (Red Hat) + +commit ca1a47cd3f5f4c46ca188b1c9a27af87d1ab2216 upstream. + +Patch series "mm/hugetlb: fixes for PMD table sharing (incl. using +mmu_gather)", v3. + +One functional fix, one performance regression fix, and two related +comment fixes. + +I cleaned up my prototype I recently shared [1] for the performance fix, +deferring most of the cleanups I had in the prototype to a later point. +While doing that I identified the other things. + +The goal of this patch set is to be backported to stable trees "fairly" +easily. At least patch #1 and #4. + +Patch #1 fixes hugetlb_pmd_shared() not detecting any sharing +Patch #2 + #3 are simple comment fixes that patch #4 interacts with. +Patch #4 is a fix for the reported performance regression due to excessive +IPI broadcasts during fork()+exit(). + +The last patch is all about TLB flushes, IPIs and mmu_gather. +Read: complicated + +There are plenty of cleanups in the future to be had + one reasonable +optimization on x86. But that's all out of scope for this series. + +Runtime tested, with a focus on fixing the performance regression using +the original reproducer [2] on x86. + + +This patch (of 4): + +We switched from (wrongly) using the page count to an independent shared +count. Now, shared page tables have a refcount of 1 (excluding +speculative references) and instead use ptdesc->pt_share_count to identify +sharing. + +We didn't convert hugetlb_pmd_shared(), so right now, we would never +detect a shared PMD table as such, because sharing/unsharing no longer +touches the refcount of a PMD table. + +Page migration, like mbind() or migrate_pages() would allow for migrating +folios mapped into such shared PMD tables, even though the folios are not +exclusive. In smaps we would account them as "private" although they are +"shared", and we would be wrongly setting the PM_MMAP_EXCLUSIVE in the +pagemap interface. + +Fix it by properly using ptdesc_pmd_is_shared() in hugetlb_pmd_shared(). + +Link: https://lkml.kernel.org/r/20251223214037.580860-1-david@kernel.org +Link: https://lkml.kernel.org/r/20251223214037.580860-2-david@kernel.org +Link: https://lore.kernel.org/all/8cab934d-4a56-44aa-b641-bfd7e23bd673@kernel.org/ [1] +Link: https://lore.kernel.org/all/8cab934d-4a56-44aa-b641-bfd7e23bd673@kernel.org/ [2] +Fixes: 59d9094df3d7 ("mm: hugetlb: independent PMD page table shared count") +Signed-off-by: David Hildenbrand (Red Hat) +Reviewed-by: Rik van Riel +Reviewed-by: Lance Yang +Tested-by: Lance Yang +Reviewed-by: Harry Yoo +Tested-by: Laurence Oberman +Reviewed-by: Lorenzo Stoakes +Acked-by: Oscar Salvador +Cc: Liu Shixin +Cc: Uschakow, Stanislav" +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + include/linux/hugetlb.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/include/linux/hugetlb.h ++++ b/include/linux/hugetlb.h +@@ -1323,7 +1323,7 @@ static inline __init void hugetlb_cma_re + #ifdef CONFIG_HUGETLB_PMD_PAGE_TABLE_SHARING + static inline bool hugetlb_pmd_shared(pte_t *pte) + { +- return page_count(virt_to_page(pte)) > 1; ++ return ptdesc_pmd_is_shared(virt_to_ptdesc(pte)); + } + #else + static inline bool hugetlb_pmd_shared(pte_t *pte) diff --git a/queue-6.18/mm-restore-per-memcg-proactive-reclaim-with-config_numa.patch b/queue-6.18/mm-restore-per-memcg-proactive-reclaim-with-config_numa.patch new file mode 100644 index 0000000000..00629ff0dc --- /dev/null +++ b/queue-6.18/mm-restore-per-memcg-proactive-reclaim-with-config_numa.patch @@ -0,0 +1,97 @@ +From 16aca2c98a6fdf071e5a1a765a295995d7c7e346 Mon Sep 17 00:00:00 2001 +From: Yosry Ahmed +Date: Fri, 16 Jan 2026 20:52:47 +0000 +Subject: mm: restore per-memcg proactive reclaim with !CONFIG_NUMA + +From: Yosry Ahmed + +commit 16aca2c98a6fdf071e5a1a765a295995d7c7e346 upstream. + +Commit 2b7226af730c ("mm/memcg: make memory.reclaim interface generic") +moved proactive reclaim logic from memory.reclaim handler to a generic +user_proactive_reclaim() helper to be used for per-node proactive reclaim. + +However, user_proactive_reclaim() was only defined under CONFIG_NUMA, with +a stub always returning 0 otherwise. This broke memory.reclaim on +!CONFIG_NUMA configs, causing it to report success without actually +attempting reclaim. + +Move the definition of user_proactive_reclaim() outside CONFIG_NUMA, and +instead define a stub for __node_reclaim() in the !CONFIG_NUMA case. +__node_reclaim() is only called from user_proactive_reclaim() when a write +is made to sys/devices/system/node/nodeX/reclaim, which is only defined +with CONFIG_NUMA. + +Link: https://lkml.kernel.org/r/20260116205247.928004-1-yosry.ahmed@linux.dev +Fixes: 2b7226af730c ("mm/memcg: make memory.reclaim interface generic") +Signed-off-by: Yosry Ahmed +Acked-by: Shakeel Butt +Acked-by: Michal Hocko +Cc: Axel Rasmussen +Cc: David Hildenbrand +Cc: Davidlohr Bueso +Cc: Johannes Weiner +Cc: Liam Howlett +Cc: Lorenzo Stoakes +Cc: Mike Rapoport +Cc: Qi Zheng +Cc: Suren Baghdasaryan +Cc: Vlastimil Babka +Cc: Wei Xu +Cc: Yuanchu Xie +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + mm/internal.h | 8 -------- + mm/vmscan.c | 13 +++++++++++-- + 2 files changed, 11 insertions(+), 10 deletions(-) + +--- a/mm/internal.h ++++ b/mm/internal.h +@@ -538,16 +538,8 @@ extern unsigned long highest_memmap_pfn; + bool folio_isolate_lru(struct folio *folio); + void folio_putback_lru(struct folio *folio); + extern void reclaim_throttle(pg_data_t *pgdat, enum vmscan_throttle_state reason); +-#ifdef CONFIG_NUMA + int user_proactive_reclaim(char *buf, + struct mem_cgroup *memcg, pg_data_t *pgdat); +-#else +-static inline int user_proactive_reclaim(char *buf, +- struct mem_cgroup *memcg, pg_data_t *pgdat) +-{ +- return 0; +-} +-#endif + + /* + * in mm/rmap.c: +--- a/mm/vmscan.c ++++ b/mm/vmscan.c +@@ -7740,6 +7740,17 @@ int node_reclaim(struct pglist_data *pgd + return ret; + } + ++#else ++ ++static unsigned long __node_reclaim(struct pglist_data *pgdat, gfp_t gfp_mask, ++ unsigned long nr_pages, ++ struct scan_control *sc) ++{ ++ return 0; ++} ++ ++#endif ++ + enum { + MEMORY_RECLAIM_SWAPPINESS = 0, + MEMORY_RECLAIM_SWAPPINESS_MAX, +@@ -7847,8 +7858,6 @@ int user_proactive_reclaim(char *buf, + return 0; + } + +-#endif +- + /** + * check_move_unevictable_folios - Move evictable folios to appropriate zone + * lru list diff --git a/queue-6.18/mm-rmap-fix-two-comments-related-to-huge_pmd_unshare.patch b/queue-6.18/mm-rmap-fix-two-comments-related-to-huge_pmd_unshare.patch new file mode 100644 index 0000000000..2eba84bfb8 --- /dev/null +++ b/queue-6.18/mm-rmap-fix-two-comments-related-to-huge_pmd_unshare.patch @@ -0,0 +1,72 @@ +From a8682d500f691b6dfaa16ae1502d990aeb86e8be Mon Sep 17 00:00:00 2001 +From: "David Hildenbrand (Red Hat)" +Date: Tue, 23 Dec 2025 22:40:36 +0100 +Subject: mm/rmap: fix two comments related to huge_pmd_unshare() + +From: David Hildenbrand (Red Hat) + +commit a8682d500f691b6dfaa16ae1502d990aeb86e8be upstream. + +PMD page table unsharing no longer touches the refcount of a PMD page +table. Also, it is not about dropping the refcount of a "PMD page" but +the "PMD page table". + +Let's just simplify by saying that the PMD page table was unmapped, +consequently also unmapping the folio that was mapped into this page. + +This code should be deduplicated in the future. + +Link: https://lkml.kernel.org/r/20251223214037.580860-4-david@kernel.org +Fixes: 59d9094df3d7 ("mm: hugetlb: independent PMD page table shared count") +Signed-off-by: David Hildenbrand (Red Hat) +Reviewed-by: Rik van Riel +Tested-by: Laurence Oberman +Reviewed-by: Lorenzo Stoakes +Acked-by: Oscar Salvador +Cc: Liu Shixin +Cc: Harry Yoo +Cc: Lance Yang +Cc: "Uschakow, Stanislav" +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + mm/rmap.c | 20 ++++---------------- + 1 file changed, 4 insertions(+), 16 deletions(-) + +--- a/mm/rmap.c ++++ b/mm/rmap.c +@@ -2027,14 +2027,8 @@ static bool try_to_unmap_one(struct foli + flush_tlb_range(vma, + range.start, range.end); + /* +- * The ref count of the PMD page was +- * dropped which is part of the way map +- * counting is done for shared PMDs. +- * Return 'true' here. When there is +- * no other sharing, huge_pmd_unshare +- * returns false and we will unmap the +- * actual page and drop map count +- * to zero. ++ * The PMD table was unmapped, ++ * consequently unmapping the folio. + */ + goto walk_done; + } +@@ -2416,14 +2410,8 @@ static bool try_to_migrate_one(struct fo + range.start, range.end); + + /* +- * The ref count of the PMD page was +- * dropped which is part of the way map +- * counting is done for shared PMDs. +- * Return 'true' here. When there is +- * no other sharing, huge_pmd_unshare +- * returns false and we will unmap the +- * actual page and drop map count +- * to zero. ++ * The PMD table was unmapped, ++ * consequently unmapping the folio. + */ + page_vma_mapped_walk_done(&pvmw); + break; diff --git a/queue-6.18/platform-x86-hp-bioscfg-fix-kernel-panic-in-get_instance_id-macro.patch b/queue-6.18/platform-x86-hp-bioscfg-fix-kernel-panic-in-get_instance_id-macro.patch new file mode 100644 index 0000000000..c0c971feda --- /dev/null +++ b/queue-6.18/platform-x86-hp-bioscfg-fix-kernel-panic-in-get_instance_id-macro.patch @@ -0,0 +1,65 @@ +From 25150715e0b049b99df664daf05dab12f41c3e13 Mon Sep 17 00:00:00 2001 +From: Mario Limonciello +Date: Thu, 15 Jan 2026 14:31:11 -0600 +Subject: platform/x86: hp-bioscfg: Fix kernel panic in GET_INSTANCE_ID macro +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Mario Limonciello + +commit 25150715e0b049b99df664daf05dab12f41c3e13 upstream. + +The GET_INSTANCE_ID macro that caused a kernel panic when accessing sysfs +attributes: + +1. Off-by-one error: The loop condition used '<=' instead of '<', + causing access beyond array bounds. Since array indices are 0-based + and go from 0 to instances_count-1, the loop should use '<'. + +2. Missing NULL check: The code dereferenced attr_name_kobj->name + without checking if attr_name_kobj was NULL, causing a null pointer + dereference in min_length_show() and other attribute show functions. + +The panic occurred when fwupd tried to read BIOS configuration attributes: + + Oops: general protection fault [#1] SMP KASAN NOPTI + KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] + RIP: 0010:min_length_show+0xcf/0x1d0 [hp_bioscfg] + +Add a NULL check for attr_name_kobj before dereferencing and corrects +the loop boundary to match the pattern used elsewhere in the driver. + +Cc: stable@vger.kernel.org +Fixes: 5f94f181ca25 ("platform/x86: hp-bioscfg: bioscfg-h") +Signed-off-by: Mario Limonciello +Link: https://patch.msgid.link/20260115203725.828434-3-mario.limonciello@amd.com +Reviewed-by: Ilpo Järvinen +Signed-off-by: Ilpo Järvinen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/platform/x86/hp/hp-bioscfg/bioscfg.h | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/drivers/platform/x86/hp/hp-bioscfg/bioscfg.h ++++ b/drivers/platform/x86/hp/hp-bioscfg/bioscfg.h +@@ -10,6 +10,7 @@ + + #include + #include ++#include + #include + #include + #include +@@ -285,8 +286,9 @@ enum hp_wmi_data_elements { + { \ + int i; \ + \ +- for (i = 0; i <= bioscfg_drv.type##_instances_count; i++) { \ +- if (!strcmp(kobj->name, bioscfg_drv.type##_data[i].attr_name_kobj->name)) \ ++ for (i = 0; i < bioscfg_drv.type##_instances_count; i++) { \ ++ if (bioscfg_drv.type##_data[i].attr_name_kobj && \ ++ !strcmp(kobj->name, bioscfg_drv.type##_data[i].attr_name_kobj->name)) \ + return i; \ + } \ + return -EIO; \ diff --git a/queue-6.18/platform-x86-hp-bioscfg-fix-kobject-warnings-for-empty-attribute-names.patch b/queue-6.18/platform-x86-hp-bioscfg-fix-kobject-warnings-for-empty-attribute-names.patch new file mode 100644 index 0000000000..6a550f02f2 --- /dev/null +++ b/queue-6.18/platform-x86-hp-bioscfg-fix-kobject-warnings-for-empty-attribute-names.patch @@ -0,0 +1,59 @@ +From fdee1b09721605f532352628d0a24623e7062efb Mon Sep 17 00:00:00 2001 +From: Mario Limonciello +Date: Thu, 15 Jan 2026 14:31:10 -0600 +Subject: platform/x86: hp-bioscfg: Fix kobject warnings for empty attribute names +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Mario Limonciello + +commit fdee1b09721605f532352628d0a24623e7062efb upstream. + +The hp-bioscfg driver attempts to register kobjects with empty names when +the HP BIOS returns attributes with empty name strings. This causes +multiple kernel warnings: + + kobject: (00000000135fb5e6): attempted to be registered with empty name! + WARNING: CPU: 14 PID: 3336 at lib/kobject.c:219 kobject_add_internal+0x2eb/0x310 + +Add validation in hp_init_bios_buffer_attribute() to check if the +attribute name is empty after parsing it from the WMI buffer. If empty, +log a debug message and skip registration of that attribute, allowing the +module to continue processing other valid attributes. + +Cc: stable@vger.kernel.org +Fixes: a34fc329b189 ("platform/x86: hp-bioscfg: bioscfg") +Signed-off-by: Mario Limonciello +Link: https://patch.msgid.link/20260115203725.828434-2-mario.limonciello@amd.com +Reviewed-by: Ilpo Järvinen +Signed-off-by: Ilpo Järvinen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/platform/x86/hp/hp-bioscfg/bioscfg.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/drivers/platform/x86/hp/hp-bioscfg/bioscfg.c ++++ b/drivers/platform/x86/hp/hp-bioscfg/bioscfg.c +@@ -10,6 +10,8 @@ + #include + #include + #include ++#include ++#include + #include + #include "bioscfg.h" + #include "../../firmware_attributes_class.h" +@@ -781,6 +783,12 @@ static int hp_init_bios_buffer_attribute + if (ret < 0) + goto buff_attr_exit; + ++ if (strlen(str) == 0) { ++ pr_debug("Ignoring attribute with empty name\n"); ++ ret = 0; ++ goto buff_attr_exit; ++ } ++ + if (attr_type == HPWMI_PASSWORD_TYPE || + attr_type == HPWMI_SECURE_PLATFORM_TYPE) + temp_kset = bioscfg_drv.authentication_dir_kset; diff --git a/queue-6.18/revert-nfc-nci-add-the-inconsistency-check-between-the-input-data-length-and-count.patch b/queue-6.18/revert-nfc-nci-add-the-inconsistency-check-between-the-input-data-length-and-count.patch new file mode 100644 index 0000000000..5dd3223569 --- /dev/null +++ b/queue-6.18/revert-nfc-nci-add-the-inconsistency-check-between-the-input-data-length-and-count.patch @@ -0,0 +1,46 @@ +From f40ddcc0c0ca1a0122a7f4440b429f97d5832bdf Mon Sep 17 00:00:00 2001 +From: Thadeu Lima de Souza Cascardo +Date: Tue, 13 Jan 2026 17:24:58 -0300 +Subject: Revert "nfc/nci: Add the inconsistency check between the input data length and count" + +From: Thadeu Lima de Souza Cascardo + +commit f40ddcc0c0ca1a0122a7f4440b429f97d5832bdf upstream. + +This reverts commit 068648aab72c9ba7b0597354ef4d81ffaac7b979. + +NFC packets may have NUL-bytes. Checking for string length is not a correct +assumption here. As long as there is a check for the length copied from +copy_from_user, all should be fine. + +The fix only prevented the syzbot reproducer from triggering the bug +because the packet is not enqueued anymore and the code that triggers the +bug is not exercised. + +The fix even broke +testing/selftests/nci/nci_dev, making all tests there fail. After the +revert, 6 out of 8 tests pass. + +Fixes: 068648aab72c ("nfc/nci: Add the inconsistency check between the input data length and count") +Cc: stable@vger.kernel.org +Signed-off-by: Thadeu Lima de Souza Cascardo +Link: https://patch.msgid.link/20260113202458.449455-1-cascardo@igalia.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/nfc/virtual_ncidev.c | 4 ---- + 1 file changed, 4 deletions(-) + +--- a/drivers/nfc/virtual_ncidev.c ++++ b/drivers/nfc/virtual_ncidev.c +@@ -125,10 +125,6 @@ static ssize_t virtual_ncidev_write(stru + kfree_skb(skb); + return -EFAULT; + } +- if (strnlen(skb->data, count) != count) { +- kfree_skb(skb); +- return -EINVAL; +- } + + nci_recv_frame(vdev->ndev, skb); + return count; diff --git a/queue-6.18/rxrpc-fix-recvmsg-unconditional-requeue.patch b/queue-6.18/rxrpc-fix-recvmsg-unconditional-requeue.patch new file mode 100644 index 0000000000..daaeb3bb32 --- /dev/null +++ b/queue-6.18/rxrpc-fix-recvmsg-unconditional-requeue.patch @@ -0,0 +1,101 @@ +From 2c28769a51deb6022d7fbd499987e237a01dd63a Mon Sep 17 00:00:00 2001 +From: David Howells +Date: Wed, 14 Jan 2026 22:03:23 +0000 +Subject: rxrpc: Fix recvmsg() unconditional requeue + +From: David Howells + +commit 2c28769a51deb6022d7fbd499987e237a01dd63a upstream. + +If rxrpc_recvmsg() fails because MSG_DONTWAIT was specified but the call at +the front of the recvmsg queue already has its mutex locked, it requeues +the call - whether or not the call is already queued. The call may be on +the queue because MSG_PEEK was also passed and so the call was not dequeued +or because the I/O thread requeued it. + +The unconditional requeue may then corrupt the recvmsg queue, leading to +things like UAFs or refcount underruns. + +Fix this by only requeuing the call if it isn't already on the queue - and +moving it to the front if it is already queued. If we don't queue it, we +have to put the ref we obtained by dequeuing it. + +Also, MSG_PEEK doesn't dequeue the call so shouldn't call +rxrpc_notify_socket() for the call if we didn't use up all the data on the +queue, so fix that also. + +Fixes: 540b1c48c37a ("rxrpc: Fix deadlock between call creation and sendmsg/recvmsg") +Reported-by: Faith +Reported-by: Pumpkin Chang +Signed-off-by: David Howells +Acked-by: Marc Dionne +cc: Nir Ohfeld +cc: Willy Tarreau +cc: Simon Horman +cc: linux-afs@lists.infradead.org +cc: stable@kernel.org +Link: https://patch.msgid.link/95163.1768428203@warthog.procyon.org.uk +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + include/trace/events/rxrpc.h | 4 ++++ + net/rxrpc/recvmsg.c | 19 +++++++++++++++---- + 2 files changed, 19 insertions(+), 4 deletions(-) + +--- a/include/trace/events/rxrpc.h ++++ b/include/trace/events/rxrpc.h +@@ -322,6 +322,7 @@ + EM(rxrpc_call_put_kernel, "PUT kernel ") \ + EM(rxrpc_call_put_poke, "PUT poke ") \ + EM(rxrpc_call_put_recvmsg, "PUT recvmsg ") \ ++ EM(rxrpc_call_put_recvmsg_peek_nowait, "PUT peek-nwt") \ + EM(rxrpc_call_put_release_recvmsg_q, "PUT rls-rcmq") \ + EM(rxrpc_call_put_release_sock, "PUT rls-sock") \ + EM(rxrpc_call_put_release_sock_tba, "PUT rls-sk-a") \ +@@ -340,6 +341,9 @@ + EM(rxrpc_call_see_input, "SEE input ") \ + EM(rxrpc_call_see_notify_released, "SEE nfy-rlsd") \ + EM(rxrpc_call_see_recvmsg, "SEE recvmsg ") \ ++ EM(rxrpc_call_see_recvmsg_requeue, "SEE recv-rqu") \ ++ EM(rxrpc_call_see_recvmsg_requeue_first, "SEE recv-rqF") \ ++ EM(rxrpc_call_see_recvmsg_requeue_move, "SEE recv-rqM") \ + EM(rxrpc_call_see_release, "SEE release ") \ + EM(rxrpc_call_see_userid_exists, "SEE u-exists") \ + EM(rxrpc_call_see_waiting_call, "SEE q-conn ") \ +--- a/net/rxrpc/recvmsg.c ++++ b/net/rxrpc/recvmsg.c +@@ -518,7 +518,8 @@ try_again: + if (rxrpc_call_has_failed(call)) + goto call_failed; + +- if (!skb_queue_empty(&call->recvmsg_queue)) ++ if (!(flags & MSG_PEEK) && ++ !skb_queue_empty(&call->recvmsg_queue)) + rxrpc_notify_socket(call); + goto not_yet_complete; + +@@ -549,11 +550,21 @@ error_unlock_call: + error_requeue_call: + if (!(flags & MSG_PEEK)) { + spin_lock_irq(&rx->recvmsg_lock); +- list_add(&call->recvmsg_link, &rx->recvmsg_q); +- spin_unlock_irq(&rx->recvmsg_lock); ++ if (list_empty(&call->recvmsg_link)) { ++ list_add(&call->recvmsg_link, &rx->recvmsg_q); ++ rxrpc_see_call(call, rxrpc_call_see_recvmsg_requeue); ++ spin_unlock_irq(&rx->recvmsg_lock); ++ } else if (list_is_first(&call->recvmsg_link, &rx->recvmsg_q)) { ++ spin_unlock_irq(&rx->recvmsg_lock); ++ rxrpc_put_call(call, rxrpc_call_see_recvmsg_requeue_first); ++ } else { ++ list_move(&call->recvmsg_link, &rx->recvmsg_q); ++ spin_unlock_irq(&rx->recvmsg_lock); ++ rxrpc_put_call(call, rxrpc_call_see_recvmsg_requeue_move); ++ } + trace_rxrpc_recvmsg(call_debug_id, rxrpc_recvmsg_requeue, 0); + } else { +- rxrpc_put_call(call, rxrpc_call_put_recvmsg); ++ rxrpc_put_call(call, rxrpc_call_put_recvmsg_peek_nowait); + } + error_no_call: + release_sock(&rx->sk); diff --git a/queue-6.18/scsi-storvsc-process-unsupported-mode_sense_10.patch b/queue-6.18/scsi-storvsc-process-unsupported-mode_sense_10.patch new file mode 100644 index 0000000000..36ea07fac7 --- /dev/null +++ b/queue-6.18/scsi-storvsc-process-unsupported-mode_sense_10.patch @@ -0,0 +1,44 @@ +From 9eacec5d18f98f89be520eeeef4b377acee3e4b8 Mon Sep 17 00:00:00 2001 +From: Long Li +Date: Fri, 16 Jan 2026 17:03:02 -0800 +Subject: scsi: storvsc: Process unsupported MODE_SENSE_10 + +From: Long Li + +commit 9eacec5d18f98f89be520eeeef4b377acee3e4b8 upstream. + +The Hyper-V host does not support MODE_SENSE_10 and MODE_SENSE. The +driver handles MODE_SENSE as unsupported command, but not for +MODE_SENSE_10. Add MODE_SENSE_10 to the same handling logic and return +correct code to SCSI layer. + +Fixes: 89ae7d709357 ("Staging: hv: storvsc: Move the storage driver out of the staging area") +Cc: stable@kernel.org +Signed-off-by: Long Li +Reviewed-by: Michael Kelley +Link: https://patch.msgid.link/20260117010302.294068-1-longli@linux.microsoft.com +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/scsi/storvsc_drv.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/scsi/storvsc_drv.c ++++ b/drivers/scsi/storvsc_drv.c +@@ -1144,7 +1144,7 @@ static void storvsc_on_io_completion(str + * The current SCSI handling on the host side does + * not correctly handle: + * INQUIRY command with page code parameter set to 0x80 +- * MODE_SENSE command with cmd[2] == 0x1c ++ * MODE_SENSE and MODE_SENSE_10 command with cmd[2] == 0x1c + * MAINTENANCE_IN is not supported by HyperV FC passthrough + * + * Setup srb and scsi status so this won't be fatal. +@@ -1154,6 +1154,7 @@ static void storvsc_on_io_completion(str + + if ((stor_pkt->vm_srb.cdb[0] == INQUIRY) || + (stor_pkt->vm_srb.cdb[0] == MODE_SENSE) || ++ (stor_pkt->vm_srb.cdb[0] == MODE_SENSE_10) || + (stor_pkt->vm_srb.cdb[0] == MAINTENANCE_IN && + hv_dev_is_fc(device))) { + vstor_packet->vm_srb.scsi_status = 0; diff --git a/queue-6.18/scsi-xen-scsiback-fix-potential-memory-leak-in-scsiback_remove.patch b/queue-6.18/scsi-xen-scsiback-fix-potential-memory-leak-in-scsiback_remove.patch new file mode 100644 index 0000000000..52340264e8 --- /dev/null +++ b/queue-6.18/scsi-xen-scsiback-fix-potential-memory-leak-in-scsiback_remove.patch @@ -0,0 +1,35 @@ +From 901a5f309daba412e2a30364d7ec1492fa11c32c Mon Sep 17 00:00:00 2001 +From: Abdun Nihaal +Date: Tue, 23 Dec 2025 12:00:11 +0530 +Subject: scsi: xen: scsiback: Fix potential memory leak in scsiback_remove() + +From: Abdun Nihaal + +commit 901a5f309daba412e2a30364d7ec1492fa11c32c upstream. + +Memory allocated for struct vscsiblk_info in scsiback_probe() is not +freed in scsiback_remove() leading to potential memory leaks on remove, +as well as in the scsiback_probe() error paths. Fix that by freeing it +in scsiback_remove(). + +Cc: stable@vger.kernel.org +Fixes: d9d660f6e562 ("xen-scsiback: Add Xen PV SCSI backend driver") +Signed-off-by: Abdun Nihaal +Reviewed-by: Juergen Gross +Link: https://patch.msgid.link/20251223063012.119035-1-nihaal@cse.iitm.ac.in +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/xen/xen-scsiback.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/xen/xen-scsiback.c ++++ b/drivers/xen/xen-scsiback.c +@@ -1262,6 +1262,7 @@ static void scsiback_remove(struct xenbu + gnttab_page_cache_shrink(&info->free_pages, 0); + + dev_set_drvdata(&dev->dev, NULL); ++ kfree(info); + } + + static int scsiback_probe(struct xenbus_device *dev, diff --git a/queue-6.18/series b/queue-6.18/series index 54037e6233..00a0a1265d 100644 --- a/queue-6.18/series +++ b/queue-6.18/series @@ -51,3 +51,31 @@ serial-fix-not-set-tty-port-race-condition.patch comedi-dmm32at-serialize-use-of-paged-registers.patch w1-therm-fix-off-by-one-buffer-overflow-in-alarms_store.patch w1-fix-redundant-counter-decrement-in-w1_attach_slave_device.patch +revert-nfc-nci-add-the-inconsistency-check-between-the-input-data-length-and-count.patch +input-i8042-add-quirks-for-mechrevo-wujie-15x-pro.patch +input-i8042-add-quirk-for-asus-zenbook-ux425qa_um425qa.patch +scsi-storvsc-process-unsupported-mode_sense_10.patch +scsi-xen-scsiback-fix-potential-memory-leak-in-scsiback_remove.patch +i2c-spacemit-drop-irqf_oneshot-flag-from-irq-request.patch +arm-dts-microchip-sama7d65-fix-the-ranges-property-for-flx9.patch +arm-dts-microchip-sama7d65-fix-size-cells-property-for-i2c3.patch +arm64-dts-rockchip-remove-redundant-max-link-speed-from-nanopi-r4s.patch +arm64-dts-rockchip-remove-dangerous-max-link-speed-from-helios64.patch +arm64-dts-rockchip-fix-voltage-threshold-for-volume-keys-for-pinephone-pro.patch +arm64-dts-rockchip-fix-unit-address-for-rk3588-npu-s-core1-and-core2-s-iommu.patch +arm64-dts-rockchip-fix-headphones-widget-name-on-nanopi-m5.patch +arm64-dts-rockchip-configure-mclk-for-analog-sound-on-nanopi-m5.patch +slab-fix-kmalloc_nolock-context-check-for-preempt_rt.patch +rxrpc-fix-recvmsg-unconditional-requeue.patch +x86-kfence-avoid-writing-l1tf-vulnerable-ptes.patch +comedi-fix-getting-range-information-for-subdevices-16-to-255.patch +fs-writeback-skip-as_no_data_integrity-mappings-in-wait_sb_inodes.patch +drm-drm-xe-fix-xe-userptr-in-the-absence-of-config_device_private.patch +platform-x86-hp-bioscfg-fix-kobject-warnings-for-empty-attribute-names.patch +platform-x86-hp-bioscfg-fix-kernel-panic-in-get_instance_id-macro.patch +mm-hugetlb-fix-hugetlb_pmd_shared.patch +mm-rmap-fix-two-comments-related-to-huge_pmd_unshare.patch +mm-restore-per-memcg-proactive-reclaim-with-config_numa.patch +timekeeping-adjust-the-leap-state-for-the-correct-auxiliary-timekeeper.patch +io_uring-io-wq-check-io_wq_bit_exit-inside-work-run-loop.patch +iio-imu-st_lsm6dsx-fix-iio_chan_spec-for-sensors-without-event-detection.patch diff --git a/queue-6.18/slab-fix-kmalloc_nolock-context-check-for-preempt_rt.patch b/queue-6.18/slab-fix-kmalloc_nolock-context-check-for-preempt_rt.patch new file mode 100644 index 0000000000..5aa1ac8e9d --- /dev/null +++ b/queue-6.18/slab-fix-kmalloc_nolock-context-check-for-preempt_rt.patch @@ -0,0 +1,60 @@ +From 99a3e3a1cfc93b8fe318c0a3a5cfb01f1d4ad53c Mon Sep 17 00:00:00 2001 +From: Swaraj Gaikwad +Date: Tue, 13 Jan 2026 20:36:39 +0530 +Subject: slab: fix kmalloc_nolock() context check for PREEMPT_RT + +From: Swaraj Gaikwad + +commit 99a3e3a1cfc93b8fe318c0a3a5cfb01f1d4ad53c upstream. + +On PREEMPT_RT kernels, local_lock becomes a sleeping lock. The current +check in kmalloc_nolock() only verifies we're not in NMI or hard IRQ +context, but misses the case where preemption is disabled. + +When a BPF program runs from a tracepoint with preemption disabled +(preempt_count > 0), kmalloc_nolock() proceeds to call +local_lock_irqsave() which attempts to acquire a sleeping lock, +triggering: + + BUG: sleeping function called from invalid context + in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 6128 + preempt_count: 2, expected: 0 + +Fix this by checking !preemptible() on PREEMPT_RT, which directly +expresses the constraint that we cannot take a sleeping lock when +preemption is disabled. This encompasses the previous checks for NMI +and hard IRQ contexts while also catching cases where preemption is +disabled. + +Fixes: af92793e52c3 ("slab: Introduce kmalloc_nolock() and kfree_nolock().") +Reported-by: syzbot+b1546ad4a95331b2101e@syzkaller.appspotmail.com +Closes: https://syzkaller.appspot.com/bug?extid=b1546ad4a95331b2101e +Signed-off-by: Swaraj Gaikwad +Acked-by: Sebastian Andrzej Siewior +Acked-by: Alexei Starovoitov +Acked-by: Harry Yoo +Link: https://patch.msgid.link/20260113150639.48407-1-swarajgaikwad1925@gmail.co +Cc: +Signed-off-by: Vlastimil Babka +Signed-off-by: Greg Kroah-Hartman +--- + mm/slub.c | 8 ++++++-- + 1 file changed, 6 insertions(+), 2 deletions(-) + +--- a/mm/slub.c ++++ b/mm/slub.c +@@ -5692,8 +5692,12 @@ void *kmalloc_nolock_noprof(size_t size, + if (unlikely(!size)) + return ZERO_SIZE_PTR; + +- if (IS_ENABLED(CONFIG_PREEMPT_RT) && (in_nmi() || in_hardirq())) +- /* kmalloc_nolock() in PREEMPT_RT is not supported from irq */ ++ if (IS_ENABLED(CONFIG_PREEMPT_RT) && !preemptible()) ++ /* ++ * kmalloc_nolock() in PREEMPT_RT is not supported from ++ * non-preemptible context because local_lock becomes a ++ * sleeping lock on RT. ++ */ + return NULL; + retry: + if (unlikely(size > KMALLOC_MAX_CACHE_SIZE)) diff --git a/queue-6.18/timekeeping-adjust-the-leap-state-for-the-correct-auxiliary-timekeeper.patch b/queue-6.18/timekeeping-adjust-the-leap-state-for-the-correct-auxiliary-timekeeper.patch new file mode 100644 index 0000000000..b2229c0feb --- /dev/null +++ b/queue-6.18/timekeeping-adjust-the-leap-state-for-the-correct-auxiliary-timekeeper.patch @@ -0,0 +1,50 @@ +From e806f7dde8ba28bc72a7a0898589cac79f6362ac Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Thomas=20Wei=C3=9Fschuh?= +Date: Tue, 20 Jan 2026 07:55:55 +0100 +Subject: timekeeping: Adjust the leap state for the correct auxiliary timekeeper +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Thomas Weißschuh + +commit e806f7dde8ba28bc72a7a0898589cac79f6362ac upstream. + +When __do_ajdtimex() was introduced to handle adjtimex for any +timekeeper, this reference to tk_core was not updated. When called on an +auxiliary timekeeper, the core timekeeper would be updated incorrectly. + +This gets caught by the lock debugging diagnostics because the +timekeepers sequence lock gets written to without holding its +associated spinlock: + +WARNING: include/linux/seqlock.h:226 at __do_adjtimex+0x394/0x3b0, CPU#2: test/125 +aux_clock_adj (kernel/time/timekeeping.c:2979) +__do_sys_clock_adjtime (kernel/time/posix-timers.c:1161 kernel/time/posix-timers.c:1173) +do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) +entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:131) + +Update the correct auxiliary timekeeper. + +Fixes: 775f71ebedd3 ("timekeeping: Make do_adjtimex() reusable") +Fixes: ecf3e7030491 ("timekeeping: Provide adjtimex() for auxiliary clocks") +Signed-off-by: Thomas Weißschuh +Signed-off-by: Thomas Gleixner +Cc: stable@vger.kernel.org +Link: https://patch.msgid.link/20260120-timekeeper-auxclock-leapstate-v1-1-5b358c6b3cfd@linutronix.de +Signed-off-by: Greg Kroah-Hartman +--- + kernel/time/timekeeping.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/kernel/time/timekeeping.c ++++ b/kernel/time/timekeeping.c +@@ -2721,7 +2721,7 @@ static int __do_adjtimex(struct tk_data + timekeeping_update_from_shadow(tkd, TK_CLOCK_WAS_SET); + result->clock_set = true; + } else { +- tk_update_leap_state_all(&tk_core); ++ tk_update_leap_state_all(tkd); + } + + /* Update the multiplier immediately if frequency was set directly */ diff --git a/queue-6.18/x86-kfence-avoid-writing-l1tf-vulnerable-ptes.patch b/queue-6.18/x86-kfence-avoid-writing-l1tf-vulnerable-ptes.patch new file mode 100644 index 0000000000..d44739e530 --- /dev/null +++ b/queue-6.18/x86-kfence-avoid-writing-l1tf-vulnerable-ptes.patch @@ -0,0 +1,114 @@ +From b505f1944535f83d369ae68813e7634d11b990d3 Mon Sep 17 00:00:00 2001 +From: Andrew Cooper +Date: Tue, 6 Jan 2026 18:04:26 +0000 +Subject: x86/kfence: avoid writing L1TF-vulnerable PTEs + +From: Andrew Cooper + +commit b505f1944535f83d369ae68813e7634d11b990d3 upstream. + +For native, the choice of PTE is fine. There's real memory backing the +non-present PTE. However, for XenPV, Xen complains: + + (XEN) d1 L1TF-vulnerable L1e 8010000018200066 - Shadowing + +To explain, some background on XenPV pagetables: + + Xen PV guests are control their own pagetables; they choose the new + PTE value, and use hypercalls to make changes so Xen can audit for + safety. + + In addition to a regular reference count, Xen also maintains a type + reference count. e.g. SegDesc (referenced by vGDT/vLDT), Writable + (referenced with _PAGE_RW) or L{1..4} (referenced by vCR3 or a lower + pagetable level). This is in order to prevent e.g. a page being + inserted into the pagetables for which the guest has a writable mapping. + + For non-present mappings, all other bits become software accessible, + and typically contain metadata rather a real frame address. There is + nothing that a reference count could sensibly be tied to. As such, even + if Xen could recognise the address as currently safe, nothing would + prevent that frame from changing owner to another VM in the future. + + When Xen detects a PV guest writing a L1TF-PTE, it responds by + activating shadow paging. This is normally only used for the live phase + of migration, and comes with a reasonable overhead. + +KFENCE only cares about getting #PF to catch wild accesses; it doesn't +care about the value for non-present mappings. Use a fully inverted PTE, +to avoid hitting the slow path when running under Xen. + +While adjusting the logic, take the opportunity to skip all actions if the +PTE is already in the right state, half the number PVOps callouts, and +skip TLB maintenance on a !P -> P transition which benefits non-Xen cases +too. + +Link: https://lkml.kernel.org/r/20260106180426.710013-1-andrew.cooper3@citrix.com +Fixes: 1dc0da6e9ec0 ("x86, kfence: enable KFENCE for x86") +Signed-off-by: Andrew Cooper +Tested-by: Marco Elver +Cc: Alexander Potapenko +Cc: Marco Elver +Cc: Dmitry Vyukov +Cc: Thomas Gleixner +Cc: Ingo Molnar +Cc: Borislav Petkov +Cc: Dave Hansen +Cc: "H. Peter Anvin" +Cc: Jann Horn +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/include/asm/kfence.h | 29 ++++++++++++++++++++++++----- + 1 file changed, 24 insertions(+), 5 deletions(-) + +--- a/arch/x86/include/asm/kfence.h ++++ b/arch/x86/include/asm/kfence.h +@@ -42,10 +42,34 @@ static inline bool kfence_protect_page(u + { + unsigned int level; + pte_t *pte = lookup_address(addr, &level); ++ pteval_t val; + + if (WARN_ON(!pte || level != PG_LEVEL_4K)) + return false; + ++ val = pte_val(*pte); ++ ++ /* ++ * protect requires making the page not-present. If the PTE is ++ * already in the right state, there's nothing to do. ++ */ ++ if (protect != !!(val & _PAGE_PRESENT)) ++ return true; ++ ++ /* ++ * Otherwise, invert the entire PTE. This avoids writing out an ++ * L1TF-vulnerable PTE (not present, without the high address bits ++ * set). ++ */ ++ set_pte(pte, __pte(~val)); ++ ++ /* ++ * If the page was protected (non-present) and we're making it ++ * present, there is no need to flush the TLB at all. ++ */ ++ if (!protect) ++ return true; ++ + /* + * We need to avoid IPIs, as we may get KFENCE allocations or faults + * with interrupts disabled. Therefore, the below is best-effort, and +@@ -53,11 +77,6 @@ static inline bool kfence_protect_page(u + * lazy fault handling takes care of faults after the page is PRESENT. + */ + +- if (protect) +- set_pte(pte, __pte(pte_val(*pte) & ~_PAGE_PRESENT)); +- else +- set_pte(pte, __pte(pte_val(*pte) | _PAGE_PRESENT)); +- + /* + * Flush this CPU's TLB, assuming whoever did the allocation/free is + * likely to continue running on this CPU.