kernel/linux.git, branch v6.12.69

Linux 6.12.69

2026-02-06T15:55:51+00:00

Link: https://lore.kernel.org/r/20260204143846.906385641@linuxfoundation.org Tested-by: Brett A C Sheffield Tested-by: Salvatore Bonaccorso Tested-by: Florian Fainelli Tested-by: Jon Hunter Tested-by: Peter Schneider Tested-by: Ron Economos Tested-by: Francesco Dolcini Tested-by: Harshit Mogalapalli Tested-by: Mark Brown Tested-by: Brett Mastbergen Tested-by: Hardik Garg Tested-by: Shung-Hsi Yu Tested-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman

bpf/selftests: test_select_reuseport_kern: Remove unused header

2026-02-06T15:55:51+00:00

commit 93cf4e537ed0c5bd9ba6cbdb2c33864547c1442f upstream. test_select_reuseport_kern.c is currently including , but it does not use any definition from there. Remove stdlib.h inclusion from test_select_reuseport_kern.c Signed-off-by: Alexis Lothoré (eBPF Foundation) Signed-off-by: Martin KaFai Lau Link: https://patch.msgid.link/20250227-remove_wrong_header-v1-1-bc94eb4e2f73@bootlin.com Signed-off-by: Alexei Starovoitov [shung-hsi.yu: Fix compilation error mentioned in footer of Alexis' patch with newer glibc header: [...] CLNG-BPF [test_progs-cpuv4] test_select_reuseport_kern.bpf.o In file included from progs/test_select_reuseport_kern.c:4: /usr/include/bits/floatn.h:83:52: error: unsupported machine mode '__TC__' 83 | typedef _Complex float __cfloat128 __attribute__ ((__mode__ (__TC__))); | ^ /usr/include/bits/floatn.h:97:9: error: __float128 is not supported on this target 97 | typedef __float128 _Float128; I'm not certain when the problem starts to occur, but I'm quite sure test_select_reuseport_kern.c were not meant to be using the C standard library in the first place.] Signed-off-by: Shung-Hsi Yu Signed-off-by: Greg Kroah-Hartman

RDMA/mana_ib: Handle net event for pointing to the current netdev

2026-02-06T15:55:51+00:00

commit bee35b7161aaaed9831e2f14876c374b9c566952 upstream. When running under Hyper-V, the master device to the RDMA device is always bonded to this RDMA device. This is not user-configurable. The master device can be unbind/bind from the kernel. During those events, the RDMA device should set to the current netdev to reflect the change of master device from those events. Signed-off-by: Long Li Link: https://patch.msgid.link/1741821332-9392-2-git-send-email-longli@linuxonhyperv.com Signed-off-by: Leon Romanovsky Fixes: 1df03a4b4414 ("RDMA/mana_ib: Set correct device into ib") Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman

net: mana: Change the function signature of mana_get_primary_netdev_rcu

2026-02-06T15:55:51+00:00

commit a8445cfec101c42e9d64cdb2dac13973b22c205c upstream. Change mana_get_primary_netdev_rcu() to mana_get_primary_netdev(), and return the ndev with refcount held. The caller is responsible for dropping the refcount. Also drop the check for IFF_SLAVE as it is not necessary if the upper device is present. Signed-off-by: Long Li Link: https://patch.msgid.link/1741821332-9392-1-git-send-email-longli@linuxonhyperv.com Signed-off-by: Leon Romanovsky Fixes: 1df03a4b4414 ("RDMA/mana_ib: Set correct device into ib") Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman

pinctrl: lpass-lpi: implement .get_direction() for the GPIO driver

2026-02-06T15:55:51+00:00

[ Upstream commit 4f0d22ec60cee420125f4055af76caa0f373a3fe ] GPIO controller driver should typically implement the .get_direction() callback as GPIOLIB internals may try to use it to determine the state of a pin. Add it for the LPASS LPI driver. Reported-by: Abel Vesa Cc: stable@vger.kernel.org Fixes: 6e261d1090d6 ("pinctrl: qcom: Add sm8250 lpass lpi pinctrl driver") Signed-off-by: Bartosz Golaszewski Reviewed-by: Konrad Dybcio Tested-by: Konrad Dybcio # X1E CRD Tested-by: Abel Vesa Signed-off-by: Linus Walleij [ PIN_CONFIG_LEVEL => PIN_CONFIG_OUTPUT ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

drm/amdgpu/gfx11: adjust KGQ reset sequence

2026-02-06T15:55:51+00:00

[ Upstream commit 3eb46fbb601f9a0b4df8eba79252a0a85e983044 ] Kernel gfx queues do not need to be reinitialized or remapped after a reset. This fixes queue reset failures on APUs. v2: preserve init and remap for MMIO case. Fixes: b3e9bfd86658 ("drm/amdgpu/gfx11: add ring reset callbacks") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4789 Reviewed-by: Timur Kristóf Signed-off-by: Alex Deucher (cherry picked from commit b340ff216fdabfe71ba0cdd47e9835a141d08e10) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

writeback: fix 100% CPU usage when dirtytime_expire_interval is 0

