kernel/linux.git, branch v6.18.9

Linux 6.18.9

2026-02-06T15:57:45+00:00

Link: https://lore.kernel.org/r/20260204143851.857060534@linuxfoundation.org Tested-by: Achill Gilgenast = Tested-by: Brett A C Sheffield Tested-by: Salvatore Bonaccorso Tested-by: Florian Fainelli Tested-by: Jon Hunter Tested-by: Justin M. Forbes Tested-by: Takeshi Ogasawara Tested-by: Peter Schneider Tested-by: Luna Jernberg Tested-by: Ron Economos Tested-by: Mark Brown Tested-by: Brett Mastbergen Tested-by: Hardik Garg Tested-by: Barry K. Nathan Tested-by: Shung-Hsi Yu Tested-by: Dileep Malepu Tested-by: Miguel Ojeda Tested-by: Jeffrin Jose T Signed-off-by: Greg Kroah-Hartman

mptcp: avoid dup SUB_CLOSED events after disconnect

2026-02-06T15:57:45+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

sched_ext: Fix SCX_KICK_WAIT to work reliably

2026-02-06T15:57:45+00:00

commit a379fa1e2cae15d7422b4eead83a6366f2f445cb upstream. SCX_KICK_WAIT is used to synchronously wait for the target CPU to complete a reschedule and can be used to implement operations like core scheduling. This used to be implemented by scx_next_task_picked() incrementing pnt_seq, which was always called when a CPU picks the next task to run, allowing SCX_KICK_WAIT to reliably wait for the target CPU to enter the scheduler and pick the next task. However, commit b999e365c298 ("sched_ext: Replace scx_next_task_picked() with switch_class()") replaced scx_next_task_picked() with the switch_class() callback, which is only called when switching between sched classes. This broke SCX_KICK_WAIT because pnt_seq would no longer be reliably incremented unless the previous task was SCX and the next task was not. This fix leverages commit 4c95380701f5 ("sched/ext: Fold balance_scx() into pick_task_scx()") which refactored the pick path making put_prev_task_scx() the natural place to track task switches for SCX_KICK_WAIT. The fix moves pnt_seq increment to put_prev_task_scx() and also increments it in pick_task_scx() to handle cases where the same task is re-selected, whether by BPF scheduler decision or slice refill. The semantics: If the current task on the target CPU is SCX, SCX_KICK_WAIT waits until the CPU enters the scheduling path. This provides sufficient guarantee for use cases like core scheduling while keeping the operation self-contained within SCX. v2: - Also increment pnt_seq in pick_task_scx() to handle same-task re-selection (Andrea Righi). - Use smp_cond_load_acquire() for the busy-wait loop for better architecture optimization (Peter Zijlstra). Reported-by: Wen-Fang Liu Link: http://lkml.kernel.org/r/228ebd9e6ed3437996dffe15735a9caa@honor.com Cc: Peter Zijlstra Reviewed-by: Andrea Righi Signed-off-by: Tejun Heo Signed-off-by: Christian Loehle Signed-off-by: Greg Kroah-Hartman

sched_ext: Don't kick CPUs running higher classes

2026-02-06T15:57:45+00:00

commit a9c1fbbd6dadbaa38c157a07d5d11005460b86b9 upstream. When a sched_ext scheduler tries to kick a CPU, the CPU may be running a higher class task. sched_ext has no control over such CPUs. A sched_ext scheduler couldn't have expected to get access to the CPU after kicking it anyway. Skip kicking when the target CPU is running a higher class. Reviewed-by: Andrea Righi Signed-off-by: Tejun Heo Signed-off-by: Christian Loehle Signed-off-by: Greg Kroah-Hartman

net/sched: act_ife: convert comma to semicolon

2026-02-06T15:57:45+00:00

commit 205305c028ad986d0649b8b100bab6032dcd1bb5 upstream. Replace comma between expressions with semicolons. Using a ',' in place of a ';' can have unintended side effects. Although that is not the case here, it is seems best to use ';' unless ',' is intended. Found by inspection. No functional change intended. Compile tested only. Signed-off-by: Chen Ni Reviewed-by: Jamal Hadi Salim Link: https://patch.msgid.link/20251112072709.73755-1-nichen@iscas.ac.cn Signed-off-by: Jakub Kicinski Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman

Revert "drm/nouveau/disp: Set drm_mode_config_funcs.atomic_(check|commit)"

2026-02-06T15:57:45+00:00

