January 2025 - Linux-stable-mirror

[PATCH 5.4~6.6] MIPS: Probe toolchain support of -msym32

by WangYuli

From: Jiaxun Yang <jiaxun.yang(a)flygoat.com> [ Upstream commit 18ca63a2e23c5e170d2d7552b64b1f5ad019cd9b ] msym32 is not supported by LLVM toolchain. Workaround by probe toolchain support of msym32 for KBUILD_SYM32 feature. Link: https://github.com/ClangBuiltLinux/linux/issues/1544 Signed-off-by: Jiaxun Yang <jiaxun.yang(a)flygoat.com> Signed-off-by: Thomas Bogendoerfer <tsbogend(a)alpha.franken.de> Signed-off-by: WangYuli <wangyuli(a)uniontech.com> --- arch/mips/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/mips/Makefile b/arch/mips/Makefile index f49807e1f19b..0888074f4dfe 100644 --- a/arch/mips/Makefile +++ b/arch/mips/Makefile @@ -299,7 +299,7 @@ drivers-$(CONFIG_PCI) += arch/mips/pci/ ifdef CONFIG_64BIT ifndef KBUILD_SYM32 ifeq ($(shell expr $(load-y) \< 0xffffffff80000000), 0) - KBUILD_SYM32 = y + KBUILD_SYM32 = $(call cc-option-yn, -msym32) endif endif -- 2.47.1

2 days, 14 hours

3
5
0 0

[PATCH net 0/3] mptcp: rx path fixes

by Matthieu Baerts (NGI0)

Here are 3 different fixes, all related to the MPTCP receive buffer: - Patch 1: fix receive buffer space when recvmsg() blocks after receiving some data. For a fix introduced in v6.12, backported to v6.1. - Patch 2: mptcp_cleanup_rbuf() can be called when no data has been copied. For 5.11. - Patch 3: prevent excessive coalescing on receive, which can affect the throughput badly. It looks better to wait a bit before backporting this one to stable versions, to get more results. For 5.10. Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> --- Please note that there is no urgency here as well: this can of course be sent to Linus next year! Enjoy this holiday period! --- Paolo Abeni (3): mptcp: fix recvbuffer adjust on sleeping rcvmsg mptcp: don't always assume copied data in mptcp_cleanup_rbuf() mptcp: prevent excessive coalescing on receive net/mptcp/protocol.c | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-) --- base-commit: a024e377efed31ecfb39210bed562932321345b3 change-id: 20241230-net-mptcp-rbuf-fixes-74526e59d951 Best regards, -- Matthieu Baerts (NGI0) <matttbe(a)kernel.org>

2 days, 17 hours

2
4
0 0

FAILED: patch "[PATCH] selinux: ignore unknown extended permissions" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y git checkout FETCH_HEAD git cherry-pick -x 900f83cf376bdaf798b6f5dcb2eae0c822e908b6 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024122319-risk-starlit-ce4a@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 900f83cf376bdaf798b6f5dcb2eae0c822e908b6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Thi=C3=A9baud=20Weksteen?= <tweek(a)google.com> Date: Thu, 5 Dec 2024 12:09:19 +1100 Subject: [PATCH] selinux: ignore unknown extended permissions MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit When evaluating extended permissions, ignore unknown permissions instead of calling BUG(). This commit ensures that future permissions can be added without interfering with older kernels. Cc: stable(a)vger.kernel.org Fixes: fa1aa143ac4a ("selinux: extended permissions for ioctls") Signed-off-by: Thiébaud Weksteen <tweek(a)google.com> Signed-off-by: Paul Moore <paul(a)paul-moore.com> diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c index 971c45d576ba..3d5c563cfc4c 100644 --- a/security/selinux/ss/services.c +++ b/security/selinux/ss/services.c @@ -979,7 +979,10 @@ void services_compute_xperms_decision(struct extended_perms_decision *xpermd, return; break; default: - BUG(); + pr_warn_once( + "SELinux: unknown extended permission (%u) will be ignored\n", + node->datum.u.xperms->specified); + return; } if (node->key.specified == AVTAB_XPERMS_ALLOWED) { @@ -998,7 +1001,8 @@ void services_compute_xperms_decision(struct extended_perms_decision *xpermd, &node->datum.u.xperms->perms, xpermd->dontaudit); } else { - BUG(); + pr_warn_once("SELinux: unknown specified key (%u)\n", + node->key.specified); } }

2 days, 18 hours

3
2
0 0

[for-linus][PATCH 1/2] fgraph: Add READ_ONCE() when accessing fgraph_array[]

by Steven Rostedt

From: Zilin Guan <zilin(a)seu.edu.cn> In __ftrace_return_to_handler(), a loop iterates over the fgraph_array[] elements, which are fgraph_ops. The loop checks if an element is a fgraph_stub to prevent using a fgraph_stub afterward. However, if the compiler reloads fgraph_array[] after this check, it might race with an update to fgraph_array[] that introduces a fgraph_stub. This could result in the stub being processed, but the stub contains a null "func_hash" field, leading to a NULL pointer dereference. To ensure that the gops compared against the fgraph_stub matches the gops processed later, add a READ_ONCE(). A similar patch appears in commit 63a8dfb ("function_graph: Add READ_ONCE() when accessing fgraph_array[]"). Cc:stable@vger.kernel.org Fixes: 37238abe3cb47 ("ftrace/function_graph: Pass fgraph_ops to function graph callbacks") Link: https://lore.kernel.org/20241231113731.277668-1-zilin@seu.edu.cn Signed-off-by: Zilin Guan <zilin(a)seu.edu.cn> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> --- kernel/trace/fgraph.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/trace/fgraph.c b/kernel/trace/fgraph.c index ddedcb50917f..30e3ddc8a8a8 100644 --- a/kernel/trace/fgraph.c +++ b/kernel/trace/fgraph.c @@ -833,7 +833,7 @@ static unsigned long __ftrace_return_to_handler(struct fgraph_ret_regs *ret_regs #endif { for_each_set_bit(i, &bitmap, sizeof(bitmap) * BITS_PER_BYTE) { - struct fgraph_ops *gops = fgraph_array[i]; + struct fgraph_ops *gops = READ_ONCE(fgraph_array[i]); if (gops == &fgraph_stub) continue; -- 2.45.2

2 days, 20 hours

3
3
0 0

+ fs-proc-do_task_stat-fix-esp-not-readable-during-coredump.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: fs/proc: do_task_stat: fix ESP not readable during coredump has been added to the -mm mm-hotfixes-unstable branch. Its filename is fs-proc-do_task_stat-fix-esp-not-readable-during-coredump.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Nam Cao <namcao(a)linutronix.de> Subject: fs/proc: do_task_stat: fix ESP not readable during coredump Date: Thu, 2 Jan 2025 09:22:56 +0100 The field "eip" (instruction pointer) and "esp" (stack pointer) of a task can be read from /proc/PID/stat. These fields can be interesting for coredump. However, these fields were disabled by commit 0a1eb2d474ed ("fs/proc: Stop reporting eip and esp in /proc/PID/stat"), because it is generally unsafe to do so. But it is safe for a coredumping process, and therefore exceptions were made: - for a coredumping thread by commit fd7d56270b52 ("fs/proc: Report eip/esp in /prod/PID/stat for coredumping"). - for all other threads in a coredumping process by commit cb8f381f1613 ("fs/proc/array.c: allow reporting eip/esp for all coredumping threads"). The above two commits check the PF_DUMPCORE flag to determine a coredump thread and the PF_EXITING flag for the other threads. Unfortunately, commit 92307383082d ("coredump: Don't perform any cleanups before dumping core") moved coredump to happen earlier and before PF_EXITING is set. Thus, checking PF_EXITING is no longer the correct way to determine threads in a coredumping process. Instead of PF_EXITING, use PF_POSTCOREDUMP to determine the other threads. Checking of PF_EXITING was added for coredumping, so it probably can now be removed. But it doesn't hurt to keep. Link: https://lkml.kernel.org/r/d89af63d478d6c64cc46a01420b46fd6eb147d6f.17358057… Fixes: 92307383082d ("coredump: Don't perform any cleanups before dumping core") Signed-off-by: Nam Cao <namcao(a)linutronix.de> Acked-by: Oleg Nesterov <oleg(a)redhat.com> Acked-by: Kees Cook <kees(a)kernel.org> Cc: Eric W. Biederman <ebiederm(a)xmission.com> Cc: Dylan Hatch <dylanbhatch(a)google.com> Cc: John Ogness <john.ogness(a)linutronix.de> Cc: Shuah Khan <shuah(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/proc/array.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/fs/proc/array.c~fs-proc-do_task_stat-fix-esp-not-readable-during-coredump +++ a/fs/proc/array.c @@ -500,7 +500,7 @@ static int do_task_stat(struct seq_file * a program is not able to use ptrace(2) in that case. It is * safe because the task has stopped executing permanently. */ - if (permitted && (task->flags & (PF_EXITING|PF_DUMPCORE))) { + if (permitted && (task->flags & (PF_EXITING|PF_DUMPCORE|PF_POSTCOREDUMP))) { if (try_get_task_stack(task)) { eip = KSTK_EIP(task); esp = KSTK_ESP(task); _ Patches currently in -mm which might be from namcao(a)linutronix.de are fs-proc-do_task_stat-fix-esp-not-readable-during-coredump.patch selftests-coredump-add-stackdump-test.patch

2 days, 21 hours

1
0
0 0

[PATCH v3 0/4] scsi: ufs: qcom: Suspend fixes

by Manivannan Sadhasivam via B4 Relay

Hi, This series fixes the several suspend issues on Qcom platforms. Patch 1 fixes the resume failure with spm_lvl=5 suspend on most of the Qcom platforms. For this patch, I couldn't figure out the exact commit that caused the issue. So I used the commit that introduced reinit support as a placeholder. Patch 4 fixes the suspend issue on SM8550 and SM8650 platforms where UFS PHY retention is not supported. Hence the default spm_lvl=3 suspend fails. So this patch configures spm_lvl=5 as the default suspend level to force UFSHC/ device powerdown during suspend. This supersedes the previous series [1] that tried to fix the issue in clock drivers. This series is tested on Qcom SM8550 QRD, SM8650 QRD and Qcom RB5 boards. [1] https://lore.kernel.org/linux-arm-msm/20241107-ufs-clk-fix-v1-0-6032ff22a05… Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org> --- Changes in v3: - Added a patch that honors the runtime/system PM levels set by host drivers. Otherwise patch 4 doesn't have any effect. This was discovered with SM8650 QRD. - Collected tags - Link to v2: https://lore.kernel.org/r/20241213-ufs-qcom-suspend-fix-v2-0-1de6cd2d6146@l… Changes in v2: - Changed 'ufs_qcom_drvdata::quirks' type to 'enum ufshcd_quirks' - Collected tags - Link to v1: https://lore.kernel.org/r/20241211-ufs-qcom-suspend-fix-v1-0-83ebbde76b1c@l… --- Manivannan Sadhasivam (4): scsi: ufs: qcom: Power off the PHY if it was already powered on in ufs_qcom_power_up_sequence() scsi: ufs: core: Honor runtime/system PM levels if set by host controller drivers scsi: ufs: qcom: Allow passing platform specific OF data scsi: ufs: qcom: Power down the controller/device during system suspend for SM8550/SM8650 SoCs drivers/ufs/core/ufshcd-priv.h | 6 ------ drivers/ufs/core/ufshcd.c | 10 ++++++---- drivers/ufs/host/ufs-qcom.c | 31 +++++++++++++++++++------------ drivers/ufs/host/ufs-qcom.h | 5 +++++ include/ufs/ufshcd.h | 2 -- 5 files changed, 30 insertions(+), 24 deletions(-) --- base-commit: 40384c840ea1944d7c5a392e8975ed088ecf0b37 change-id: 20241211-ufs-qcom-suspend-fix-5618e9c56d93 Best regards, -- Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org>

2 days, 21 hours

3
4
0 0

+ filemap-avoid-truncating-64-bit-offset-to-32-bits.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: filemap: avoid truncating 64-bit offset to 32 bits has been added to the -mm mm-hotfixes-unstable branch. Its filename is filemap-avoid-truncating-64-bit-offset-to-32-bits.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Marco Nelissen <marco.nelissen(a)gmail.com> Subject: filemap: avoid truncating 64-bit offset to 32 bits Date: Thu, 2 Jan 2025 11:04:11 -0800 On 32-bit kernels, folio_seek_hole_data() was inadvertently truncating a 64-bit value to 32 bits, leading to a possible infinite loop when writing to an xfs filesystem. Link: https://lkml.kernel.org/r/20250102190540.1356838-1-marco.nelissen@gmail.com Fixes: 54fa39ac2e00b ("iomap: use mapping_seek_hole_data") Signed-off-by: Marco Nelissen <marco.nelissen(a)gmail.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/filemap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/filemap.c~filemap-avoid-truncating-64-bit-offset-to-32-bits +++ a/mm/filemap.c @@ -2996,7 +2996,7 @@ static inline loff_t folio_seek_hole_dat if (ops->is_partially_uptodate(folio, offset, bsz) == seek_data) break; - start = (start + bsz) & ~(bsz - 1); + start = (start + bsz) & ~((u64)bsz - 1); offset += bsz; } while (offset < folio_size(folio)); unlock: _ Patches currently in -mm which might be from marco.nelissen(a)gmail.com are filemap-avoid-truncating-64-bit-offset-to-32-bits.patch

2 days, 22 hours

1
0
0 0

[for-linus][PATCH 2/2] ftrace: Fix function profilers filtering functionality

by Steven Rostedt

From: Kohei Enju <enjuk(a)amazon.com> Commit c132be2c4fcc ("function_graph: Have the instances use their own ftrace_ops for filtering"), function profiler (enabled via function_profile_enabled) has been showing statistics for all functions, ignoring set_ftrace_filter settings. While tracers are instantiated, the function profiler is not. Therefore, it should use the global set_ftrace_filter for consistency. This patch modifies the function profiler to use the global filter, fixing the filtering functionality. Before (filtering not working): ``` root@localhost:~# echo 'vfs*' > /sys/kernel/tracing/set_ftrace_filter root@localhost:~# echo 1 > /sys/kernel/tracing/function_profile_enabled root@localhost:~# sleep 1 root@localhost:~# echo 0 > /sys/kernel/tracing/function_profile_enabled root@localhost:~# head /sys/kernel/tracing/trace_stat/* Function Hit Time Avg s^2 -------- --- ---- --- --- schedule 314 22290594 us 70989.15 us 40372231 us x64_sys_call 1527 8762510 us 5738.382 us 3414354 us schedule_hrtimeout_range 176 8665356 us 49234.98 us 405618876 us __x64_sys_ppoll 324 5656635 us 17458.75 us 19203976 us do_sys_poll 324 5653747 us 17449.83 us 19214945 us schedule_timeout 67 5531396 us 82558.15 us 2136740827 us __x64_sys_pselect6 12 3029540 us 252461.7 us 63296940171 us do_pselect.constprop.0 12 3029532 us 252461.0 us 63296952931 us ``` After (filtering working): ``` root@localhost:~# echo 'vfs*' > /sys/kernel/tracing/set_ftrace_filter root@localhost:~# echo 1 > /sys/kernel/tracing/function_profile_enabled root@localhost:~# sleep 1 root@localhost:~# echo 0 > /sys/kernel/tracing/function_profile_enabled root@localhost:~# head /sys/kernel/tracing/trace_stat/* Function Hit Time Avg s^2 -------- --- ---- --- --- vfs_write 462 68476.43 us 148.217 us 25874.48 us vfs_read 641 9611.356 us 14.994 us 28868.07 us vfs_fstat 890 878.094 us 0.986 us 1.667 us vfs_fstatat 227 757.176 us 3.335 us 18.928 us vfs_statx 226 610.610 us 2.701 us 17.749 us vfs_getattr_nosec 1187 460.919 us 0.388 us 0.326 us vfs_statx_path 297 343.287 us 1.155 us 11.116 us vfs_rename 6 291.575 us 48.595 us 9889.236 us ``` Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/20250101190820.72534-1-enjuk@amazon.com Fixes: c132be2c4fcc ("function_graph: Have the instances use their own ftrace_ops for filtering") Signed-off-by: Kohei Enju <enjuk(a)amazon.com> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> --- kernel/trace/ftrace.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index 9b17efb1a87d..2e113f8b13a2 100644 --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -902,16 +902,13 @@ static void profile_graph_return(struct ftrace_graph_ret *trace, } static struct fgraph_ops fprofiler_ops = { - .ops = { - .flags = FTRACE_OPS_FL_INITIALIZED, - INIT_OPS_HASH(fprofiler_ops.ops) - }, .entryfunc = &profile_graph_entry, .retfunc = &profile_graph_return, }; static int register_ftrace_profiler(void) { + ftrace_ops_set_global_filter(&fprofiler_ops.ops); return register_ftrace_graph(&fprofiler_ops); } @@ -922,12 +919,11 @@ static void unregister_ftrace_profiler(void) #else static struct ftrace_ops ftrace_profile_ops __read_mostly = { .func = function_profile_call, - .flags = FTRACE_OPS_FL_INITIALIZED, - INIT_OPS_HASH(ftrace_profile_ops) }; static int register_ftrace_profiler(void) { + ftrace_ops_set_global_filter(&ftrace_profile_ops); return register_ftrace_function(&ftrace_profile_ops); } -- 2.45.2

