July 2025 - Linux-stable-mirror

[PATCH v2 1/4] arm64: dts: imx8mp-venice-gw71xx: fix TPM SPI frequency

by Tim Harvey

The IMX8MPDS Table 37 [1] shows that the max SPI master read frequency depends on the pins the interface is muxed behind with ECSPI2 muxed behind ECSPI2 supporting up to 25MHz. Adjust the spi-max-frequency based on these findings. [1] https://www.nxp.com/webapp/Download?colCode=IMX8MPIEC Fixes: 1a8f6ff6a291 ("arm64: dts: imx8mp-venice-gw71xx: add TPM device") Cc: stable(a)vger.kernel.org Signed-off-by: Tim Harvey <tharvey(a)gateworks.com> --- v2: add cc to stable --- arch/arm64/boot/dts/freescale/imx8mp-venice-gw71xx.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/freescale/imx8mp-venice-gw71xx.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-venice-gw71xx.dtsi index 2f740d74707b..4bf818873fe3 100644 --- a/arch/arm64/boot/dts/freescale/imx8mp-venice-gw71xx.dtsi +++ b/arch/arm64/boot/dts/freescale/imx8mp-venice-gw71xx.dtsi @@ -70,7 +70,7 @@ &ecspi2 { tpm@1 { compatible = "atmel,attpm20p", "tcg,tpm_tis-spi"; reg = <0x1>; - spi-max-frequency = <36000000>; + spi-max-frequency = <25000000>; }; }; -- 2.25.1

7 hours, 3 minutes

2
4
0 0

[PATCH v2] sched: Fix preemption string of preempt_dynamic_none

by Thomas Weißschuh

Zero is a valid value for "preempt_dynamic_mode", namely "preempt_dynamic_none". Fix the off-by-one in preempt_model_str(), so that "preempty_dynamic_none" is correctly formatted as PREEMPT(none) instead of PREEMPT(undef). Fixes: 8bdc5daaa01e ("sched: Add a generic function to return the preemption string") Cc: stable(a)vger.kernel.org Signed-off-by: Thomas Weißschuh <thomas.weissschuh(a)linutronix.de> Tested-by: Shrikanth Hegde <sshegde(a)linux.ibm.com> Reviewed-by: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de> --- Changes in v2: - Pick up Reviewed-by and Tested-by - Rebase on v6.16-rc1 - Link to v1: https://lore.kernel.org/r/20250603-preempt-str-none-v1-1-f0e9916dcf44@linut… --- kernel/sched/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index dce50fa57471dffc4311b9d393ae300a43d38d20..021b0a703d094b3386c5ba50e0e111e3a7c2b3df 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -7663,7 +7663,7 @@ const char *preempt_model_str(void) if (IS_ENABLED(CONFIG_PREEMPT_DYNAMIC)) { seq_buf_printf(&s, "(%s)%s", - preempt_dynamic_mode > 0 ? + preempt_dynamic_mode >= 0 ? preempt_modes[preempt_dynamic_mode] : "undef", brace ? "}" : ""); return seq_buf_str(&s); --- base-commit: 19272b37aa4f83ca52bdf9c16d5d81bdd1354494 change-id: 20250603-preempt-str-none-d21231cc2238 Best regards, -- Thomas Weißschuh <thomas.weissschuh(a)linutronix.de>

7 hours, 37 minutes

2
1
0 0

[PATCH] i2c: qup: jump out of the loop in case of timeout

by Yang Xiwen via B4 Relay

