September 2025 - Linux-stable-mirror

Bug: Performance regression in 1013af4f585f: mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race

by Uschakow, Stanislav

Hello. We have observed a huge latency increase using `fork()` after ingesting the CVE-2025-38085 fix which leads to the commit `1013af4f585f: mm/hugetlb: fix huge_pmd_unshare() vs GUP-fast race`. On large machines with 1.5TB of memory with 196 cores, we identified mmapping of 1.2TB of shared memory and forking itself dozens or hundreds of times we see a increase of execution times of a factor of 4. The reproducer is at the end of the email. Comparing the a kernel without this patch with a kernel with this patch applied when spawning 1000 children we see those execution times: Patched kernel: $ time make stress ... real 0m11.275s user 0m0.177s sys 0m23.905s Original kernel : $ time make stress ...real 0m2.475s user 0m1.398s sys 0m2.501s The patch in question: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… My observation/assumption is: each child touches 100 random pages and despawns on each despawn `huge_pmd_unshare()` is called each call to `huge_pmd_unshare()` syncrhonizes all threads using `tlb_remove_table_sync_one()` leading to the regression I'm happy to provide more information. Thank you Stanislav Uschakow === Reproducer === Setup: #!/bin/bash echo "Setting up hugepages for reproduction..." # hugepages (1.2TB / 2MB = 614400 pages) REQUIRED_PAGES=614400 # Check current hugepage allocation CURRENT_PAGES=$(cat /proc/sys/vm/nr_hugepages) echo "Current hugepages: $CURRENT_PAGES" if [ "$CURRENT_PAGES" -lt "$REQUIRED_PAGES" ]; then echo "Allocating $REQUIRED_PAGES hugepages..." echo $REQUIRED_PAGES | sudo tee /proc/sys/vm/nr_hugepages ALLOCATED=$(cat /proc/sys/vm/nr_hugepages) echo "Allocated hugepages: $ALLOCATED" if [ "$ALLOCATED" -lt "$REQUIRED_PAGES" ]; then echo "Warning: Could not allocate all required hugepages" echo "Available: $ALLOCATED, Required: $REQUIRED_PAGES" fi fi echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled echo -e "\nHugepage information:" cat /proc/meminfo | grep -i huge echo -e "\nSetup complete. You can now run the reproduction test." Makefile: CXX = gcc CXXFLAGS = -O2 -Wall TARGET = hugepage_repro SOURCE = hugepage_repro.c $(TARGET): $(SOURCE) $(CXX) $(CXXFLAGS) -o $(TARGET) $(SOURCE) clean: rm -f $(TARGET) setup: chmod +x setup_hugepages.sh ./setup_hugepages.sh test: $(TARGET) ./$(TARGET) 20 3 stress: $(TARGET) ./$(TARGET) 1000 1 .PHONY: clean setup test stress hugepage_repro.c: #include <sys/mman.h> #include <sys/wait.h> #include <unistd.h> #include <stdlib.h> #include <string.h> #include <time.h> #include <stdio.h> #define HUGEPAGE_SIZE (2 * 1024 * 1024) // 2MB #define TOTAL_SIZE (1200ULL * 1024 * 1024 * 1024) // 1.2TB #define NUM_HUGEPAGES (TOTAL_SIZE / HUGEPAGE_SIZE) void* create_hugepage_mapping() { void* addr = mmap(NULL, TOTAL_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_ANONYMOUS | MAP_HUGETLB, -1, 0); if (addr == MAP_FAILED) { perror("mmap hugepages failed"); exit(1); } return addr; } void touch_random_pages(void* addr, int num_touches) { char* base = (char*)addr; for (int i = 0; i < num_touches; ++i) { size_t offset = (rand() % NUM_HUGEPAGES) * HUGEPAGE_SIZE; volatile char val = base[offset]; (void)val; } } void child_process(void* shared_mem, int child_id) { struct timespec start, end; clock_gettime(CLOCK_MONOTONIC, &start); touch_random_pages(shared_mem, 100); clock_gettime(CLOCK_MONOTONIC, &end); long duration = (end.tv_sec - start.tv_sec) * 1000000 + (end.tv_nsec - start.tv_nsec) / 1000; printf("Child %d completed in %ld μs\n", child_id, duration); } int main(int argc, char* argv[]) { int num_processes = argc > 1 ? atoi(argv[1]) : 50; int iterations = argc > 2 ? atoi(argv[2]) : 5; printf("Creating %lluGB hugepage mapping...\n", TOTAL_SIZE / (1024*1024*1024)); void* shared_mem = create_hugepage_mapping(); for (int iter = 0; iter < iterations; ++iter) { printf("\nIteration %d: Forking %d processes\n", iter + 1, num_processes); pid_t children[num_processes]; struct timespec iter_start, iter_end; clock_gettime(CLOCK_MONOTONIC, &iter_start); for (int i = 0; i < num_processes; ++i) { pid_t pid = fork(); if (pid == 0) { child_process(shared_mem, i); exit(0); } else if (pid > 0) { children[i] = pid; } } for (int i = 0; i < num_processes; ++i) { waitpid(children[i], NULL, 0); } clock_gettime(CLOCK_MONOTONIC, &iter_end); long iter_duration = (iter_end.tv_sec - iter_start.tv_sec) * 1000 + (iter_end.tv_nsec - iter_start.tv_nsec) / 1000000; printf("Iteration completed in %ld ms\n", iter_duration); } munmap(shared_mem, TOTAL_SIZE); return 0; } Amazon Web Services Development Center Germany GmbH Tamara-Danz-Str. 13 10243 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B Sitz: Berlin Ust-ID: DE 365 538 597

14 hours, 12 minutes

5
27
0 0

[PATCH] x86/fpu: Ensure XFD state on signal delivery

by Chang S. Bae

Sean reported [1] the following splat when running KVM tests: WARNING: CPU: 232 PID: 15391 at xfd_validate_state+0x65/0x70 Call Trace: <TASK> fpu__clear_user_states+0x9c/0x100 arch_do_signal_or_restart+0x142/0x210 exit_to_user_mode_loop+0x55/0x100 do_syscall_64+0x205/0x2c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Chao further identified [2] a reproducible scenarios involving signal delivery: a non-AMX task is preempted by an AMX-enabled task which modifies the XFD MSR. When the non-AMX task resumes and reloads XSTATE with init values, a warning is triggered due to a mismatch between fpstate::xfd and the CPU's current XFD state. fpu__clear_user_states() does not currently re-synchronize the XFD state after such preemption. Invoke xfd_update_state() which detects and corrects the mismatch if the dynamic feature is enabled. This also benefits the sigreturn path, as fpu__restore_sig() may call fpu__clear_user_states() when the sigframe is inaccessible. Fixes: 672365477ae8a ("x86/fpu: Update XFD state where required") Reported-by: Sean Christopherson <seanjc(a)google.com> Closes: https://lore.kernel.org/lkml/aDCo_SczQOUaB2rS@google.com [1] Tested-by: Chao Gao <chao.gao(a)intel.com> Signed-off-by: Chang S. Bae <chang.seok.bae(a)intel.com> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/all/aDWbctO%2FRfTGiCg3@intel.com [2] --- arch/x86/kernel/fpu/core.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c index ea138583dd92..5fa782a2ae7c 100644 --- a/arch/x86/kernel/fpu/core.c +++ b/arch/x86/kernel/fpu/core.c @@ -800,6 +800,9 @@ void fpu__clear_user_states(struct fpu *fpu) !fpregs_state_valid(fpu, smp_processor_id())) os_xrstor_supervisor(fpu->fpstate); + /* Ensure XFD state is in sync before reloading XSTATE */ + xfd_update_state(fpu->fpstate); + /* Reset user states in registers. */ restore_fpregs_from_init_fpstate(XFEATURE_MASK_USER_RESTORE); -- 2.48.1

1 day, 14 hours

3
2
0 0

[PATCH v2] PCI: xilinx-xdma: Enable INTx interrupts

by Ravi Kumar Bandi

The pcie-xilinx-dma-pl driver does not enable INTx interrupts after initializing the port, preventing INTx interrupts from PCIe endpoints from flowing through the Xilinx XDMA root port bridge. This issue affects kernel 6.6.0 and later versions. This patch allows INTx interrupts generated by PCIe endpoints to flow through the root port. Tested the fix on a board with two endpoints generating INTx interrupts. Interrupts are properly detected and serviced. The /proc/interrupts output shows: [...] 32: 320 0 pl_dma:RC-Event 16 Level 400000000.axi-pcie, azdrv 52: 470 0 pl_dma:RC-Event 16 Level 500000000.axi-pcie, azdrv [...] Changes since v1:: - Fixed commit message per reviewer's comments Fixes: 8d786149d78c ("PCI: xilinx-xdma: Add Xilinx XDMA Root Port driver") Cc: stable(a)vger.kernel.org Signed-off-by: Ravi Kumar Bandi <ravib(a)amazon.com> --- drivers/pci/controller/pcie-xilinx-dma-pl.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/pci/controller/pcie-xilinx-dma-pl.c b/drivers/pci/controller/pcie-xilinx-dma-pl.c index b037c8f315e4..cc539292d10a 100644 --- a/drivers/pci/controller/pcie-xilinx-dma-pl.c +++ b/drivers/pci/controller/pcie-xilinx-dma-pl.c @@ -659,6 +659,12 @@ static int xilinx_pl_dma_pcie_setup_irq(struct pl_dma_pcie *port) return err; } + /* Enable interrupts */ + pcie_write(port, XILINX_PCIE_DMA_IMR_ALL_MASK, + XILINX_PCIE_DMA_REG_IMR); + pcie_write(port, XILINX_PCIE_DMA_IDRN_MASK, + XILINX_PCIE_DMA_REG_IDRN_MASK); + return 0; } -- 2.47.3

2 days, 7 hours

8
31
0 0

[PATCH 0/4] drm/tidss: Fixes data edge sampling

by Louis Chauvet

Currently the driver only configure the data edge sampling partially. The AM62 require it to be configured in two distincts registers: one in tidss and one in the general device registers. Introduce a new dt property to link the proper syscon node from the main device registers into the tidss driver. Fixes: 32a1795f57ee ("drm/tidss: New driver for TI Keystone platform Display SubSystem") --- Cc: stable(a)vger.kernel.org Signed-off-by: Louis Chauvet <louis.chauvet(a)bootlin.com> --- Louis Chauvet (4): dt-bindings: display: ti,am65x-dss: Add clk property for data edge synchronization dt-bindings: mfd: syscon: Add ti,am625-dss-clk-ctrl arm64: dts: ti: k3-am62-main: Add tidss clk-ctrl property drm/tidss: Fix sampling edge configuration .../devicetree/bindings/display/ti/ti,am65x-dss.yaml | 6 ++++++ Documentation/devicetree/bindings/mfd/syscon.yaml | 3 ++- arch/arm64/boot/dts/ti/k3-am62-main.dtsi | 6 ++++++ drivers/gpu/drm/tidss/tidss_dispc.c | 14 ++++++++++++++ 4 files changed, 28 insertions(+), 1 deletion(-) --- base-commit: 85c23f28905cf20a86ceec3cfd7a0a5572c9eb13 change-id: 20250730-fix-edge-handling-9123f7438910 Best regards, -- Louis Chauvet <louis.chauvet(a)bootlin.com>

2 days, 14 hours

6
23
0 0

[PATCH] iommu/amd: Fix pci_segment memleak in alloc_pci_segment()

by Jinhui Guo

Fix a memory leak of struct amd_iommu_pci_segment in alloc_pci_segment() when system memory (or contiguous memory) is insufficient. Fixes: 04230c119930 ("iommu/amd: Introduce per PCI segment device table") Fixes: eda797a27795 ("iommu/amd: Introduce per PCI segment rlookup table") Fixes: 99fc4ac3d297 ("iommu/amd: Introduce per PCI segment alias_table") Cc: stable(a)vger.kernel.org Signed-off-by: Jinhui Guo <guojinhui.liam(a)bytedance.com> --- drivers/iommu/amd/init.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c index ba9e582a8bbe..77afd5884984 100644 --- a/drivers/iommu/amd/init.c +++ b/drivers/iommu/amd/init.c @@ -1608,13 +1608,22 @@ static struct amd_iommu_pci_seg *__init alloc_pci_segment(u16 id, list_add_tail(&pci_seg->list, &amd_iommu_pci_seg_list); if (alloc_dev_table(pci_seg)) - return NULL; + goto err_free_pci_seg; if (alloc_alias_table(pci_seg)) - return NULL; + goto err_free_dev_table; if (alloc_rlookup_table(pci_seg)) - return NULL; + goto err_free_alias_table; return pci_seg; + +err_free_alias_table: + free_alias_table(pci_seg); +err_free_dev_table: + free_dev_table(pci_seg); +err_free_pci_seg: + list_del(&pci_seg->list); + kfree(pci_seg); + return NULL; } static struct amd_iommu_pci_seg *__init get_pci_segment(u16 id, -- 2.20.1

2 days, 15 hours

1
1
0 0

[PATCH] media: c8sectpfe: fix probe device leaks

by Johan Hovold

Make sure to drop the references taken to the I2C adapters during probe on probe failure (e.g. probe deferral) and on driver unbind. Fixes: c5f5d0f99794 ("[media] c8sectpfe: STiH407/10 Linux DVB demux support") Cc: stable(a)vger.kernel.org # 4.3 Cc: Peter Griffin <peter.griffin(a)linaro.org> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- .../media/platform/st/sti/c8sectpfe/c8sectpfe-core.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/media/platform/st/sti/c8sectpfe/c8sectpfe-core.c b/drivers/media/platform/st/sti/c8sectpfe/c8sectpfe-core.c index 89bd15a4d26a..3f94d9b4ef1e 100644 --- a/drivers/media/platform/st/sti/c8sectpfe/c8sectpfe-core.c +++ b/drivers/media/platform/st/sti/c8sectpfe/c8sectpfe-core.c @@ -655,6 +655,13 @@ static irqreturn_t c8sectpfe_error_irq_handler(int irq, void *priv) return IRQ_HANDLED; } +static void c8sectpfe_put_device(void *_dev) +{ + struct device *dev = _dev; + + put_device(dev); +} + static int c8sectpfe_probe(struct platform_device *pdev) { struct device *dev = &pdev->dev; @@ -799,6 +806,11 @@ static int c8sectpfe_probe(struct platform_device *pdev) return -ENODEV; } + ret = devm_add_action_or_reset(dev, c8sectpfe_put_device, + &tsin->i2c_adapter->dev); + if (ret) + return ret; + /* Acquire reset GPIO and activate it */ tsin->rst_gpio = devm_fwnode_gpiod_get(dev, of_fwnode_handle(child), -- 2.49.1

2 days, 16 hours

3
4
0 0

[PATCH 0/2] drm/xe: Fix some rebar issues

by Lucas De Marchi

Our implementation for BAR2 (lmembar) resize works at the xe_vram layer and only releases that BAR before resizing. That is not always sufficient. If the parent bridge needs to move, the BAR0 also needs to be released, otherwise the resize fails. This is the case of not having enough space allocated from the beginning. Also, there's a BAR0 in the upstream port of the pcie switch in BMG preventing the resize to propagate to the bridge as previously discussed in https://lore.kernel.org/intel-xe/20250721173057.867829-1-uwu@icenowy.me/ and https://lore.kernel.org/intel-xe/wqukxnxni2dbpdhri3cbvlrzsefgdanesgskzmxi5s… I'm bringing that commit from Ilpo here so this can be tested with the xe changes and propagate to stable. Note that the use of a pci fixup is not ideal, but without intrusive changes on resource fitting it's possibly the best alternative. I also have confirmation from HW folks that the BAR in the upstream port has no production use. I have more cleanups on top on the xe side, but those conflict with some refactors Ilpo is working on as prep for the resource fitting, so I will wait things settle to submit again. I propose to take this through the drm tree. With this I could resize the lmembar on some problematic hosts and after doing an SBR, with one caveat: the audio device also prevents the BAR from moving and it needs to be manually removed before resizing. With the PCI refactors and BAR fitting logic that Ilpo is working on, it's expected that it won't be needed for a long time. Signed-off-by: Lucas De Marchi <lucas.demarchi(a)intel.com> --- Ilpo Järvinen (1): PCI: Release BAR0 of an integrated bridge to allow GPU BAR resize Lucas De Marchi (1): drm/xe: Move rebar to be done earlier drivers/gpu/drm/xe/xe_pci.c | 2 ++ drivers/gpu/drm/xe/xe_vram.c | 34 ++++++++++++++++++++++++++-------- drivers/gpu/drm/xe/xe_vram.h | 1 + drivers/pci/quirks.c | 23 +++++++++++++++++++++++ 4 files changed, 52 insertions(+), 8 deletions(-) base-commit: 8031d70dbb4201841897de480cec1f9750d4a5dc change-id: 20250917-xe-pci-rebar-2-c0fe2f04c879 Lucas De Marchi

2 days, 17 hours

3
9
0 0

[PATCH 0/2] Kconfig fixes for QCOM clk drivers when targeting ARCH=arm

by Nathan Chancellor

Hi all, This series resolves two new Kconfig warnings that I see in my test framework from an ARM configuration getting bumped to 6.17 and enabling these configurations in the process. --- Nathan Chancellor (2): clk: qcom: Fix SM_VIDEOCC_6350 dependencies clk: qcom: Fix dependencies of QCS_{DISP,GPU,VIDEO}CC_615 drivers/clk/qcom/Kconfig | 4 ++++ 1 file changed, 4 insertions(+) --- base-commit: 30bf3ec8cb6b2d2e2f8715388395cbd27cbe4fc9 change-id: 20250930-clk-qcom-kconfig-fixes-arm-3611dec03c3e Best regards, -- Nathan Chancellor <nathan(a)kernel.org>

2 days, 18 hours

4
7
0 0

[PATCH] drm/imx/tve: fix probe device leak

by Johan Hovold

Make sure to drop the reference taken to the DDC device during probe on probe failure (e.g. probe deferral) and on driver unbind. Fixes: fcbc51e54d2a ("staging: drm/imx: Add support for Television Encoder (TVEv2)") Cc: stable(a)vger.kernel.org # 3.10 Cc: Philipp Zabel <p.zabel(a)pengutronix.de> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/gpu/drm/imx/ipuv3/imx-tve.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/gpu/drm/imx/ipuv3/imx-tve.c b/drivers/gpu/drm/imx/ipuv3/imx-tve.c index c5629e155d25..895413d26113 100644 --- a/drivers/gpu/drm/imx/ipuv3/imx-tve.c +++ b/drivers/gpu/drm/imx/ipuv3/imx-tve.c @@ -525,6 +525,13 @@ static const struct component_ops imx_tve_ops = { .bind = imx_tve_bind, }; +static void imx_tve_put_device(void *_dev) +{ + struct device *dev = _dev; + + put_device(dev); +} + static int imx_tve_probe(struct platform_device *pdev) { struct device *dev = &pdev->dev; @@ -546,6 +553,11 @@ static int imx_tve_probe(struct platform_device *pdev) if (ddc_node) { tve->ddc = of_find_i2c_adapter_by_node(ddc_node); of_node_put(ddc_node); + + ret = devm_add_action_or_reset(dev, imx_tve_put_device, + &tve->ddc->dev); + if (ret) + return ret; } tve->mode = of_get_tve_mode(np); -- 2.49.1

2 days, 18 hours

2
2
0 0

[PATCH] drm: sti: fix device leaks at component probe

by Johan Hovold

Make sure to drop the references taken to the vtg devices by of_find_device_by_node() when looking up their driver data during component probe. Note that holding a reference to a platform device does not prevent its driver data from going away so there is no point in keeping the reference after the lookup helper returns. Fixes: cc6b741c6f63 ("drm: sti: remove useless fields from vtg structure") Cc: stable(a)vger.kernel.org # 4.16 Cc: Benjamin Gaignard <benjamin.gaignard(a)collabora.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/gpu/drm/sti/sti_vtg.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/sti/sti_vtg.c b/drivers/gpu/drm/sti/sti_vtg.c index ee81691b3203..ce6bc7e7b135 100644 --- a/drivers/gpu/drm/sti/sti_vtg.c +++ b/drivers/gpu/drm/sti/sti_vtg.c @@ -143,12 +143,17 @@ struct sti_vtg { struct sti_vtg *of_vtg_find(struct device_node *np) { struct platform_device *pdev; + struct sti_vtg *vtg; pdev = of_find_device_by_node(np); if (!pdev) return NULL; - return (struct sti_vtg *)platform_get_drvdata(pdev); + vtg = platform_get_drvdata(pdev); + + put_device(&pdev->dev); + + return vtg; } static void vtg_reset(struct sti_vtg *vtg) -- 2.49.1

2 days, 18 hours

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror September 2025