2 days, 22 hours

1
0
0 0

[PATCH net 2/5] gve: guard XDP xmit NDO on existence of xdp queues

by Praveen Kaligineedi

From: Joshua Washington <joshwash(a)google.com> In GVE, dedicated XDP queues only exist when an XDP program is installed and the interface is up. As such, the NDO XDP XMIT callback should return early if either of these conditions are false. In the case of no loaded XDP program, priv->num_xdp_queues=0 which can cause a divide-by-zero error, and in the case of interface down, num_xdp_queues remains untouched to persist XDP queue count for the next interface up, but the TX pointer itself would be NULL. The XDP xmit callback also needs to synchronize with a device transitioning from open to close. This synchronization will happen via the GVE_PRIV_FLAGS_NAPI_ENABLED bit along with a synchronize_net() call, which waits for any RCU critical sections at call-time to complete. Fixes: 39a7f4aa3e4a ("gve: Add XDP REDIRECT support for GQI-QPL format") Cc: stable(a)vger.kernel.org Signed-off-by: Joshua Washington <joshwash(a)google.com> Signed-off-by: Praveen Kaligineedi <pkaligineedi(a)google.com> Reviewed-by: Praveen Kaligineedi <pkaligineedi(a)google.com> Reviewed-by: Shailend Chand <shailend(a)google.com> Reviewed-by: Willem de Bruijn <willemb(a)google.com> --- drivers/net/ethernet/google/gve/gve_main.c | 3 +++ drivers/net/ethernet/google/gve/gve_tx.c | 5 ++++- 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/google/gve/gve_main.c b/drivers/net/ethernet/google/gve/gve_main.c index e171ca248f9a..5d7b0cc59959 100644 --- a/drivers/net/ethernet/google/gve/gve_main.c +++ b/drivers/net/ethernet/google/gve/gve_main.c @@ -1899,6 +1899,9 @@ static void gve_turndown(struct gve_priv *priv) gve_clear_napi_enabled(priv); gve_clear_report_stats(priv); + + /* Make sure that all traffic is finished processing. */ + synchronize_net(); } static void gve_turnup(struct gve_priv *priv) diff --git a/drivers/net/ethernet/google/gve/gve_tx.c b/drivers/net/ethernet/google/gve/gve_tx.c index 83ad278ec91f..852f8c7e39d2 100644 --- a/drivers/net/ethernet/google/gve/gve_tx.c +++ b/drivers/net/ethernet/google/gve/gve_tx.c @@ -837,9 +837,12 @@ int gve_xdp_xmit(struct net_device *dev, int n, struct xdp_frame **frames, struct gve_tx_ring *tx; int i, err = 0, qid; - if (unlikely(flags & ~XDP_XMIT_FLAGS_MASK)) + if (unlikely(flags & ~XDP_XMIT_FLAGS_MASK) || !priv->xdp_prog) return -EINVAL; + if (!gve_get_napi_enabled(priv)) + return -ENETDOWN; + qid = gve_xdp_tx_queue_id(priv, smp_processor_id() % priv->num_xdp_queues); -- 2.47.1.613.gc27f4b7a9f-goog

3 days, 2 hours

3
2
0 0

[REGRESSION] Brightness control does not work after waking up from suspend

by Fernando Ramos

Commit 73dae652dcac776296890da215ee7dec357a1032 (included in 6.13-rc2) was backported to 6.12.5 as 99a02eab82515343d536796aa917dee50aec1551. This causes a problem where brightness control no longer works after waking up from suspend. This is the output of "journalctl -f" when the issue is triggered: > ... > Dec 25 01:37:00 x395 kernel: usb 4-1: reset full-speed USB device number 2 using xhci_hcd > Dec 25 01:37:00 x395 kernel: amdgpu 0000:05:00.0: amdgpu: ring gfx uses VM inv eng 0 on hub 0 > Dec 25 01:37:00 x395 kernel: amdgpu 0000:05:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 1 on hub 0 > Dec 25 01:37:00 x395 kernel: amdgpu 0000:05:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 4 on hub 0 > Dec 25 01:37:00 x395 kernel: amdgpu 0000:05:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 5 on hub 0 > Dec 25 01:37:00 x395 kernel: amdgpu 0000:05:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 6 on hub 0 > Dec 25 01:37:00 x395 kernel: amdgpu 0000:05:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 7 on hub 0 > Dec 25 01:37:00 x395 kernel: amdgpu 0000:05:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 8 on hub 0 > Dec 25 01:37:00 x395 kernel: amdgpu 0000:05:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 9 on hub 0 > Dec 25 01:37:00 x395 kernel: amdgpu 0000:05:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 10 on hub 0 > Dec 25 01:37:00 x395 kernel: amdgpu 0000:05:00.0: amdgpu: ring kiq_0.2.1.0 uses VM inv eng 11 on hub 0 > Dec 25 01:37:00 x395 kernel: amdgpu 0000:05:00.0: amdgpu: ring sdma0 uses VM inv eng 0 on hub 8 > Dec 25 01:37:00 x395 kernel: amdgpu 0000:05:00.0: amdgpu: ring vcn_dec uses VM inv eng 1 on hub 8 > Dec 25 01:37:00 x395 kernel: amdgpu 0000:05:00.0: amdgpu: ring vcn_enc0 uses VM inv eng 4 on hub 8 > Dec 25 01:37:00 x395 kernel: amdgpu 0000:05:00.0: amdgpu: ring vcn_enc1 uses VM inv eng 5 on hub 8 > Dec 25 01:37:00 x395 kernel: amdgpu 0000:05:00.0: amdgpu: ring jpeg_dec uses VM inv eng 6 on hub 8 > Dec 25 01:37:00 x395 kernel: irq 7: nobody cared (try booting with the "irqpoll" option) > Dec 25 01:37:00 x395 kernel: CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.7-rc1-gc157915828d8 #7 14cb019df871d9dae96d82113f6abf187f110b68 > Dec 25 01:37:00 x395 kernel: Hardware name: LENOVO 20NLCTO1WW/20NLCTO1WW, BIOS R13ET50W(1.24 ) 06/11/2021 > Dec 25 01:37:00 x395 kernel: Call Trace: > Dec 25 01:37:00 x395 kernel: <IRQ> > Dec 25 01:37:00 x395 kernel: dump_stack_lvl+0x5d/0x80 > Dec 25 01:37:00 x395 kernel: __report_bad_irq+0x35/0xa7 > Dec 25 01:37:00 x395 kernel: note_interrupt.cold+0xa/0x62 > Dec 25 01:37:00 x395 kernel: handle_irq_event+0x6f/0x80 > Dec 25 01:37:00 x395 kernel: handle_fasteoi_irq+0x78/0x200 > Dec 25 01:37:00 x395 kernel: __common_interrupt+0x3e/0x90 > Dec 25 01:37:00 x395 kernel: common_interrupt+0x42/0xa0 > Dec 25 01:37:00 x395 kernel: asm_common_interrupt+0x26/0x40 > Dec 25 01:37:00 x395 kernel: RIP: 0010:tmigr_handle_remote+0x87/0x470 > Dec 25 01:37:00 x395 kernel: Code: 24 04 00 0f 84 ac 00 00 00 48 b9 ff ff ff ff ff ff ff 7f 41 0f b6 54 24 10 48 89 4c 24 38 88 54 24 48 49 8b 44 24 08 8b 40 50 <0f> b6 c4 38 c2 74 0e 3c ff 74 0a 49 8b 44 24 18 48 39 c8 74 76 48 > Dec 25 01:37:00 x395 kernel: RSP: 0018:ffffafe000003ea8 EFLAGS: 00000202 > Dec 25 01:37:00 x395 kernel: RAX: 000000003de00141 RBX: 0000000000000002 RCX: 7fffffffffffffff > Dec 25 01:37:00 x395 kernel: RDX: 0000000000000001 RSI: ffffafe000003ed8 RDI: ffffafe000003f10 > Dec 25 01:37:00 x395 kernel: RBP: 0000000000000101 R08: f1c92dc141c95fb9 R09: 263db225b099c5f2 > Dec 25 01:37:00 x395 kernel: R10: f1c92dc141c95fb9 R11: 263db225b099c5f2 R12: ffff989030a26300 > Dec 25 01:37:00 x395 kernel: R13: 0000000000000001 R14: 0000000000000282 R15: 0000000000000001 > Dec 25 01:37:00 x395 kernel: ? srso_return_thunk+0x5/0x5f > Dec 25 01:37:00 x395 kernel: ? __run_timers+0x1fc/0x280 > Dec 25 01:37:00 x395 kernel: handle_softirqs+0xe4/0x2a0 > Dec 25 01:37:00 x395 kernel: __irq_exit_rcu+0x97/0xb0 > Dec 25 01:37:00 x395 kernel: sysvec_apic_timer_interrupt+0x71/0x90 > Dec 25 01:37:00 x395 kernel: </IRQ> > Dec 25 01:37:00 x395 kernel: <TASK> > Dec 25 01:37:00 x395 kernel: asm_sysvec_apic_timer_interrupt+0x1a/0x20 > Dec 25 01:37:00 x395 kernel: RIP: 0010:tick_nohz_idle_enter+0x59/0x70 > Dec 25 01:37:00 x395 kernel: Code: 02 00 01 83 45 7c 01 e8 05 c9 fe ff 48 89 85 80 00 00 00 48 83 8b 00 62 02 00 04 83 45 7c 01 e8 3d 93 f8 ff fb 0f 1f 44 00 00 <5b> 5d e9 10 d1 c8 00 0f 0b eb c6 66 66 2e 0f 1f 84 00 00 00 00 00 > Dec 25 01:37:00 x395 kernel: RSP: 0018:ffffffffa1c03e68 EFLAGS: 00000282 > Dec 25 01:37:00 x395 kernel: RAX: 0000000874467ae1 RBX: ffff989030a00000 RCX: 0000000874467ae1 > Dec 25 01:37:00 x395 kernel: RDX: 0000000874467ae1 RSI: 0000000000001d53 RDI: 0000000874467ae1 > Dec 25 01:37:00 x395 kernel: RBP: ffff989030a26200 R08: 0000000000000002 R09: 0000000000000000 > Dec 25 01:37:00 x395 kernel: R10: 0000000000000001 R11: 0000000000000000 R12: ffff98903efc9ff4 > Dec 25 01:37:00 x395 kernel: R13: 0000000000000000 R14: ffffffffa1c10038 R15: 00000000aafaf000 > Dec 25 01:37:00 x395 kernel: ? tick_nohz_idle_enter+0x53/0x70 > Dec 25 01:37:00 x395 kernel: do_idle+0x3f/0x210 > Dec 25 01:37:00 x395 kernel: cpu_startup_entry+0x29/0x30 > Dec 25 01:37:00 x395 kernel: rest_init+0xcc/0xd0 > Dec 25 01:37:00 x395 kernel: start_kernel+0x9be/0x9c0 > Dec 25 01:37:00 x395 kernel: x86_64_start_reservations+0x24/0x30 > Dec 25 01:37:00 x395 kernel: x86_64_start_kernel+0x95/0xa0 > Dec 25 01:37:00 x395 kernel: common_startup_64+0x13e/0x141 > Dec 25 01:37:00 x395 kernel: </TASK> > Dec 25 01:37:00 x395 kernel: handlers: > Dec 25 01:37:00 x395 kernel: [<00000000d69cbeca>] amd_gpio_irq_handler > Dec 25 01:37:00 x395 kernel: Disabling IRQ #7 > Dec 25 01:37:00 x395 kernel: usb 4-2: reset high-speed USB device number 3 using xhci_hcd > Dec 25 01:37:01 x395 kernel: usb 4-2.1: reset high-speed USB device number 4 using xhci_hcd > Dec 25 01:37:01 x395 kernel: OOM killer enabled. > Dec 25 01:37:01 x395 kernel: Restarting tasks ... > Dec 25 01:37:01 x395 kernel: usb 4-2.2: USB disconnect, device number 5 > Dec 25 01:37:01 x395 kernel: done. > ... The problem only happens in the stable branch (v6.12.y) and not in the main branch. More specifically: Version Problem present ================================================================= v6.12.5 Yes !! v6.12.5 + revert 99a02eab No v6.12.7-rc1 (c157915828d) Yes !! v6.12.7-rc1 (c157915828d) + revert 99a02eab No v6.13-rc4 No

3 days, 2 hours

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror January 2025