From: Yang Xiwen <forbidden405(a)outlook.com> Original logic only sets the return value but doesn't jump out of the loop if the bus is kept active by a client. This is not expected. A malicious or buggy i2c client can hang the kernel in this case and should be avoided. This is observed during a long time test with a PCA953x GPIO extender. Fix it by changing the logic to not only sets the return value, but also jumps out of the loop and return to the caller with -ETIMEDOUT. Cc: stable(a)vger.kernel.org Signed-off-by: Yang Xiwen <forbidden405(a)outlook.com> --- drivers/i2c/busses/i2c-qup.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c index 3a36d682ed57..5b053e51f4c9 100644 --- a/drivers/i2c/busses/i2c-qup.c +++ b/drivers/i2c/busses/i2c-qup.c @@ -452,8 +452,10 @@ static int qup_i2c_bus_active(struct qup_i2c_dev *qup, int len) if (!(status & I2C_STATUS_BUS_ACTIVE)) break; - if (time_after(jiffies, timeout)) + if (time_after(jiffies, timeout)) { ret = -ETIMEDOUT; + break; + } usleep_range(len, len * 2); } --- base-commit: 19272b37aa4f83ca52bdf9c16d5d81bdd1354494 change-id: 20250615-qca-i2c-d41bb61aa59e Best regards, -- Yang Xiwen <forbidden405(a)outlook.com>

7 hours, 58 minutes

3
2
0 0

[REGRESSION] Packet loss after hot-plugging ethernet cable on HP Zbook (Arrow Lake)

by En-Wei WU

Hi, I'm seeing a regression on an HP ZBook using the e1000e driver (chipset PCI ID: [8086:57a0]) -- the system can't get an IP address after hot-plugging an Ethernet cable. In this case, the Ethernet cable was unplugged at boot. The network interface eno1 was present but stuck in the DHCP process. Using tcpdump, only TX packets were visible and never got any RX -- indicating a possible packet loss or link-layer issue. This is on the vanilla Linux 6.16-rc4 (commit 62f224733431dbd564c4fe800d4b67a0cf92ed10). Bisect says it's this commit: commit efaaf344bc2917cbfa5997633bc18a05d3aed27f Author: Vitaly Lifshits <vitaly.lifshits(a)intel.com> Date: Thu Mar 13 16:05:56 2025 +0200 e1000e: change k1 configuration on MTP and later platforms Starting from Meteor Lake, the Kumeran interface between the integrated MAC and the I219 PHY works at a different frequency. This causes sporadic MDI errors when accessing the PHY, and in rare circumstances could lead to packet corruption. To overcome this, introduce minor changes to the Kumeran idle state (K1) parameters during device initialization. Hardware reset reverts this configuration, therefore it needs to be applied in a few places. Fixes: cc23f4f0b6b9 ("e1000e: Add support for Meteor Lake") Signed-off-by: Vitaly Lifshits <vitaly.lifshits(a)intel.com> Tested-by: Avigail Dahan <avigailx.dahan(a)intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen(a)intel.com> drivers/net/ethernet/intel/e1000e/defines.h | 3 +++ drivers/net/ethernet/intel/e1000e/ich8lan.c | 80 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----- drivers/net/ethernet/intel/e1000e/ich8lan.h | 4 ++++ 3 files changed, 82 insertions(+), 5 deletions(-) Reverting this patch resolves the issue. Based on the symptoms and the bisect result, this issue might be similar to https://lore.kernel.org/intel-wired-lan/20250626153544.1853d106@onyx.my.dom… Affected machine is: HP ZBook X G1i 16 inch Mobile Workstation PC, BIOS 01.02.03 05/27/2025 (see end of message for dmesg from boot) CPU model name: Intel(R) Core(TM) Ultra 7 265H (Arrow Lake) ethtool output: driver: e1000e version: 6.16.0-061600rc4-generic firmware-version: 0.1-4 expansion-rom-version: bus-info: 0000:00:1f.6 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: yes lspci output: 0:1f.6 Ethernet controller [0200]: Intel Corporation Device [8086:57a0] DeviceName: Onboard Ethernet Subsystem: Hewlett-Packard Company Device [103c:8e1d] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin D routed to IRQ 162 IOMMU group: 17 Region 0: Memory at 92280000 (32-bit, non-prefetchable) [size=128K] Capabilities: [c8] Power Management version 3 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=1 PME- Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Address: 00000000fee00798 Data: 0000 Kernel driver in use: e1000e Kernel modules: e1000e The relevant dmesg: <<<cable disconnected>>> [ 0.927394] e1000e: Intel(R) PRO/1000 Network Driver [ 0.927398] e1000e: Copyright(c) 1999 - 2015 Intel Corporation. [ 0.927933] e1000e 0000:00:1f.6: enabling device (0000 -> 0002) [ 0.928249] e1000e 0000:00:1f.6: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode [ 1.155716] e1000e 0000:00:1f.6 0000:00:1f.6 (uninitialized): registered PHC clock [ 1.220694] e1000e 0000:00:1f.6 eth0: (PCI Express:2.5GT/s:Width x1) 24:fb:e3:bf:28:c6 [ 1.220721] e1000e 0000:00:1f.6 eth0: Intel(R) PRO/1000 Network Connection [ 1.220903] e1000e 0000:00:1f.6 eth0: MAC: 16, PHY: 12, PBA No: FFFFFF-0FF [ 1.222632] e1000e 0000:00:1f.6 eno1: renamed from eth0 <<<cable connected>>> [ 153.932626] e1000e 0000:00:1f.6 eno1: NIC Link is Up 1000 Mbps Half Duplex, Flow Control: None [ 153.934527] e1000e 0000:00:1f.6 eno1: NIC Link is Down [ 157.622238] e1000e 0000:00:1f.6 eno1: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None No error message seen after hot-plugging the Ethernet cable. -- Best Regards, En-Wei.

8 hours, 6 minutes

3
2
0 0

GOOD DAY

by Muhammad Sohaib Manzoor

GOOD DAY Thanks for your response. I'm Muhammad Sohaib Manzoor, a financial consultant in Dubai. I'm managing the estate of late AU metal dealers— $55 million USD and 320kg of gold. Their daughter seeks a trusted partner to help reinvest in low-risk ventures. Funds will be transferred legally through a secured financial channel. Let me know, I’m seeking just a 15% share once the business starts. Let me know if you're interested. if you're interested, and I’ll share full details. Best, Muhammad

8 hours, 11 minutes

1
0
0 0

[PATCH stable] ipmi:msghandler: Fix potential memory corruption in ipmi_create_user()

by Brendan Jackman

From: Dan Carpenter <dan.carpenter(a)linaro.org> commit fa332f5dc6fc662ad7d3200048772c96b861cf6b upstream The "intf" list iterator is an invalid pointer if the correct "intf->intf_num" is not found. Calling atomic_dec(&intf->nr_users) on and invalid pointer will lead to memory corruption. We don't really need to call atomic_dec() if we haven't called atomic_add_return() so update the if (intf->in_shutdown) path as well. Fixes: 8e76741c3d8b ("ipmi: Add a limit on the number of users that may use IPMI") Signed-off-by: Dan Carpenter <dan.carpenter(a)linaro.org> Message-ID: <aBjMZ8RYrOt6NOgi(a)stanley.mountain> Signed-off-by: Corey Minyard <corey(a)minyard.net> Signed-off-by: Brendan Jackman <jackmanb(a)google.com> --- I have tested this in 6.12 with Google's platform drivers added to reproduce the bug. The bug causes the panic notifier chain to get corrupted leading to a crash. With the fix this goes away. Applies to 6.6 too but I haven't tested it there. Backport changes: - Dropped change to the `if (intf->in_shutdown)` block since that logic doesn't exist yet. - Modified out_unlock to release the srcu lock instead of the mutex since we don't have the mutex here yet. --- drivers/char/ipmi/ipmi_msghandler.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/char/ipmi/ipmi_msghandler.c b/drivers/char/ipmi/ipmi_msghandler.c index e12b531f5c2f338008a42dc2c35b0a62395c9f3c..6a4a8ecd0edd02793eda70f9f9ae578e37da477f 100644 --- a/drivers/char/ipmi/ipmi_msghandler.c +++ b/drivers/char/ipmi/ipmi_msghandler.c @@ -1241,7 +1241,7 @@ int ipmi_create_user(unsigned int if_num, } /* Not found, return an error */ rv = -EINVAL; - goto out_kfree; + goto out_unlock; found: if (atomic_add_return(1, &intf->nr_users) > max_users) { @@ -1283,6 +1283,7 @@ int ipmi_create_user(unsigned int if_num, out_kfree: atomic_dec(&intf->nr_users); +out_unlock: srcu_read_unlock(&ipmi_interfaces_srcu, index); vfree(new_user); return rv; --- base-commit: 783cd2c3dca8b6c434e955b84c20c8940588dc68 change-id: 20250630-ipmi-fix-c565f7098afd Best regards, -- Brendan Jackman <jackmanb(a)google.com>

9 hours, 21 minutes

3
5
0 0

[PATCH v2] arm64: dts: qcom: qcs615: add missing dt property in QUP SEs

by Viken Dadhaniya

Add the missing required-opps and operating-points-v2 properties to several I2C, SPI, and UART nodes in the QUP SEs. Fixes: f6746dc9e379 ("arm64: dts: qcom: qcs615: Add QUPv3 configuration") Cc: stable(a)vger.kernel.org Signed-off-by: Viken Dadhaniya <viken.dadhaniya(a)oss.qualcomm.com> --- v1 -> v2: - Added Fixes and Cc tag. v1 Link: https://lore.kernel.org/all/20250626102826.3422984-1-viken.dadhaniya@oss.qu… --- --- arch/arm64/boot/dts/qcom/qcs615.dtsi | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/qcs615.dtsi b/arch/arm64/boot/dts/qcom/qcs615.dtsi index bfbb21035492..e033b53f0f0f 100644 --- a/arch/arm64/boot/dts/qcom/qcs615.dtsi +++ b/arch/arm64/boot/dts/qcom/qcs615.dtsi @@ -631,6 +631,7 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>, interconnect-names = "qup-core", "qup-config"; power-domains = <&rpmhpd RPMHPD_CX>; + operating-points-v2 = <&qup_opp_table>; status = "disabled"; }; @@ -654,6 +655,7 @@ &config_noc SLAVE_QUP_0 QCOM_ICC_TAG_ALWAYS>, "qup-config", "qup-memory"; power-domains = <&rpmhpd RPMHPD_CX>; + required-opps = <&rpmhpd_opp_low_svs>; dmas = <&gpi_dma0 0 1 QCOM_GPI_I2C>, <&gpi_dma0 1 1 QCOM_GPI_I2C>; dma-names = "tx", @@ -681,6 +683,7 @@ &config_noc SLAVE_QUP_0 QCOM_ICC_TAG_ALWAYS>, "qup-config", "qup-memory"; power-domains = <&rpmhpd RPMHPD_CX>; + required-opps = <&rpmhpd_opp_low_svs>; dmas = <&gpi_dma0 0 2 QCOM_GPI_I2C>, <&gpi_dma0 1 2 QCOM_GPI_I2C>; dma-names = "tx", @@ -703,6 +706,7 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>, interconnect-names = "qup-core", "qup-config"; power-domains = <&rpmhpd RPMHPD_CX>; + operating-points-v2 = <&qup_opp_table>; dmas = <&gpi_dma0 0 2 QCOM_GPI_SPI>, <&gpi_dma0 1 2 QCOM_GPI_SPI>; dma-names = "tx", @@ -728,6 +732,7 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>, interconnect-names = "qup-core", "qup-config"; power-domains = <&rpmhpd RPMHPD_CX>; + operating-points-v2 = <&qup_opp_table>; status = "disabled"; }; @@ -751,6 +756,7 @@ &config_noc SLAVE_QUP_0 QCOM_ICC_TAG_ALWAYS>, "qup-config", "qup-memory"; power-domains = <&rpmhpd RPMHPD_CX>; + required-opps = <&rpmhpd_opp_low_svs>; dmas = <&gpi_dma0 0 3 QCOM_GPI_I2C>, <&gpi_dma0 1 3 QCOM_GPI_I2C>; dma-names = "tx", -- 2.34.1

9 hours, 21 minutes

2
1
0 0

Re: Patch "drm/i915/gem: Allow EXEC_CAPTURE on recoverable contexts on DG1" has been added to the 6.1-stable tree

by Joonas Lahtinen

Hi Greg, Please do note that there is a revert for this patch that was part of the same pull request. That needs to be picked in too in case you are picking the original patch. I already got the automated mails from Sasha that both the original commit and revert were already picked into 6.1, 6.6 and 6.12 trees. Are now in a perpetual machinery induced loop where the original commit and revert will be picked in alternating fashion to the stable trees? [1] Regards, Joonas [1] Originally, I was under the assumption stable machinery would automatically skip over patches that have later been reverted, but that doesn't seem to be the case? Quoting gregkh(a)linuxfoundation.org (2025-06-30 14:39:44) > > This is a note to let you know that I've just added the patch titled > > drm/i915/gem: Allow EXEC_CAPTURE on recoverable contexts on DG1 > > to the 6.1-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > drm-i915-gem-allow-exec_capture-on-recoverable-contexts-on-dg1.patch > and it can be found in the queue-6.1 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. > > > From 25eeba495b2fc16037647c1a51bcdf6fc157af5c Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala(a)linux.intel.com> > Date: Mon, 12 May 2025 21:22:15 +0200 > Subject: drm/i915/gem: Allow EXEC_CAPTURE on recoverable contexts on DG1 > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> > > commit 25eeba495b2fc16037647c1a51bcdf6fc157af5c upstream. > > The intel-media-driver is currently broken on DG1 because > it uses EXEC_CAPTURE with recovarable contexts. Relax the > check to allow that. > > I've also submitted a fix for the intel-media-driver: > https://github.com/intel/media-driver/pull/1920 > > Cc: stable(a)vger.kernel.org # v6.0+ > Cc: Matthew Auld <matthew.auld(a)intel.com> > Cc: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> > Testcase: igt/gem_exec_capture/capture-invisible > Fixes: 71b1669ea9bd ("drm/i915/uapi: tweak error capture on recoverable contexts") > Reviewed-by: Andi Shyti <andi.shyti(a)linux.intel.com> > Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> > Signed-off-by: Andi Shyti <andi.shyti(a)kernel.org> > Link: https://lore.kernel.org/r/20250411144313.11660-2-ville.syrjala@linux.intel.… > (cherry picked from commit d6e020819612a4a06207af858e0978be4d3e3140) > Signed-off-by: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> > Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> > --- > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c > @@ -2001,7 +2001,7 @@ static int eb_capture_stage(struct i915_ > continue; > > if (i915_gem_context_is_recoverable(eb->gem_context) && > - (IS_DGFX(eb->i915) || GRAPHICS_VER_FULL(eb->i915) > IP_VER(12, 0))) > + GRAPHICS_VER_FULL(eb->i915) > IP_VER(12, 10)) > return -EINVAL; > > for_each_batch_create_order(eb, j) { > > > Patches currently in stable-queue which might be from ville.syrjala(a)linux.intel.com are > > queue-6.1/drm-dp-change-aux-dpcd-probe-address-from-dpcd_rev-to-lane0_1_status.patch > queue-6.1/revert-drm-i915-gem-allow-exec_capture-on-recoverabl.patch > queue-6.1/drm-i915-gem-allow-exec_capture-on-recoverable-contexts-on-dg1.patch > queue-6.1/drm-i915-gem-allow-exec_capture-on-recoverable-conte.patch

10 hours, 8 minutes

1
0
0 0

[PATCH v2] drm/xe/bmg: fix compressed VRAM handling

by Matthew Auld

There looks to be an issue in our compression handling when the BO pages are very fragmented, where we choose to skip the identity map and instead fall back to emitting the PTEs by hand when migrating memory, such that we can hopefully do more work per blit operation. However in such a case we need to ensure the src PTEs are correctly tagged with a compression enabled PAT index on dgpu xe2+, otherwise the copy will simply treat the src memory as uncompressed, leading to corruption if the memory was compressed by the user. To fix this pass along use_comp_pat into emit_pte() on the src side, to indicate that compression should be considered. v2 (Jonathan): tweak the commit message Fixes: 523f191cc0c7 ("drm/xe/xe_migrate: Handle migration logic for xe2+ dgfx") Signed-off-by: Matthew Auld <matthew.auld(a)intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray(a)intel.com> Cc: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> Cc: Akshata Jahagirdar <akshata.jahagirdar(a)intel.com> Cc: <stable(a)vger.kernel.org> # v6.12+ Reviewed-by: Jonathan Cavitt <jonathan.cavitt(a)intel.com> --- drivers/gpu/drm/xe/xe_migrate.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/xe/xe_migrate.c b/drivers/gpu/drm/xe/xe_migrate.c index 0838582537e8..4e2bdf70eb70 100644 --- a/drivers/gpu/drm/xe/xe_migrate.c +++ b/drivers/gpu/drm/xe/xe_migrate.c @@ -863,7 +863,7 @@ struct dma_fence *xe_migrate_copy(struct xe_migrate *m, if (src_is_vram && xe_migrate_allow_identity(src_L0, &src_it)) xe_res_next(&src_it, src_L0); else - emit_pte(m, bb, src_L0_pt, src_is_vram, copy_system_ccs, + emit_pte(m, bb, src_L0_pt, src_is_vram, copy_system_ccs || use_comp_pat, &src_it, src_L0, src); if (dst_is_vram && xe_migrate_allow_identity(src_L0, &dst_it)) -- 2.50.0

10 hours, 11 minutes

1
0
0 0

[PATCH] x86/mm: Disable hugetlb page table sharing on non-PAE 32-bit

by Jann Horn

Only select ARCH_WANT_HUGE_PMD_SHARE if hugetlb page table sharing is actually possible; page table sharing requires at least three levels, because it involves shared references to PMD tables. Having ARCH_WANT_HUGE_PMD_SHARE enabled on non-PAE 32-bit X86 (which has 2-level paging) became particularly problematic after commit 59d9094df3d7 ("mm: hugetlb: independent PMD page table shared count"), since that changes `struct ptdesc` such that the `pt_mm` (for PGDs) and the `pt_share_count` (for PMDs) share the same union storage - and with 2-level paging, PMDs are PGDs. (For comparison, arm64 also gates ARCH_WANT_HUGE_PMD_SHARE on the configuration of page tables such that it is never enabled with 2-level paging.) Reported-by: Vitaly Chikunov <vt(a)altlinux.org> Closes: https://lore.kernel.org/r/srhpjxlqfna67blvma5frmy3aa@altlinux.org Fixes: cfe28c5d63d8 ("x86: mm: Remove x86 version of huge_pmd_share.") Cc: stable(a)vger.kernel.org Signed-off-by: Jann Horn <jannh(a)google.com> --- arch/x86/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 71019b3b54ea..917f523b994b 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -147,7 +147,7 @@ config X86 select ARCH_WANTS_DYNAMIC_TASK_STRUCT select ARCH_WANTS_NO_INSTR select ARCH_WANT_GENERAL_HUGETLB - select ARCH_WANT_HUGE_PMD_SHARE + select ARCH_WANT_HUGE_PMD_SHARE if PGTABLE_LEVELS > 2 select ARCH_WANT_LD_ORPHAN_WARN select ARCH_WANT_OPTIMIZE_DAX_VMEMMAP if X86_64 select ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP if X86_64 --- base-commit: d0b3b7b22dfa1f4b515fd3a295b3fd958f9e81af change-id: 20250630-x86-2level-hugetlb-b1d8feb255ce -- Jann Horn <jannh(a)google.com>

10 hours, 17 minutes

3
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror July 2025