--- /dev/null
+From 47b398be7bfb6227c13815315fbb42c269590930 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+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 <maz@kernel.org>
+
+[ 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 <ben.horgan@arm.com>
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Link: https://lore.kernel.org/r/aZw3EGs4rbQvbAzV@e134344.arm.com
+Tested-by: Ben Horgan <ben.horgan@arm.com>
+Tested-by: André Draszik <andre.draszik@linaro.org>
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
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
--- /dev/null
+From afad9687f5c17b4bdb3173e0ac65c2dfbc5fe5f9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+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 <maz@kernel.org>
+
+[ 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 <ben.horgan@arm.com>
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Link: https://lore.kernel.org/r/aZw3EGs4rbQvbAzV@e134344.arm.com
+Tested-by: Ben Horgan <ben.horgan@arm.com>
+Tested-by: André Draszik <andre.draszik@linaro.org>
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From ebc9e34dcd9e6723a9a8bf7eff47036cf52fe9cc Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 16 Jan 2026 17:29:50 +0100
+Subject: most: core: fix leak on early registration failure
+
+From: Johan Hovold <johan@kernel.org>
+
+[ 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 <christian.gromm@microchip.com>
+Cc: Navaneeth K <knavaneeth786@gmail.com>
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Link: https://patch.msgid.link/20260116162950.21578-1-johan@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
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
--- /dev/null
+From faedd175385d7ad56109a3a93aae1d69bdda45ae Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 18 Feb 2026 15:25:35 -0800
+Subject: xfs: fix copy-paste error in previous fix
+
+From: Darrick J. Wong <djwong@kernel.org>
+
+[ 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 <clm@meta.com>
+Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
+Signed-off-by: Carlos Maiolino <cem@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From aac6413b8e2768ef0fac9bd51be0ba902a0fd17b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+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 <maz@kernel.org>
+
+[ 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 <ben.horgan@arm.com>
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Link: https://lore.kernel.org/r/aZw3EGs4rbQvbAzV@e134344.arm.com
+Tested-by: Ben Horgan <ben.horgan@arm.com>
+Tested-by: André Draszik <andre.draszik@linaro.org>
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From 824507b5eae87a829c579e7cbc042e70bf987e02 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+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 <srinivasan.shanmugam@amd.com>
+
+[ 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 <christian.koenig@amd.com>
+Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
+Reviewed-by: Christian König <christian.koenig@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From 8440564773b67c38299680dba07d018a1af69990 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 16 Jan 2026 17:29:50 +0100
+Subject: most: core: fix leak on early registration failure
+
+From: Johan Hovold <johan@kernel.org>
+
+[ 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 <christian.gromm@microchip.com>
+Cc: Navaneeth K <knavaneeth786@gmail.com>
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Link: https://patch.msgid.link/20260116162950.21578-1-johan@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
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
--- /dev/null
+From b6696822d24ec5d40617b29be442580a99ecb701 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 18 Feb 2026 15:25:35 -0800
+Subject: xfs: fix copy-paste error in previous fix
+
+From: Darrick J. Wong <djwong@kernel.org>
+
+[ 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 <clm@meta.com>
+Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
+Signed-off-by: Carlos Maiolino <cem@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From 8b2c1ed1cafddc152ceb3674bb9c1916e844fee4 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+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 <maz@kernel.org>
+
+[ 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 <ben.horgan@arm.com>
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Link: https://lore.kernel.org/r/aZw3EGs4rbQvbAzV@e134344.arm.com
+Tested-by: Ben Horgan <ben.horgan@arm.com>
+Tested-by: André Draszik <andre.draszik@linaro.org>
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From ea4fcae379ed9a5cfde81fd2975ddd7608c7bacc Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+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 <srinivasan.shanmugam@amd.com>
+
+[ 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 <christian.koenig@amd.com>
+Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
+Reviewed-by: Christian König <christian.koenig@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From 6c51eb23d20e4b52f4f797afec2892a12b4696cb Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 16 Jan 2026 17:29:50 +0100
+Subject: most: core: fix leak on early registration failure
+
+From: Johan Hovold <johan@kernel.org>
+
+[ 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 <christian.gromm@microchip.com>
+Cc: Navaneeth K <knavaneeth786@gmail.com>
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Link: https://patch.msgid.link/20260116162950.21578-1-johan@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From 911f0aa68c3f388567b8a1072b21833c868d6288 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 7 Feb 2026 21:54:55 -0800
+Subject: perf test parse-metric: Ensure aggregate counts appear to have run
+
+From: Ian Rogers <irogers@google.com>
+
+[ 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 <irogers@google.com>
+Cc: Adrian Hunter <adrian.hunter@intel.com>
+Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Cc: Chun-Tse Shao <ctshao@google.com>
+Cc: Ingo Molnar <mingo@redhat.com>
+Cc: James Clark <james.clark@linaro.org>
+Cc: Jiri Olsa <jolsa@kernel.org>
+Cc: Namhyung Kim <namhyung@kernel.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Yang Li <yang.lee@linux.alibaba.com>
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
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
--- /dev/null
+From b9fcdd7f84561a2b49b0b8c28f55b54d2627efab Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 18 Feb 2026 15:25:35 -0800
+Subject: xfs: fix copy-paste error in previous fix
+
+From: Darrick J. Wong <djwong@kernel.org>
+
+[ 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 <clm@meta.com>
+Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
+Signed-off-by: Carlos Maiolino <cem@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From 1d8fd1f094fe0bb79bb4eaf50b0b7c585bb2b999 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+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 <maz@kernel.org>
+
+[ 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 <ben.horgan@arm.com>
+Signed-off-by: Marc Zyngier <maz@kernel.org>
+Link: https://lore.kernel.org/r/aZw3EGs4rbQvbAzV@e134344.arm.com
+Tested-by: Ben Horgan <ben.horgan@arm.com>
+Tested-by: André Draszik <andre.draszik@linaro.org>
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
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
projects / thirdparty / kernel / stable-queue.git / commitdiff