2026-02-06T15:55:50+00:00

[ Upstream commit 543467d6fe97e27e22a26e367fda972dbefebbff ] When vm.dirtytime_expire_seconds is set to 0, wakeup_dirtytime_writeback() schedules delayed work with a delay of 0, causing immediate execution. The function then reschedules itself with 0 delay again, creating an infinite busy loop that causes 100% kworker CPU usage. Fix by: - Only scheduling delayed work in wakeup_dirtytime_writeback() when dirtytime_expire_interval is non-zero - Cancelling the delayed work in dirtytime_interval_handler() when the interval is set to 0 - Adding a guard in start_dirtytime_writeback() for defensive coding Tested by booting kernel in QEMU with virtme-ng: - Before fix: kworker CPU spikes to ~73% - After fix: CPU remains at normal levels - Setting interval back to non-zero correctly resumes writeback Fixes: a2f4870697a5 ("fs: make sure the timestamps for lazytime inodes eventually get written") Cc: stable@vger.kernel.org Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220227 Signed-off-by: Laveesh Bansal Link: https://patch.msgid.link/20260106145059.543282-2-laveeshb@laveeshbansal.com Reviewed-by: Jan Kara Signed-off-by: Christian Brauner [ adapted system_percpu_wq to system_wq for the workqueue used in dirtytime_interval_handler() ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

perf: sched: Fix perf crash with new is_user_task() helper

2026-02-06T15:55:50+00:00

[ Upstream commit 76ed27608f7dd235b727ebbb12163438c2fbb617 ] In order to do a user space stacktrace the current task needs to be a user task that has executed in user space. It use to be possible to test if a task is a user task or not by simply checking the task_struct mm field. If it was non NULL, it was a user task and if not it was a kernel task. But things have changed over time, and some kernel tasks now have their own mm field. An idea was made to instead test PF_KTHREAD and two functions were used to wrap this check in case it became more complex to test if a task was a user task or not[1]. But this was rejected and the C code simply checked the PF_KTHREAD directly. It was later found that not all kernel threads set PF_KTHREAD. The io-uring helpers instead set PF_USER_WORKER and this needed to be added as well. But checking the flags is still not enough. There's a very small window when a task exits that it frees its mm field and it is set back to NULL. If perf were to trigger at this moment, the flags test would say its a user space task but when perf would read the mm field it would crash with at NULL pointer dereference. Now there are flags that can be used to test if a task is exiting, but they are set in areas that perf may still want to profile the user space task (to see where it exited). The only real test is to check both the flags and the mm field. Instead of making this modification in every location, create a new is_user_task() helper function that does all the tests needed to know if it is safe to read the user space memory or not. [1] https://lore.kernel.org/all/20250425204120.639530125@goodmis.org/ Fixes: 90942f9fac05 ("perf: Use current->flags & PF_KTHREAD|PF_USER_WORKER instead of current->mm == NULL") Closes: https://lore.kernel.org/all/0d877e6f-41a7-4724-875d-0b0a27b8a545@roeck-us.net/ Reported-by: Guenter Roeck Signed-off-by: Steven Rostedt (Google) Signed-off-by: Peter Zijlstra (Intel) Tested-by: Guenter Roeck Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260129102821.46484722@gandalf.local.home Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

perf: Simplify get_perf_callchain() user logic

2026-02-06T15:55:50+00:00

[ Upstream commit d77e3319e31098a6cb97b7ce4e71ba676e327fd7 ] Simplify the get_perf_callchain() user logic a bit. task_pt_regs() should never be NULL. Signed-off-by: Josh Poimboeuf Signed-off-by: Steven Rostedt (Google) Signed-off-by: Peter Zijlstra (Intel) Acked-by: Namhyung Kim Link: https://lore.kernel.org/r/20250820180428.760066227@kernel.org Stable-dep-of: 76ed27608f7d ("perf: sched: Fix perf crash with new is_user_task() helper") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

mptcp: avoid dup SUB_CLOSED events after disconnect

2026-02-06T15:55:50+00:00

[ Upstream commit 280d654324e33f8e6e3641f76764694c7b64c5db ] In case of subflow disconnect(), which can also happen with the first subflow in case of errors like timeout or reset, mptcp_subflow_ctx_reset will reset most fields from the mptcp_subflow_context structure, including close_event_done. Then, when another subflow is closed, yet another SUB_CLOSED event for the disconnected initial subflow is sent. Because of the previous reset, there are no source address and destination port. A solution is then to also check the subflow's local id: it shouldn't be negative anyway. Another solution would be not to reset subflow->close_event_done at disconnect time, but when reused. But then, probably the whole reset could be done when being reused. Let's not change this logic, similar to TCP with tcp_disconnect(). Fixes: d82809b6c5f2 ("mptcp: avoid duplicated SUB_CLOSED events") Cc: stable@vger.kernel.org Reported-by: Marco Angaroni Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/603 Reviewed-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/20260127-net-mptcp-dup-nl-events-v1-1-7f71e1bc4feb@kernel.org Signed-off-by: Jakub Kicinski [ Adjust context ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman