kernel/linux.git, branch v6.19.6

Linux 6.19.6

2026-03-04T12:23:57+00:00

Tested-by: Hardik Garg Tested-by: Miguel Ojeda Tested-by: Mark Brown Tested-by: Jon Hunter Tested-by: Ron Economos Tested-by: Barry K. Nathan Tested-by: Shung-Hsi Yu Tested-by: Takeshi Ogasawara Tested-by: Florian Fainelli Tested-by: Peter Schneider Tested-by: Justin M. Forbes Tested-by: Brett A C Sheffield Signed-off-by: Sasha Levin

drm/amdgpu: Refactor amdgpu_gem_va_ioctl for Handling Last Fence Update and Timeline Management v7

2026-03-04T12:21:48+00:00

[ Upstream commit efdc66fe12b07e7b7d28650bd8d4f7e3bb92c5d4 ] When GPU memory mappings are updated, the driver returns a fence so userspace knows when the update is finished. The previous refactor could pick the wrong fence or rely on checks that are not safe for GPU mappings that stay valid even when memory is missing. In some cases this could return an invalid fence or cause fence reference counting problems. Fix this by (v5,v6, per Christian): - Starting from the VM’s existing last update fence, so a valid and meaningful fence is always returned even when no new work is required. - Selecting the VM-level fence only for always-valid / PRT mappings using the required combined bo_va + bo guard. - Using the per-BO page table update fence for normal MAP and REPLACE operations. - For UNMAP and CLEAR, returning the fence provided by amdgpu_vm_clear_freed(), which may remain unchanged when nothing needs clearing. - Keeping fence reference counting balanced. v7: Drop the extra bo_va/bo NULL guard since amdgpu_vm_is_bo_always_valid() handles NULL BOs correctly (including PRT). (Christian) This makes VM timeline fences correct and prevents crashes caused by incorrect fence handling. Fixes: bd8150a1b337 ("drm/amdgpu: Refactor amdgpu_gem_va_ioctl for Handling Last Fence Update and Timeline Management v4") Suggested-by: Christian König Signed-off-by: Srinivasan Shanmugam Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin

perf test parse-metric: Ensure aggregate counts appear to have run

2026-03-04T12:21:47+00:00

[ Upstream commit ff9aeb6bd14dbc70651971c81e81fa8269c3101a ] Commit bb5a920b90991279 ("perf stat: Ensure metrics are displayed even with failed events") with failed events") made it so that counters which weren't enabled in the kernel were handled as NaN in metrics. This caused the "Parse and process metrics" test to start failing as it wasn't putting a non-zero value in these variables. Add arbitrary values of 1 to fix the test. Fixes: bb5a920b90991279 ("perf stat: Ensure metrics are displayed even with failed events") Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Chun-Tse Shao Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Yang Li Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin

most: core: fix leak on early registration failure

2026-03-04T12:21:47+00:00

[ Upstream commit 2c198c272f9c9213b0fdf6b4a879f445c574f416 ] A recent commit fixed a resource leak on early registration failures but for some reason left out the first error path which still leaks the resources associated with the interface. Fix up also the first error path so that the interface is always released on errors. Fixes: 1f4c9d8a1021 ("most: core: fix resource leak in most_register_interface error paths") Fixes: 723de0f9171e ("staging: most: remove device from interface structure") Cc: Christian Gromm Cc: Navaneeth K Signed-off-by: Johan Hovold Link: https://patch.msgid.link/20260116162950.21578-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin

arm64: Fix sampling the "stable" virtual counter in preemptible section

2026-03-04T12:21:47+00:00

[ Upstream commit e5cb94ba5f96d691d8885175d4696d6ae6bc5ec9 ] Ben reports that when running with CONFIG_DEBUG_PREEMPT, using __arch_counter_get_cntvct_stable() results in well deserves warnings, as we access a per-CPU variable without preemption disabled. Fix the issue by disabling preemption on reading the counter. We can probably do a lot better by not disabling preemption on systems that do not require horrible workarounds to return a valid counter value, but this plugs the issue for the time being. Fixes: 29cc0f3aa7c6 ("arm64: Force the use of CNTVCT_EL0 in __delay()") Reported-by: Ben Horgan Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/aZw3EGs4rbQvbAzV@e134344.arm.com Tested-by: Ben Horgan Tested-by: André Draszik Signed-off-by: Will Deacon Signed-off-by: Sasha Levin

xfs: fix copy-paste error in previous fix

2026-03-04T12:21:47+00:00

[ Upstream commit e764dd439d68cfc16724e469db390d779ab49521 ] Chris Mason noticed that there is a copy-paste error in a recent change to xrep_dir_teardown that nulls out pointers after freeing the resources. Fixes: ba408d299a3bb3c ("xfs: only call xf{array,blob}_destroy if we have a valid pointer") Link: https://lore.kernel.org/linux-xfs/20260205194211.2307232-1-clm@meta.com/ Reported-by: Chris Mason Signed-off-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig Reviewed-by: Carlos Maiolino Signed-off-by: Carlos Maiolino Signed-off-by: Sasha Levin