commit 6c65db809796717f0a96cf22f80405dbc1a31a4b upstream. This reverts commit 604826acb3f53c6648a7ee99a3914ead680ab7fb. Apparently there is more to supporting atomic modesetting than providing atomic_(check|commit) callbacks. Before this revert: WARNING: [] drivers/gpu/drm/drm_plane.c:389 at .__drm_universal_plane_init+0x13c/0x794 [drm], CPU#1: modprobe/1790 BUG: Kernel NULL pointer dereference on read at 0x00000000 .drm_atomic_get_plane_state+0xd4/0x210 [drm] (unreliable) .drm_client_modeset_commit_atomic+0xf8/0x338 [drm] .drm_client_modeset_commit_locked+0x80/0x260 [drm] .drm_client_modeset_commit+0x40/0x7c [drm] .__drm_fb_helper_restore_fbdev_mode_unlocked.part.0+0xfc/0x108 [drm_kms_helper] .drm_fb_helper_set_par+0x8c/0xb8 [drm_kms_helper] .fbcon_init+0x31c/0x618 [...] .__drm_fb_helper_initial_config_and_unlock+0x474/0x7f4 [drm_kms_helper] .drm_fbdev_client_hotplug+0xb0/0x120 [drm_client_lib] .drm_client_register+0x88/0xe4 [drm] .drm_fbdev_client_setup+0x12c/0x19b4 [drm_client_lib] .drm_client_setup+0x15c/0x18c [drm_client_lib] .nouveau_drm_probe+0x19c/0x268 [nouveau] Fixes: 604826acb3f5 ("drm/nouveau/disp: Set drm_mode_config_funcs.atomic_(check|commit)") Reported-by: John Ogness Closes: https://lore.kernel.org/lkml/87ldhf1prw.fsf@jogness.linutronix.de Signed-off-by: John Ogness Tested-by: Daniel Palmer Link: https://patch.msgid.link/20260130113230.2311221-1-john.ogness@linutronix.de Signed-off-by: Danilo Krummrich Signed-off-by: Greg Kroah-Hartman

libbpf: Fix -Wdiscarded-qualifiers under C23

2026-02-06T15:57:45+00:00

commit d70f79fef65810faf64dbae1f3a1b5623cdb2345 upstream. glibc ≥ 2.42 (GCC 15) defaults to -std=gnu23, which promotes -Wdiscarded-qualifiers to an error. In C23, strstr() and strchr() return "const char *". Change variable types to const char * where the pointers are never modified (res, sym_sfx, next_path). Suggested-by: Florian Weimer Suggested-by: Andrii Nakryiko Signed-off-by: Mikhail Gavrilov Link: https://lore.kernel.org/r/20251206092825.1471385-1-mikhail.v.gavrilov@gmail.com Signed-off-by: Alexei Starovoitov [ shung-hsi.yu: needed to fix kernel build failure due to libbpf since glibc 2.43+ (which adds 'const' qualifier to strstr) ] Signed-off-by: Shung-Hsi Yu Signed-off-by: Greg Kroah-Hartman

gpiolib: acpi: Fix potential out-of-boundary left shift

2026-02-06T15:57:44+00:00

commit e64d1cb21a1c6ecd51bc1c94c83f6fc656f7c94d upstream. GPIO Address Space handler gets a pointer to the in or out value. This value is supposed to be at least 64-bit, but it's not limited to be exactly 64-bit. When ACPI tables are being parsed, for the bigger Connection():s ACPICA creates a Buffer instead of regular Integer object. The Buffer exists as long as Namespace holds the certain Connection(). Hence we can access the necessary bits without worrying. On the other hand, the left shift, used in the code, is limited by 31 (on 32-bit platforms) and otherwise considered to be Undefined Behaviour. Also the code uses only the first 64-bit word for the value, and anything bigger than 63 will be also subject to UB. Fix all this by modifying the code to correctly set or clear the respective bit in the bitmap constructed of 64-bit words. Fixes: 59084c564c41 ("gpiolib: acpi: use BIT_ULL() for u64 mask in address space handler") Fixes: 2c4d00cb8fc5 ("gpiolib: acpi: Use BIT() macro to increase readability") Cc: stable@vger.kernel.org Reviewed-by: Mika Westerberg Signed-off-by: Andy Shevchenko Link: https://patch.msgid.link/20260128095918.4157491-1-andriy.shevchenko@linux.intel.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman

iommu/tegra241-cmdqv: Reset VCMDQ in tegra241_vcmdq_hw_init_user()

2026-02-06T15:57:44+00:00

commit 80f1a2c2332fee0edccd006fe87fc8a6db94bab3 upstream. The Enable bits in CMDQV/VINTF/VCMDQ_CONFIG registers do not actually reset the HW registers. So, the driver explicitly clears all the registers when a VINTF or VCMDQ is being initialized calling its hw_deinit() function. However, a userspace VCMDQ is not properly reset, unlike an in-kernel VCMDQ getting reset in tegra241_vcmdq_hw_init(). Meanwhile, tegra241_vintf_hw_init() calling tegra241_vintf_hw_deinit() will not deinit any VCMDQ, since there is no userspace VCMDQ mapped to the VINTF at that stage. Then, this may result in dirty VCMDQ registers, which can fail the VM. Like tegra241_vcmdq_hw_init(), reset a VCMDQ in tegra241_vcmdq_hw_init() to fix this bug. This is required by a host kernel. Fixes: 6717f26ab1e7 ("iommu/tegra241-cmdqv: Add user-space use support") Cc: stable@vger.kernel.org Reported-by: Bao Nguyen Signed-off-by: Nicolin Chen Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: Fix cond_exec handling in amdgpu_ib_schedule()

2026-02-06T15:57:44+00:00

commit b1defcdc4457649db236415ee618a7151e28788c upstream. The EXEC_COUNT field must be > 0. In the gfx shadow handling we always emit a cond_exec packet after the gfx_shadow packet, but the EXEC_COUNT never gets patched. This leads to a hang when we try and reset queues on gfx11 APUs. Fixes: c68cbbfd54c6 ("drm/amdgpu: cleanup conditional execution") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4789 Reviewed-by: Jesse Zhang Signed-off-by: Alex Deucher (cherry picked from commit ba205ac3d6e83f56c4f824f23f1b4522cb844ff3) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman