August 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

1 day, 6 hours

5
18
0 0

[PATCH] perf tools: Fix bool return value in gzip_is_compressed()

by Miaoqian Lin

gzip_is_compressed() returns -1 on error but is declared as bool. And -1 gets converted to true, which could be misleading. Return false instead to match the declared type. Fixes: 88c74dc76a30 ("perf tools: Add gzip_is_compressed function") Cc: <stable(a)vger.kernel.org> Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com> --- tools/perf/util/zlib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/util/zlib.c b/tools/perf/util/zlib.c index 78d2297c1b67..1f7c06523059 100644 --- a/tools/perf/util/zlib.c +++ b/tools/perf/util/zlib.c @@ -88,7 +88,7 @@ bool gzip_is_compressed(const char *input) ssize_t rc; if (fd < 0) - return -1; + return false; rc = read(fd, buf, sizeof(buf)); close(fd); -- 2.39.5 (Apple Git-154)

1 week

4
5
0 0

[PATCH v4 0/2] media: pci: Fix invalid access to file *

by Jacopo Mondi

Since commits 7b9eb53e8591 ("media: cx18: Access v4l2_fh from file") 9ba9d11544f9 ("media: ivtv: Access v4l2_fh from file") All the ioctl handlers access their private data structures from file * The ivtv and cx18 drivers call the ioctl handlers from their DVB layer without a valid file *, causing invalid memory access. The issue has been reported by smatch in "[bug report] media: cx18: Access v4l2_fh from file" Fix this by providing wrappers for the ioctl handlers to be used by the DVB layer that do not require a valid file *. Signed-off-by: Jacopo Mondi <jacopo.mondi(a)ideasonboard.com> --- Changes in v4: - Slightly adjust commit messages - Link to v3: https://lore.kernel.org/r/20250818-cx18-v4l2-fh-v3-0-5e2f08f3cadc@ideasonbo… Changes in v3: - Change helpers to accept the type they're going to operate on instead of using the open_id wrapper type as suggested by Laurent - Link to v2: https://lore.kernel.org/r/20250818-cx18-v4l2-fh-v2-0-3f53ce423663@ideasonbo… Changes in v2: - Add Cc: stable(a)vger.kernel.org per-patch --- Jacopo Mondi (2): media: cx18: Fix invalid access to file * media: ivtv: Fix invalid access to file * drivers/media/pci/cx18/cx18-driver.c | 9 +++------ drivers/media/pci/cx18/cx18-ioctl.c | 30 +++++++++++++++++++----------- drivers/media/pci/cx18/cx18-ioctl.h | 8 +++++--- drivers/media/pci/ivtv/ivtv-driver.c | 11 ++++------- drivers/media/pci/ivtv/ivtv-ioctl.c | 22 +++++++++++++++++----- drivers/media/pci/ivtv/ivtv-ioctl.h | 6 ++++-- 6 files changed, 52 insertions(+), 34 deletions(-) --- base-commit: a75b8d198c55e9eb5feb6f6e155496305caba2dc change-id: 20250818-cx18-v4l2-fh-7eaa6199fdde Best regards, -- Jacopo Mondi <jacopo.mondi(a)ideasonboard.com>

1 week

2
7
0 0

[PATCH] [PATCH v3] perf/x86/amd: check event before enable to avoid GPF

by George Kennedy

On AMD machines cpuc->events[idx] can become NULL in a subtle race condition with NMI->throttle->x86_pmu_stop(). Check event for NULL in amd_pmu_enable_all() before enable to avoid a GPF. This appears to be an AMD only issue. Syzkaller reported a GPF in amd_pmu_enable_all. INFO: NMI handler (perf_event_nmi_handler) took too long to run: 13.143 msecs Oops: general protection fault, probably for non-canonical address 0xdffffc0000000034: 0000 PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x00000000000001a0-0x00000000000001a7] CPU: 0 UID: 0 PID: 328415 Comm: repro_36674776 Not tainted 6.12.0-rc1-syzk RIP: 0010:x86_pmu_enable_event (arch/x86/events/perf_event.h:1195 arch/x86/events/core.c:1430) RSP: 0018:ffff888118009d60 EFLAGS: 00010012 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000034 RSI: 0000000000000000 RDI: 00000000000001a0 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000002 R13: ffff88811802a440 R14: ffff88811802a240 R15: ffff8881132d8601 FS: 00007f097dfaa700(0000) GS:ffff888118000000(0000) GS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200001c0 CR3: 0000000103d56000 CR4: 00000000000006f0 Call Trace: <IRQ> amd_pmu_enable_all (arch/x86/events/amd/core.c:760 (discriminator 2)) x86_pmu_enable (arch/x86/events/core.c:1360) event_sched_out (kernel/events/core.c:1191 kernel/events/core.c:1186 kernel/events/core.c:2346) __perf_remove_from_context (kernel/events/core.c:2435) event_function (kernel/events/core.c:259) remote_function (kernel/events/core.c:92 (discriminator 1) kernel/events/core.c:72 (discriminator 1)) __flush_smp_call_function_queue (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/csd.h:64 kernel/smp.c:135 kernel/smp.c:540) __sysvec_call_function_single (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./arch/x86/include/asm/trace/irq_vectors.h:99 arch/x86/kernel/smp.c:272) sysvec_call_function_single (arch/x86/kernel/smp.c:266 (discriminator 47) arch/x86/kernel/smp.c:266 (discriminator 47)) </IRQ> Reported-by: syzkaller <syzkaller(a)googlegroups.com> Signed-off-by: George Kennedy <george.kennedy(a)oracle.com> --- Suggested comment now with the code. arch/x86/events/amd/core.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/arch/x86/events/amd/core.c b/arch/x86/events/amd/core.c index 920e3a640cad..6615ace15f5d 100644 --- a/arch/x86/events/amd/core.c +++ b/arch/x86/events/amd/core.c @@ -762,7 +762,12 @@ static void amd_pmu_enable_all(int added) if (!test_bit(idx, cpuc->active_mask)) continue; - amd_pmu_enable_event(cpuc->events[idx]); + /* + * FIXME: cpuc->events[idx] can become NULL in a subtle race + * condition with NMI->throttle->x86_pmu_stop(). + */ + if (cpuc->events[idx]) + amd_pmu_enable_event(cpuc->events[idx]); } } -- 2.39.3

1 week

3
2
0 0

[PATCH v2 0/5] rtc: Fix problems with missing UIE irqs

by Esben Haabendal

This fixes a couple of different problems, that can cause RTC (alarm) irqs to be missing when generating UIE interrupts. The first commit fixes a long-standing problem, which has been documented in a comment since 2010. This fixes a race that could cause UIE irqs to stop being generated, which was easily reproduced by timing the use of RTC_UIE_ON ioctl with the seconds tick in the RTC. The last commit ensures that RTC (alarm) irqs are enabled whenever RTC_UIE_ON ioctl is used. The driver specific commits avoids kernel warnings about unbalanced enable_irq/disable_irq, which gets triggered on first RTC_UIE_ON with the last commit. Before this series, the same warning should be seen on initial RTC_AIE_ON with those drivers. Signed-off-by: Esben Haabendal <esben(a)geanix.com> --- Changes in v2: - Dropped patch for rtc-st-lpc driver. - Link to v1: https://lore.kernel.org/r/20241203-rtc-uie-irq-fixes-v1-0-01286ecd9f3f@gean… --- Esben Haabendal (5): rtc: interface: Fix long-standing race when setting alarm rtc: isl12022: Fix initial enable_irq/disable_irq balance rtc: cpcap: Fix initial enable_irq/disable_irq balance rtc: tps6586x: Fix initial enable_irq/disable_irq balance rtc: interface: Ensure alarm irq is enabled when UIE is enabled drivers/rtc/interface.c | 27 +++++++++++++++++++++++++++ drivers/rtc/rtc-cpcap.c | 1 + drivers/rtc/rtc-isl12022.c | 1 + drivers/rtc/rtc-tps6586x.c | 1 + 4 files changed, 30 insertions(+) --- base-commit: 82f2b0b97b36ee3fcddf0f0780a9a0825d52fec3 change-id: 20241203-rtc-uie-irq-fixes-f2838782d0f8 Best regards, -- Esben Haabendal <esben(a)geanix.com>

1 week, 3 days

2
3
0 0

[PATCH] perf lzma: Fix return value in lzma_is_compressed()

by Miaoqian Lin

lzma_is_compressed() returns -1 on error but is declared as bool. And -1 gets converted to true, which could be misleading. Return false instead to match the declared type. Fixes: 4b57fd44b61b ("perf tools: Add lzma_is_compressed function") Cc: <stable(a)vger.kernel.org> Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com> --- tools/perf/util/lzma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/util/lzma.c b/tools/perf/util/lzma.c index bbcd2ffcf4bd..c355757ed391 100644 --- a/tools/perf/util/lzma.c +++ b/tools/perf/util/lzma.c @@ -120,7 +120,7 @@ bool lzma_is_compressed(const char *input) ssize_t rc; if (fd < 0) - return -1; + return false; rc = read(fd, buf, sizeof(buf)); close(fd); -- 2.39.5 (Apple Git-154)

1 week, 3 days

2
1
0 0

Unplayable framerates in game but specific kernel versions work, maybe amdgpu problem

by machion＠disroot.org

Hello kernel/driver developers, I hope, with my information it's possible to find a bug/problem in the kernel. Otherwise I am sorry, that I disturbed you. I only use LTS kernels, but I can narrow it down to a hand full of them, where it works. The PC: Manjaro Stable/Cinnamon/X11/AMD Ryzen 5 2600/Radeon HD 7790/8GB RAM I already asked the Manjaro community, but with no luck. The game: Hellpoint (GOG Linux latest version, Unity3D-Engine v2021), uses vulkan --- I came a long road of kernels. I had many versions of 5.4, 5.10, 5.15, 6.1 and 6.6 and and the game was always unplayable, because the frames where around 1fps (performance of PC is not the problem). I asked the mesa and cinnamon team for help in the past, but also with no luck. It never worked, till on 2025-03-29 when I installed 6.12.19 for the first time and it worked! But it only worked with 6.12.19, 6.12.20 and 6.12.21 When I updated to 6.12.25, it was back to unplayable. For testing I installed 6.14.4 with the same result. It doesn't work. I also compared file /proc/config.gz of both kernels (6.12.21 <> 6.14.4), but can't seem to see drastic changes to the graphical part. I presume it has something to do with amdgpu. If you need more information, I would be happy to help. Kind regards, Marion

1 week, 4 days

2
5
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>

1 week, 4 days

6
22
0 0

[PATCH 6.1.y] spi: microchip-core: ensure TX and RX FIFOs are empty at start of a transfer

by jianqi.ren.cn＠windriver.com

From: Steve Wilkins <steve.wilkins(a)raymarine.com> [ Upstream commit 9cf71eb0faef4bff01df4264841b8465382d7927 ] While transmitting with rx_len == 0, the RX FIFO is not going to be emptied in the interrupt handler. A subsequent transfer could then read crap from the previous transfer out of the RX FIFO into the start RX buffer. The core provides a register that will empty the RX and TX FIFOs, so do that before each transfer. Fixes: 9ac8d17694b6 ("spi: add support for microchip fpga spi controllers") Signed-off-by: Steve Wilkins <steve.wilkins(a)raymarine.com> Signed-off-by: Conor Dooley <conor.dooley(a)microchip.com> Link: https://patch.msgid.link/20240715-flammable-provoke-459226d08e70@wendy Signed-off-by: Mark Brown <broonie(a)kernel.org> [Minor conflict resolved due to code context change.] Signed-off-by: Jianqi Ren <jianqi.ren.cn(a)windriver.com> Signed-off-by: He Zhe <zhe.he(a)windriver.com> --- Verified the build test --- drivers/spi/spi-microchip-core.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/spi/spi-microchip-core.c b/drivers/spi/spi-microchip-core.c index bfad0fe743ad..acc05f5a929e 100644 --- a/drivers/spi/spi-microchip-core.c +++ b/drivers/spi/spi-microchip-core.c @@ -91,6 +91,8 @@ #define REG_CONTROL2 (0x28) #define REG_COMMAND (0x2c) #define COMMAND_CLRFRAMECNT BIT(4) +#define COMMAND_TXFIFORST BIT(3) +#define COMMAND_RXFIFORST BIT(2) #define REG_PKTSIZE (0x30) #define REG_CMD_SIZE (0x34) #define REG_HWSTATUS (0x38) @@ -489,6 +491,8 @@ static int mchp_corespi_transfer_one(struct spi_controller *host, mchp_corespi_set_xfer_size(spi, (spi->tx_len > FIFO_DEPTH) ? FIFO_DEPTH : spi->tx_len); + mchp_corespi_write(spi, REG_COMMAND, COMMAND_RXFIFORST | COMMAND_TXFIFORST); + while (spi->tx_len) mchp_corespi_write_fifo(spi); -- 2.34.1

1 week, 5 days

4
3
0 0