drm/i915/wakeref: clean up INTEL_WAKEREF_PUT_* flag macros

2026-03-04T12:21:47+00:00

[ Upstream commit 524696a19e34598c9173fdd5b32fb7e5d16a91d3 ] Commit 469c1c9eb6c9 ("kernel-doc: Issue warnings that were silently discarded") started emitting warnings for cases that were previously silently discarded. One such case is in intel_wakeref.h: Warning: drivers/gpu/drm/i915/intel_wakeref.h:156 expecting prototype for __intel_wakeref_put(). Prototype was for INTEL_WAKEREF_PUT_ASYNC() instead Arguably kernel-doc should be able to handle this, as it's valid C, but having the flags defined between the function declarator and the body is just asking for trouble. Move the INTEL_WAKEREF_PUT_* macros away from there, making kernel-doc's life easier. While at it, reduce the unnecessary abstraction levels by removing the enum, and append _MASK to INTEL_WAKEREF_PUT_DELAY for clarity. Cc: Andy Shevchenko Cc: Jonathan Corbet Acked-by: Randy Dunlap Tested-by: Randy Dunlap Link: https://patch.msgid.link/20251215120908.3515578-1-jani.nikula@intel.com Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin

Revert "ACPI: processor: Update cpuidle driver check in __acpi_processor_start()"

2026-03-04T12:21:47+00:00

This reverts commit 0089ce1c056aee547115bdc25c223f8f88c08498 which is upstream commit 6cfed39c2ce64ac024bbde458a9727105e0b8c66. This commit is causing a suspend regression on systems such as the Asus Zephyrus G14 (GA402RJ) with Ryzen 7 6700H: when suspending, the display turns off but the device fails to fully power down. This is not seen with v7.0-rc1 which indicates that there are changes missing. Therefore, revert this change. Link: https://lore.kernel.org/all/lA7Dz_m7_nCF8KkRyEOcSCLg799Mm9_DN2r9hx7ISjw32OoKiB1r_YjGHIFX8vgqxpOkVJ8d_yHb-VsGAvIWC942D4-zdWxAIP4_k6ZIQi8=@protonmail.com/ Fixes: 0089ce1c056a ("ACPI: processor: Update cpuidle driver check in __acpi_processor_start()") Reported-by: Athul Krishna Signed-off-by: Sasha Levin

ALSA: pcm: Revert bufs move in snd_pcm_xfern_frames_ioctl()

2026-03-04T12:21:47+00:00

[ Upstream commit 0585c53b21541cd6b17ad5ab41b371a0d52e358c ] When building with clang older than 17 targeting architectures that use asm goto for their get_user() and put_user(), such as arm64, after commit f3d233daf011 ("ALSA: pcm: Relax __free() variable declarations"), there are bogus errors around skipping over a variable declared with the cleanup attribute: sound/core/pcm_native.c:3308:6: error: cannot jump from this asm goto statement to one of its possible targets if (put_user(result, &_xfern->result)) ^ ... arch/arm64/include/asm/uaccess.h:298:2: note: expanded from macro '__put_mem_asm' asm goto( ^ sound/core/pcm_native.c:3295:6: note: possible target of asm goto statement if (put_user(0, &_xfern->result)) ^ ... sound/core/pcm_native.c:3300:8: note: jump exits scope of variable with __attribute__((cleanup)) void *bufs __free(kfree) = ^ clang-17 fixed a bug in clang's jump scope checker [1] where all labels in a function were checked as valid targets for all asm goto instances in a function, regardless of whether they were actual targets in a paricular asm goto's provided list of labels. To workaround this, revert the change done to snd_pcm_xfern_frames_ioctl() by commit f3d233daf011 ("ALSA: pcm: Relax __free() variable declarations") to avoid a variable declared with cleanup from existing between multiple uses of asm goto. There are no other uses of cleanup in this function so there should be low risk from moving this variable back to the top of the function. Link: https://github.com/ClangBuiltLinux/linux/issues/1886 [1] Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202512190802.i4Jzbcsl-lkp@intel.com/ Signed-off-by: Nathan Chancellor Link: https://patch.msgid.link/20260106-pcm_native-revert-var-move-free-for-old-clang-v1-1-06a03693423d@kernel.org Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin

NTB: ntb_transport: Fix too small buffer for debugfs_name

2026-03-04T12:21:47+00:00

[ Upstream commit 6a4b50585d74fe45d3ade1e3e86ba8aae79761a5 ] The buffer used for "qp%d" was only 4 bytes, which truncates names like "qp10" to "qp1" and causes multiple queues to share the same directory. Enlarge the buffer and use sizeof() to avoid truncation. Fixes: fce8a7bb5b4b ("PCI-Express Non-Transparent Bridge Support") Cc: # v3.9+ Reviewed-by: Frank Li Reviewed-by: Dave Jiang Signed-off-by: Koichiro Den Signed-off-by: Jon Mason Signed-off-by: Sasha Levin