From: Sasha Levin Date: Mon, 2 Mar 2026 15:48:00 +0000 (-0500) Subject: Fixes for all trees X-Git-Tag: v6.19.6~2 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=91087fc8f4c1a14663537b41d91f5961de2ea424;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for all trees Signed-off-by: Sasha Levin --- diff --git a/queue-6.1/arm64-fix-sampling-the-stable-virtual-counter-in-pre.patch b/queue-6.1/arm64-fix-sampling-the-stable-virtual-counter-in-pre.patch new file mode 100644 index 0000000000..9e7b037331 --- /dev/null +++ b/queue-6.1/arm64-fix-sampling-the-stable-virtual-counter-in-pre.patch @@ -0,0 +1,54 @@ +From 47b398be7bfb6227c13815315fbb42c269590930 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 26 Feb 2026 08:22:32 +0000 +Subject: arm64: Fix sampling the "stable" virtual counter in preemptible + section +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Marc Zyngier + +[ 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 +--- + arch/arm64/lib/delay.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +diff --git a/arch/arm64/lib/delay.c b/arch/arm64/lib/delay.c +index 2b6041cc8448f..15a953ac6f0fb 100644 +--- a/arch/arm64/lib/delay.c ++++ b/arch/arm64/lib/delay.c +@@ -32,7 +32,11 @@ static inline unsigned long xloops_to_cycles(unsigned long xloops) + * Note that userspace cannot change the offset behind our back either, + * as the vcpu mutex is held as long as KVM_RUN is in progress. + */ +-#define __delay_cycles() __arch_counter_get_cntvct_stable() ++static cycles_t notrace __delay_cycles(void) ++{ ++ guard(preempt_notrace)(); ++ return __arch_counter_get_cntvct_stable(); ++} + + void __delay(unsigned long cycles) + { +-- +2.51.0 + diff --git a/queue-6.1/series b/queue-6.1/series index a76b7a561b..2d3c411db0 100644 --- a/queue-6.1/series +++ b/queue-6.1/series @@ -529,3 +529,4 @@ x86-kexec-copy-acpi-root-pointer-address-from-config.patch arm64-force-the-use-of-cntvct_el0-in-__delay.patch net-nfc-nci-fix-parameter-validation-for-packet-data.patch ntb-ntb_transport-fix-too-small-buffer-for-debugfs_n.patch +arm64-fix-sampling-the-stable-virtual-counter-in-pre.patch diff --git a/queue-6.12/arm64-fix-sampling-the-stable-virtual-counter-in-pre.patch b/queue-6.12/arm64-fix-sampling-the-stable-virtual-counter-in-pre.patch new file mode 100644 index 0000000000..81a28a9ada --- /dev/null +++ b/queue-6.12/arm64-fix-sampling-the-stable-virtual-counter-in-pre.patch @@ -0,0 +1,54 @@ +From afad9687f5c17b4bdb3173e0ac65c2dfbc5fe5f9 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 26 Feb 2026 08:22:32 +0000 +Subject: arm64: Fix sampling the "stable" virtual counter in preemptible + section +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Marc Zyngier + +[ 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 +--- + arch/arm64/lib/delay.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +diff --git a/arch/arm64/lib/delay.c b/arch/arm64/lib/delay.c +index d02341303899e..e278e060e78a9 100644 +--- a/arch/arm64/lib/delay.c ++++ b/arch/arm64/lib/delay.c +@@ -32,7 +32,11 @@ static inline unsigned long xloops_to_cycles(unsigned long xloops) + * Note that userspace cannot change the offset behind our back either, + * as the vcpu mutex is held as long as KVM_RUN is in progress. + */ +-#define __delay_cycles() __arch_counter_get_cntvct_stable() ++static cycles_t notrace __delay_cycles(void) ++{ ++ guard(preempt_notrace)(); ++ return __arch_counter_get_cntvct_stable(); ++} + + void __delay(unsigned long cycles) + { +-- +2.51.0 + diff --git a/queue-6.12/most-core-fix-leak-on-early-registration-failure.patch b/queue-6.12/most-core-fix-leak-on-early-registration-failure.patch new file mode 100644 index 0000000000..d22811940f --- /dev/null +++ b/queue-6.12/most-core-fix-leak-on-early-registration-failure.patch @@ -0,0 +1,55 @@ +From ebc9e34dcd9e6723a9a8bf7eff47036cf52fe9cc Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 16 Jan 2026 17:29:50 +0100 +Subject: most: core: fix leak on early registration failure + +From: Johan Hovold + +[ 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 +--- + drivers/most/core.c | 9 +++++++-- + 1 file changed, 7 insertions(+), 2 deletions(-) + +diff --git a/drivers/most/core.c b/drivers/most/core.c +index 6277e6702ca8c..40d63e38fef54 100644 +--- a/drivers/most/core.c ++++ b/drivers/most/core.c +@@ -1282,12 +1282,17 @@ int most_register_interface(struct most_interface *iface) + int id; + struct most_channel *c; + +- if (!iface || !iface->enqueue || !iface->configure || +- !iface->poison_channel || (iface->num_channels > MAX_CHANNELS)) ++ if (!iface) + return -EINVAL; + + device_initialize(iface->dev); + ++ if (!iface->enqueue || !iface->configure || !iface->poison_channel || ++ (iface->num_channels > MAX_CHANNELS)) { ++ put_device(iface->dev); ++ return -EINVAL; ++ } ++ + id = ida_alloc(&mdev_id, GFP_KERNEL); + if (id < 0) { + dev_err(iface->dev, "Failed to allocate device ID\n"); +-- +2.51.0 + diff --git a/queue-6.12/series b/queue-6.12/series index bf41c6aed7..3def5f2c38 100644 --- a/queue-6.12/series +++ b/queue-6.12/series @@ -950,3 +950,6 @@ tracing-wake-up-poll-waiters-for-hist-files-when-rem.patch ntb-ntb_transport-fix-too-small-buffer-for-debugfs_n.patch alsa-pcm-revert-bufs-move-in-snd_pcm_xfern_frames_io.patch drm-i915-wakeref-clean-up-intel_wakeref_put_-flag-ma.patch +xfs-fix-copy-paste-error-in-previous-fix.patch +arm64-fix-sampling-the-stable-virtual-counter-in-pre.patch +most-core-fix-leak-on-early-registration-failure.patch diff --git a/queue-6.12/xfs-fix-copy-paste-error-in-previous-fix.patch b/queue-6.12/xfs-fix-copy-paste-error-in-previous-fix.patch new file mode 100644 index 0000000000..013dd2a55d --- /dev/null +++ b/queue-6.12/xfs-fix-copy-paste-error-in-previous-fix.patch @@ -0,0 +1,41 @@ +From faedd175385d7ad56109a3a93aae1d69bdda45ae Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 18 Feb 2026 15:25:35 -0800 +Subject: xfs: fix copy-paste error in previous fix + +From: Darrick J. Wong + +[ 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 +--- + fs/xfs/scrub/dir_repair.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/fs/xfs/scrub/dir_repair.c b/fs/xfs/scrub/dir_repair.c +index 81c3fda7590bf..a9e2aa5c3968d 100644 +--- a/fs/xfs/scrub/dir_repair.c ++++ b/fs/xfs/scrub/dir_repair.c +@@ -177,7 +177,7 @@ xrep_dir_teardown( + rd->dir_names = NULL; + if (rd->dir_entries) + xfarray_destroy(rd->dir_entries); +- rd->dir_names = NULL; ++ rd->dir_entries = NULL; + } + + /* Set up for a directory repair. */ +-- +2.51.0 + diff --git a/queue-6.18/arm64-fix-sampling-the-stable-virtual-counter-in-pre.patch b/queue-6.18/arm64-fix-sampling-the-stable-virtual-counter-in-pre.patch new file mode 100644 index 0000000000..bf5a3734dc --- /dev/null +++ b/queue-6.18/arm64-fix-sampling-the-stable-virtual-counter-in-pre.patch @@ -0,0 +1,54 @@ +From aac6413b8e2768ef0fac9bd51be0ba902a0fd17b Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 26 Feb 2026 08:22:32 +0000 +Subject: arm64: Fix sampling the "stable" virtual counter in preemptible + section +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Marc Zyngier + +[ 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 +--- + arch/arm64/lib/delay.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +diff --git a/arch/arm64/lib/delay.c b/arch/arm64/lib/delay.c +index d02341303899e..e278e060e78a9 100644 +--- a/arch/arm64/lib/delay.c ++++ b/arch/arm64/lib/delay.c +@@ -32,7 +32,11 @@ static inline unsigned long xloops_to_cycles(unsigned long xloops) + * Note that userspace cannot change the offset behind our back either, + * as the vcpu mutex is held as long as KVM_RUN is in progress. + */ +-#define __delay_cycles() __arch_counter_get_cntvct_stable() ++static cycles_t notrace __delay_cycles(void) ++{ ++ guard(preempt_notrace)(); ++ return __arch_counter_get_cntvct_stable(); ++} + + void __delay(unsigned long cycles) + { +-- +2.51.0 + diff --git a/queue-6.18/drm-amdgpu-refactor-amdgpu_gem_va_ioctl-for-handling.patch-25528 b/queue-6.18/drm-amdgpu-refactor-amdgpu_gem_va_ioctl-for-handling.patch-25528 new file mode 100644 index 0000000000..b6f3ec6ffc --- /dev/null +++ b/queue-6.18/drm-amdgpu-refactor-amdgpu_gem_va_ioctl-for-handling.patch-25528 @@ -0,0 +1,164 @@ +From 824507b5eae87a829c579e7cbc042e70bf987e02 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 9 Jan 2026 18:01:23 +0530 +Subject: drm/amdgpu: Refactor amdgpu_gem_va_ioctl for Handling Last Fence + Update and Timeline Management v7 +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Srinivasan Shanmugam + +[ 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 +--- + drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 73 +++++++++++++------------ + 1 file changed, 37 insertions(+), 36 deletions(-) + +diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c +index b5eb45d2905be..1631a0431ea8e 100644 +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c +@@ -720,15 +720,23 @@ amdgpu_gem_va_update_vm(struct amdgpu_device *adev, + struct amdgpu_bo_va *bo_va, + uint32_t operation) + { +- struct dma_fence *clear_fence = dma_fence_get_stub(); +- struct dma_fence *last_update = NULL; +- int r; ++ struct dma_fence *fence; ++ int r = 0; ++ ++ /* Always start from the VM's existing last update fence. */ ++ fence = dma_fence_get(vm->last_update); + + if (!amdgpu_vm_ready(vm)) +- return clear_fence; ++ return fence; + +- /* First clear freed BOs and get a fence for that work, if any. */ +- r = amdgpu_vm_clear_freed(adev, vm, &clear_fence); ++ /* ++ * First clean up any freed mappings in the VM. ++ * ++ * amdgpu_vm_clear_freed() may replace @fence with a new fence if it ++ * schedules GPU work. If nothing needs clearing, @fence can remain as ++ * the original vm->last_update. ++ */ ++ r = amdgpu_vm_clear_freed(adev, vm, &fence); + if (r) + goto error; + +@@ -746,35 +754,38 @@ amdgpu_gem_va_update_vm(struct amdgpu_device *adev, + goto error; + + /* +- * Decide which fence represents the "last update" for this VM/BO: ++ * Decide which fence best represents the last update: ++ * ++ * MAP/REPLACE: ++ * - For always-valid mappings, use vm->last_update. ++ * - Otherwise, export bo_va->last_pt_update. + * +- * - For MAP/REPLACE we want the PT update fence, which is tracked as +- * either vm->last_update (for always-valid BOs) or bo_va->last_pt_update +- * (for per-BO updates). ++ * UNMAP/CLEAR: ++ * Keep the fence returned by amdgpu_vm_clear_freed(). If no work was ++ * needed, it can remain as vm->last_pt_update. + * +- * - For UNMAP/CLEAR we rely on the fence returned by +- * amdgpu_vm_clear_freed(), which already covers the page table work +- * for the removed mappings. ++ * The VM and BO update fences are always initialized to a valid value. ++ * vm->last_update and bo_va->last_pt_update always start as valid fences. ++ * and are never expected to be NULL. + */ + switch (operation) { + case AMDGPU_VA_OP_MAP: + case AMDGPU_VA_OP_REPLACE: +- if (bo_va && bo_va->base.bo) { +- if (amdgpu_vm_is_bo_always_valid(vm, bo_va->base.bo)) { +- if (vm->last_update) +- last_update = dma_fence_get(vm->last_update); +- } else { +- if (bo_va->last_pt_update) +- last_update = dma_fence_get(bo_va->last_pt_update); +- } +- } ++ /* ++ * For MAP/REPLACE, return the page table update fence for the ++ * mapping we just modified. bo_va is expected to be valid here. ++ */ ++ dma_fence_put(fence); ++ ++ if (amdgpu_vm_is_bo_always_valid(vm, bo_va->base.bo)) ++ fence = dma_fence_get(vm->last_update); ++ else ++ fence = dma_fence_get(bo_va->last_pt_update); + break; + case AMDGPU_VA_OP_UNMAP: + case AMDGPU_VA_OP_CLEAR: +- if (clear_fence) +- last_update = dma_fence_get(clear_fence); +- break; + default: ++ /* keep @fence as returned by amdgpu_vm_clear_freed() */ + break; + } + +@@ -782,17 +793,7 @@ amdgpu_gem_va_update_vm(struct amdgpu_device *adev, + if (r && r != -ERESTARTSYS) + DRM_ERROR("Couldn't update BO_VA (%d)\n", r); + +- /* +- * If we managed to pick a more specific last-update fence, prefer it +- * over the generic clear_fence and drop the extra reference to the +- * latter. +- */ +- if (last_update) { +- dma_fence_put(clear_fence); +- return last_update; +- } +- +- return clear_fence; ++ return fence; + } + + int amdgpu_gem_va_ioctl(struct drm_device *dev, void *data, +-- +2.51.0 + diff --git a/queue-6.18/most-core-fix-leak-on-early-registration-failure.patch b/queue-6.18/most-core-fix-leak-on-early-registration-failure.patch new file mode 100644 index 0000000000..840f6a981a --- /dev/null +++ b/queue-6.18/most-core-fix-leak-on-early-registration-failure.patch @@ -0,0 +1,55 @@ +From 8440564773b67c38299680dba07d018a1af69990 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 16 Jan 2026 17:29:50 +0100 +Subject: most: core: fix leak on early registration failure + +From: Johan Hovold + +[ 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 +--- + drivers/most/core.c | 9 +++++++-- + 1 file changed, 7 insertions(+), 2 deletions(-) + +diff --git a/drivers/most/core.c b/drivers/most/core.c +index 6277e6702ca8c..40d63e38fef54 100644 +--- a/drivers/most/core.c ++++ b/drivers/most/core.c +@@ -1282,12 +1282,17 @@ int most_register_interface(struct most_interface *iface) + int id; + struct most_channel *c; + +- if (!iface || !iface->enqueue || !iface->configure || +- !iface->poison_channel || (iface->num_channels > MAX_CHANNELS)) ++ if (!iface) + return -EINVAL; + + device_initialize(iface->dev); + ++ if (!iface->enqueue || !iface->configure || !iface->poison_channel || ++ (iface->num_channels > MAX_CHANNELS)) { ++ put_device(iface->dev); ++ return -EINVAL; ++ } ++ + id = ida_alloc(&mdev_id, GFP_KERNEL); + if (id < 0) { + dev_err(iface->dev, "Failed to allocate device ID\n"); +-- +2.51.0 + diff --git a/queue-6.18/series b/queue-6.18/series index 1c8d7957e7..d8320e092e 100644 --- a/queue-6.18/series +++ b/queue-6.18/series @@ -750,3 +750,7 @@ ntb-ntb_transport-fix-too-small-buffer-for-debugfs_n.patch alsa-pcm-revert-bufs-move-in-snd_pcm_xfern_frames_io.patch revert-acpi-processor-update-cpuidle-driver-check-in.patch drm-i915-wakeref-clean-up-intel_wakeref_put_-flag-ma.patch +xfs-fix-copy-paste-error-in-previous-fix.patch +arm64-fix-sampling-the-stable-virtual-counter-in-pre.patch +most-core-fix-leak-on-early-registration-failure.patch +drm-amdgpu-refactor-amdgpu_gem_va_ioctl-for-handling.patch-25528 diff --git a/queue-6.18/xfs-fix-copy-paste-error-in-previous-fix.patch b/queue-6.18/xfs-fix-copy-paste-error-in-previous-fix.patch new file mode 100644 index 0000000000..3778fb5201 --- /dev/null +++ b/queue-6.18/xfs-fix-copy-paste-error-in-previous-fix.patch @@ -0,0 +1,41 @@ +From b6696822d24ec5d40617b29be442580a99ecb701 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 18 Feb 2026 15:25:35 -0800 +Subject: xfs: fix copy-paste error in previous fix + +From: Darrick J. Wong + +[ 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 +--- + fs/xfs/scrub/dir_repair.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/fs/xfs/scrub/dir_repair.c b/fs/xfs/scrub/dir_repair.c +index d5a55eabf6801..e0fa5e6ca1fe8 100644 +--- a/fs/xfs/scrub/dir_repair.c ++++ b/fs/xfs/scrub/dir_repair.c +@@ -177,7 +177,7 @@ xrep_dir_teardown( + rd->dir_names = NULL; + if (rd->dir_entries) + xfarray_destroy(rd->dir_entries); +- rd->dir_names = NULL; ++ rd->dir_entries = NULL; + } + + /* Set up for a directory repair. */ +-- +2.51.0 + diff --git a/queue-6.19/arm64-fix-sampling-the-stable-virtual-counter-in-pre.patch b/queue-6.19/arm64-fix-sampling-the-stable-virtual-counter-in-pre.patch new file mode 100644 index 0000000000..893d2440ba --- /dev/null +++ b/queue-6.19/arm64-fix-sampling-the-stable-virtual-counter-in-pre.patch @@ -0,0 +1,54 @@ +From 8b2c1ed1cafddc152ceb3674bb9c1916e844fee4 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 26 Feb 2026 08:22:32 +0000 +Subject: arm64: Fix sampling the "stable" virtual counter in preemptible + section +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Marc Zyngier + +[ 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 +--- + arch/arm64/lib/delay.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +diff --git a/arch/arm64/lib/delay.c b/arch/arm64/lib/delay.c +index d02341303899e..e278e060e78a9 100644 +--- a/arch/arm64/lib/delay.c ++++ b/arch/arm64/lib/delay.c +@@ -32,7 +32,11 @@ static inline unsigned long xloops_to_cycles(unsigned long xloops) + * Note that userspace cannot change the offset behind our back either, + * as the vcpu mutex is held as long as KVM_RUN is in progress. + */ +-#define __delay_cycles() __arch_counter_get_cntvct_stable() ++static cycles_t notrace __delay_cycles(void) ++{ ++ guard(preempt_notrace)(); ++ return __arch_counter_get_cntvct_stable(); ++} + + void __delay(unsigned long cycles) + { +-- +2.51.0 + diff --git a/queue-6.19/drm-amdgpu-refactor-amdgpu_gem_va_ioctl-for-handling.patch-29804 b/queue-6.19/drm-amdgpu-refactor-amdgpu_gem_va_ioctl-for-handling.patch-29804 new file mode 100644 index 0000000000..4f0cbaab51 --- /dev/null +++ b/queue-6.19/drm-amdgpu-refactor-amdgpu_gem_va_ioctl-for-handling.patch-29804 @@ -0,0 +1,164 @@ +From ea4fcae379ed9a5cfde81fd2975ddd7608c7bacc Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 9 Jan 2026 18:01:23 +0530 +Subject: drm/amdgpu: Refactor amdgpu_gem_va_ioctl for Handling Last Fence + Update and Timeline Management v7 +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Srinivasan Shanmugam + +[ 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 +--- + drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 73 +++++++++++++------------ + 1 file changed, 37 insertions(+), 36 deletions(-) + +diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c +index f30e32fbff99a..b39862256b769 100644 +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c +@@ -720,15 +720,23 @@ amdgpu_gem_va_update_vm(struct amdgpu_device *adev, + struct amdgpu_bo_va *bo_va, + uint32_t operation) + { +- struct dma_fence *clear_fence = dma_fence_get_stub(); +- struct dma_fence *last_update = NULL; +- int r; ++ struct dma_fence *fence; ++ int r = 0; ++ ++ /* Always start from the VM's existing last update fence. */ ++ fence = dma_fence_get(vm->last_update); + + if (!amdgpu_vm_ready(vm)) +- return clear_fence; ++ return fence; + +- /* First clear freed BOs and get a fence for that work, if any. */ +- r = amdgpu_vm_clear_freed(adev, vm, &clear_fence); ++ /* ++ * First clean up any freed mappings in the VM. ++ * ++ * amdgpu_vm_clear_freed() may replace @fence with a new fence if it ++ * schedules GPU work. If nothing needs clearing, @fence can remain as ++ * the original vm->last_update. ++ */ ++ r = amdgpu_vm_clear_freed(adev, vm, &fence); + if (r) + goto error; + +@@ -746,35 +754,38 @@ amdgpu_gem_va_update_vm(struct amdgpu_device *adev, + goto error; + + /* +- * Decide which fence represents the "last update" for this VM/BO: ++ * Decide which fence best represents the last update: ++ * ++ * MAP/REPLACE: ++ * - For always-valid mappings, use vm->last_update. ++ * - Otherwise, export bo_va->last_pt_update. + * +- * - For MAP/REPLACE we want the PT update fence, which is tracked as +- * either vm->last_update (for always-valid BOs) or bo_va->last_pt_update +- * (for per-BO updates). ++ * UNMAP/CLEAR: ++ * Keep the fence returned by amdgpu_vm_clear_freed(). If no work was ++ * needed, it can remain as vm->last_pt_update. + * +- * - For UNMAP/CLEAR we rely on the fence returned by +- * amdgpu_vm_clear_freed(), which already covers the page table work +- * for the removed mappings. ++ * The VM and BO update fences are always initialized to a valid value. ++ * vm->last_update and bo_va->last_pt_update always start as valid fences. ++ * and are never expected to be NULL. + */ + switch (operation) { + case AMDGPU_VA_OP_MAP: + case AMDGPU_VA_OP_REPLACE: +- if (bo_va && bo_va->base.bo) { +- if (amdgpu_vm_is_bo_always_valid(vm, bo_va->base.bo)) { +- if (vm->last_update) +- last_update = dma_fence_get(vm->last_update); +- } else { +- if (bo_va->last_pt_update) +- last_update = dma_fence_get(bo_va->last_pt_update); +- } +- } ++ /* ++ * For MAP/REPLACE, return the page table update fence for the ++ * mapping we just modified. bo_va is expected to be valid here. ++ */ ++ dma_fence_put(fence); ++ ++ if (amdgpu_vm_is_bo_always_valid(vm, bo_va->base.bo)) ++ fence = dma_fence_get(vm->last_update); ++ else ++ fence = dma_fence_get(bo_va->last_pt_update); + break; + case AMDGPU_VA_OP_UNMAP: + case AMDGPU_VA_OP_CLEAR: +- if (clear_fence) +- last_update = dma_fence_get(clear_fence); +- break; + default: ++ /* keep @fence as returned by amdgpu_vm_clear_freed() */ + break; + } + +@@ -782,17 +793,7 @@ amdgpu_gem_va_update_vm(struct amdgpu_device *adev, + if (r && r != -ERESTARTSYS) + DRM_ERROR("Couldn't update BO_VA (%d)\n", r); + +- /* +- * If we managed to pick a more specific last-update fence, prefer it +- * over the generic clear_fence and drop the extra reference to the +- * latter. +- */ +- if (last_update) { +- dma_fence_put(clear_fence); +- return last_update; +- } +- +- return clear_fence; ++ return fence; + } + + int amdgpu_gem_va_ioctl(struct drm_device *dev, void *data, +-- +2.51.0 + diff --git a/queue-6.19/most-core-fix-leak-on-early-registration-failure.patch b/queue-6.19/most-core-fix-leak-on-early-registration-failure.patch new file mode 100644 index 0000000000..03d62289dc --- /dev/null +++ b/queue-6.19/most-core-fix-leak-on-early-registration-failure.patch @@ -0,0 +1,55 @@ +From 6c51eb23d20e4b52f4f797afec2892a12b4696cb Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 16 Jan 2026 17:29:50 +0100 +Subject: most: core: fix leak on early registration failure + +From: Johan Hovold + +[ 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 +--- + drivers/most/core.c | 9 +++++++-- + 1 file changed, 7 insertions(+), 2 deletions(-) + +diff --git a/drivers/most/core.c b/drivers/most/core.c +index 6277e6702ca8c..40d63e38fef54 100644 +--- a/drivers/most/core.c ++++ b/drivers/most/core.c +@@ -1282,12 +1282,17 @@ int most_register_interface(struct most_interface *iface) + int id; + struct most_channel *c; + +- if (!iface || !iface->enqueue || !iface->configure || +- !iface->poison_channel || (iface->num_channels > MAX_CHANNELS)) ++ if (!iface) + return -EINVAL; + + device_initialize(iface->dev); + ++ if (!iface->enqueue || !iface->configure || !iface->poison_channel || ++ (iface->num_channels > MAX_CHANNELS)) { ++ put_device(iface->dev); ++ return -EINVAL; ++ } ++ + id = ida_alloc(&mdev_id, GFP_KERNEL); + if (id < 0) { + dev_err(iface->dev, "Failed to allocate device ID\n"); +-- +2.51.0 + diff --git a/queue-6.19/perf-test-parse-metric-ensure-aggregate-counts-appea.patch b/queue-6.19/perf-test-parse-metric-ensure-aggregate-counts-appea.patch new file mode 100644 index 0000000000..e5d9e37986 --- /dev/null +++ b/queue-6.19/perf-test-parse-metric-ensure-aggregate-counts-appea.patch @@ -0,0 +1,51 @@ +From 911f0aa68c3f388567b8a1072b21833c868d6288 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 7 Feb 2026 21:54:55 -0800 +Subject: perf test parse-metric: Ensure aggregate counts appear to have run + +From: Ian Rogers + +[ 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 +--- + tools/perf/tests/parse-metric.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/tools/perf/tests/parse-metric.c b/tools/perf/tests/parse-metric.c +index 6bbc209a5c6af..7c7f489a5eb0a 100644 +--- a/tools/perf/tests/parse-metric.c ++++ b/tools/perf/tests/parse-metric.c +@@ -41,6 +41,8 @@ static void load_runtime_stat(struct evlist *evlist, struct value *vals) + count = find_value(evsel->name, vals); + evsel->supported = true; + evsel->stats->aggr->counts.val = count; ++ evsel->stats->aggr->counts.ena = 1; ++ evsel->stats->aggr->counts.run = 1; + } + } + +-- +2.51.0 + diff --git a/queue-6.19/series b/queue-6.19/series index 046810692f..57ae117ea3 100644 --- a/queue-6.19/series +++ b/queue-6.19/series @@ -842,3 +842,8 @@ ntb-ntb_transport-fix-too-small-buffer-for-debugfs_n.patch alsa-pcm-revert-bufs-move-in-snd_pcm_xfern_frames_io.patch revert-acpi-processor-update-cpuidle-driver-check-in.patch drm-i915-wakeref-clean-up-intel_wakeref_put_-flag-ma.patch +xfs-fix-copy-paste-error-in-previous-fix.patch +arm64-fix-sampling-the-stable-virtual-counter-in-pre.patch +most-core-fix-leak-on-early-registration-failure.patch +perf-test-parse-metric-ensure-aggregate-counts-appea.patch +drm-amdgpu-refactor-amdgpu_gem_va_ioctl-for-handling.patch-29804 diff --git a/queue-6.19/xfs-fix-copy-paste-error-in-previous-fix.patch b/queue-6.19/xfs-fix-copy-paste-error-in-previous-fix.patch new file mode 100644 index 0000000000..da9bca73ee --- /dev/null +++ b/queue-6.19/xfs-fix-copy-paste-error-in-previous-fix.patch @@ -0,0 +1,41 @@ +From b9fcdd7f84561a2b49b0b8c28f55b54d2627efab Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 18 Feb 2026 15:25:35 -0800 +Subject: xfs: fix copy-paste error in previous fix + +From: Darrick J. Wong + +[ 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 +--- + fs/xfs/scrub/dir_repair.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/fs/xfs/scrub/dir_repair.c b/fs/xfs/scrub/dir_repair.c +index d5a55eabf6801..e0fa5e6ca1fe8 100644 +--- a/fs/xfs/scrub/dir_repair.c ++++ b/fs/xfs/scrub/dir_repair.c +@@ -177,7 +177,7 @@ xrep_dir_teardown( + rd->dir_names = NULL; + if (rd->dir_entries) + xfarray_destroy(rd->dir_entries); +- rd->dir_names = NULL; ++ rd->dir_entries = NULL; + } + + /* Set up for a directory repair. */ +-- +2.51.0 + diff --git a/queue-6.6/arm64-fix-sampling-the-stable-virtual-counter-in-pre.patch b/queue-6.6/arm64-fix-sampling-the-stable-virtual-counter-in-pre.patch new file mode 100644 index 0000000000..be0a012cc2 --- /dev/null +++ b/queue-6.6/arm64-fix-sampling-the-stable-virtual-counter-in-pre.patch @@ -0,0 +1,54 @@ +From 1d8fd1f094fe0bb79bb4eaf50b0b7c585bb2b999 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 26 Feb 2026 08:22:32 +0000 +Subject: arm64: Fix sampling the "stable" virtual counter in preemptible + section +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Marc Zyngier + +[ 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 +--- + arch/arm64/lib/delay.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +diff --git a/arch/arm64/lib/delay.c b/arch/arm64/lib/delay.c +index 2b6041cc8448f..15a953ac6f0fb 100644 +--- a/arch/arm64/lib/delay.c ++++ b/arch/arm64/lib/delay.c +@@ -32,7 +32,11 @@ static inline unsigned long xloops_to_cycles(unsigned long xloops) + * Note that userspace cannot change the offset behind our back either, + * as the vcpu mutex is held as long as KVM_RUN is in progress. + */ +-#define __delay_cycles() __arch_counter_get_cntvct_stable() ++static cycles_t notrace __delay_cycles(void) ++{ ++ guard(preempt_notrace)(); ++ return __arch_counter_get_cntvct_stable(); ++} + + void __delay(unsigned long cycles) + { +-- +2.51.0 + diff --git a/queue-6.6/series b/queue-6.6/series index 2efe39a818..381023eee6 100644 --- a/queue-6.6/series +++ b/queue-6.6/series @@ -680,3 +680,4 @@ tracing-fix-checking-of-freed-trace_event_file-for-h.patch tracing-wake-up-poll-waiters-for-hist-files-when-rem.patch ntb-ntb_transport-fix-too-small-buffer-for-debugfs_n.patch drm-i915-wakeref-clean-up-intel_wakeref_put_-flag-ma.patch +arm64-fix-sampling-the-stable-virtual-counter-in-pre.patch