[bp@imp.ch: Bug#1111455: linux-image-6.12.41+deb13-amd64: kernel BUG at fs/netfs/read_collect.c:316 netfs: Can't donate prior to front]

by Salvatore Bonaccorso

Hi, A user in Debian reported the following kernel oops when running on 6.12.41 (but apparently as well on older versions, though there were several netfs related similar issues, so including Max Kellermann as well in the recipients) The report from Benoit Panizzon is as follows: > From: Benoit Panizzon <bp(a)imp.ch> > Resent-From: Benoit Panizzon <bp(a)imp.ch> > Reply-To: Benoit Panizzon <bp(a)imp.ch>, 1111455(a)bugs.debian.org > X-Mailer: reportbug 13.2.0 > Date: Mon, 18 Aug 2025 10:24:32 +0200 > To: Debian Bug Tracking System <submit(a)bugs.debian.org> > Subject: Bug#1111455: linux-image-6.12.41+deb13-amd64: kernel BUG at fs/netfs/read_collect.c:316 netfs: Can't donate > prior to front > Delivered-To: lists-debian-kernel(a)bendel.debian.org > Delivered-To: submit(a)bugs.debian.org > Message-ID: <175550547264.3745.5845128440223069497.reportbug(a)go.imp.ch> > > Package: src:linux > Version: 6.12.41-1 > Severity: grave > Justification: renders package unusable > X-Debbugs-Cc: debian-amd64(a)lists.debian.org > User: debian-amd64(a)lists.debian.org > Usertags: amd64 > > Dear Maintainer, > > Updated my workstation from Bookworm to Trixie. /home on NFS > > Applications accessing data on NFS shares become unresponsive one after the other after a couple of minutes. > > Especially affected: > * Claws-Mail > * Chromium > > Suspected cachefsd being the culpit and disabled - issue persists. > > It looks like an invalid opcode is being used. Fairly recent CPU in use: > > vendor_id : AuthenticAMD > cpu family : 25 > model : 80 > model name : AMD Ryzen 7 PRO 5750GE with Radeon Graphics > stepping : 0 > microcode : 0xa500011 > > Google found reports of others affected with similar kernel versions mostly when accessing SMB shares. > > [Mo Aug 18 10:11:19 2025] netfs: Can't donate prior to front > [Mo Aug 18 10:11:19 2025] R=00001e07[4] s=6000-7fff 0/2000/2000 > [Mo Aug 18 10:11:19 2025] folio: 4000-7fff > [Mo Aug 18 10:11:19 2025] donated: prev=0 next=0 > [Mo Aug 18 10:11:19 2025] s=6000 av=2000 part=2000 > [Mo Aug 18 10:11:19 2025] ------------[ cut here ]------------ > [Mo Aug 18 10:11:19 2025] kernel BUG at fs/netfs/read_collect.c:316! > [Mo Aug 18 10:11:19 2025] Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI > [Mo Aug 18 10:11:19 2025] CPU: 5 UID: 0 PID: 115 Comm: kworker/u64:1 Not tainted 6.12.41+deb13-amd64 #1 Debian 6.12.41-1 > [Mo Aug 18 10:11:19 2025] Hardware name: LENOVO 11JN000JGE/32E4, BIOS M47KT26A 11/23/2022 > [Mo Aug 18 10:11:19 2025] Workqueue: nfsiod rpc_async_release [sunrpc] > [Mo Aug 18 10:11:19 2025] RIP: 0010:netfs_consume_read_data.isra.0+0xb79/0xb80 [netfs] > [Mo Aug 18 10:11:19 2025] Code: 48 89 ea 31 f6 48 c7 c7 96 95 6f c2 e8 d0 8d a2 e1 48 8b 4c 24 10 4c 89 fe 48 8b 54 24 20 48 c7 c7 b2 95 6f c2 e8 b7 8d a2 e1 <0f> 0b 90 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 > [Mo Aug 18 10:11:19 2025] RSP: 0018:ffffb4234057bd58 EFLAGS: 00010246 > [Mo Aug 18 10:11:19 2025] RAX: 0000000000000018 RBX: ffff9aed62651ec0 RCX: 0000000000000027 > [Mo Aug 18 10:11:19 2025] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff9af04e4a1740 > [Mo Aug 18 10:11:19 2025] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffb4234057bbe8 > [Mo Aug 18 10:11:19 2025] R10: ffffffffa50b43a8 R11: 0000000000000003 R12: ffff9aed6c9081e8 > [Mo Aug 18 10:11:19 2025] R13: 0000000000004000 R14: ffff9aed6c9081e8 R15: 0000000000006000 > [Mo Aug 18 10:11:19 2025] FS: 0000000000000000(0000) GS:ffff9af04e480000(0000) knlGS:0000000000000000 > [Mo Aug 18 10:11:19 2025] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [Mo Aug 18 10:11:19 2025] CR2: 00003d3407849020 CR3: 00000002f1822000 CR4: 0000000000f50ef0 > [Mo Aug 18 10:11:19 2025] PKRU: 55555554 > [Mo Aug 18 10:11:19 2025] Call Trace: > [Mo Aug 18 10:11:19 2025] <TASK> > [Mo Aug 18 10:11:19 2025] netfs_read_subreq_terminated+0x2ab/0x3e0 [netfs] > [Mo Aug 18 10:11:19 2025] nfs_netfs_read_completion+0x9c/0xc0 [nfs] > [Mo Aug 18 10:11:19 2025] nfs_read_completion+0xf6/0x130 [nfs] > [Mo Aug 18 10:11:19 2025] rpc_free_task+0x39/0x60 [sunrpc] > [Mo Aug 18 10:11:19 2025] rpc_async_release+0x2f/0x40 [sunrpc] > [Mo Aug 18 10:11:19 2025] process_one_work+0x177/0x330 > [Mo Aug 18 10:11:19 2025] worker_thread+0x251/0x390 > [Mo Aug 18 10:11:19 2025] ? __pfx_worker_thread+0x10/0x10 > [Mo Aug 18 10:11:19 2025] kthread+0xd2/0x100 > [Mo Aug 18 10:11:19 2025] ? __pfx_kthread+0x10/0x10 > [Mo Aug 18 10:11:19 2025] ret_from_fork+0x34/0x50 > [Mo Aug 18 10:11:19 2025] ? __pfx_kthread+0x10/0x10 > [Mo Aug 18 10:11:19 2025] ret_from_fork_asm+0x1a/0x30 > [Mo Aug 18 10:11:19 2025] </TASK> > [Mo Aug 18 10:11:19 2025] Modules linked in: nfsv3 rpcsec_gss_krb5 nfsv4 dns_resolver nfs netfs nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nft_compat nf_tables libcrc32c wireguard libchacha20poly1305 chacha_x86_64 poly1305_x86_64 curve25519_x86_64 libcurve25519_generic libchacha vxlan ip6_udp_tunnel udp_tunnel bridge stp llc btusb btrtl btintel btbcm btmtk bluetooth joydev qrtr nfsd auth_rpcgss binfmt_misc nfs_acl lockd grace nls_ascii nls_cp437 sunrpc vfat fat amd_atl intel_rapl_msr intel_rapl_common rtw88_8822ce rtw88_8822c edac_mce_amd rtw88_pci snd_sof_amd_rembrandt snd_sof_amd_acp rtw88_core kvm_amd snd_sof_pci snd_sof_xtensa_dsp snd_sof snd_hda_codec_realtek mac80211 kvm snd_hda_codec_generic snd_sof_utils snd_hda_scodec_component snd_soc_core snd_hda_codec_hdmi snd_hda_intel snd_compress snd_intel_dspcfg libarc4 snd_pcm_dmaengine irqbypass snd_intel_sdw_acpi snd_pci_ps crct10dif_pclmul snd_hda_codec ghash_clmulni_intel snd_rpl_pci_acp6x cfg80211 snd_hda_core sha512_ssse3 snd_acp_pci > [Mo Aug 18 10:11:19 2025] sha256_ssse3 snd_acp_legacy_common sha1_ssse3 snd_hwdep snd_pci_acp6x aesni_intel snd_pcm gf128mul snd_pci_acp5x crypto_simd think_lmi snd_timer snd_rn_pci_acp3x cryptd firmware_attributes_class snd_acp_config wmi_bmof snd snd_soc_acpi ee1004 rapl snd_pci_acp3x pcspkr ccp k10temp rfkill soundcore evdev parport_pc ppdev lp parport configfs efi_pstore nfnetlink efivarfs ip_tables x_tables autofs4 ext4 mbcache jbd2 crc32c_generic hid_plantronics hid_generic usbhid hid amdgpu dm_mod amdxcp drm_exec gpu_sched drm_buddy i2c_algo_bit drm_suballoc_helper drm_display_helper cec rc_core drm_ttm_helper xhci_pci ttm xhci_hcd drm_kms_helper drm r8169 nvme usbcore realtek sp5100_tco nvme_core mdio_devres watchdog libphy crc32_pclmul i2c_piix4 video crc32c_intel usb_common nvme_auth i2c_smbus crc16 wmi button > [Mo Aug 18 10:11:19 2025] ---[ end trace 0000000000000000 ]--- Any ideas here? Benoit can you please es well test the current 6.16.1 ideally to verify if the problem persists there as well? Regards, Salvatore

2 weeks

2
5
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2025