From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 21F5E2E54A2 for ; Sun, 1 Mar 2026 01:47:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772329646; cv=none; b=hcTylTl/Dy+Fp8ZwZk9e6xTj1ZxZ6Oxwjs9zVRwZsfCrLcNJL09A9fEh23WYr97rSa3lGajoxoDDSCi0Ct2bjfjhd1jNtFYLNB5rXorX+BGLMRACUjMPZy/VDTQXDi1M5hpVYl54heQGCNTRIWFkH7+OEWyExQjOgqhX0mza9f0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772329646; c=relaxed/simple; bh=wsWjtfWvIcz7YVPfNQwIX0YxoHhV19xwVBZwDRq4I1g=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=BOfY7TWLCsIsKVueWqiXRixllEUzpA6Rv86oi/l2XiP+IRfzu4r4Q6Egc+0mVdF8K+iAjg9SbcCmQB5etIiu5y1ptC9ZyHYievPcWUGN3oL2xH6WW8qDzyCHRbSZ3QMXeEU0qARK6JVYy2LhBO9FEitWm75oSTq2do0UDmz8CtU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Eq9rbTm1; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Eq9rbTm1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5728CC19421; Sun, 1 Mar 2026 01:47:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772329646; bh=wsWjtfWvIcz7YVPfNQwIX0YxoHhV19xwVBZwDRq4I1g=; h=From:To:Cc:Subject:Date:From; b=Eq9rbTm1OpI4/btO7nHUHk3pGPUNOrLHCi62HgPB3EFZ7V62O/8X4NSwFy4awvRD2 hA3Yh52m7UUpoMoslYwtzuEONyXdeqf/OX0bBGCBp2GTdYvwq/zjWQn0R33c6cAGVM 9VO0zNOilJdZRknZukkopmtviFIXqeHQgGsqP57WyQAwMxAer5bL4cYnpoCxmIB0A6 dBTLcbWRGgC9Xqs9C6hny3TR+itaDXHdiS+YeKLYHNNDMANRwZtee9JJQqzV4FV8kw Sic6AFthcGWTALKOYZunhMX1aZE5R7yGeq0Tihwa0pkh5FXirPBmy6l0VZa5q9cutM 1AoYBeF+6SJFg== From: Sasha Levin To: stable@vger.kernel.org, pierre-eric.pelloux-prayer@amd.com Cc: =?UTF-8?q?Christian=20K=C3=B6nig?= , Alex Deucher , amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org Subject: FAILED: Patch "drm/amdgpu: fix sync handling in amdgpu_dma_buf_move_notify" failed to apply to 6.1-stable tree Date: Sat, 28 Feb 2026 20:47:23 -0500 Message-ID: <20260301014724.1711344-1-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Patchwork-Hint: ignore X-stable: review Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to . Thanks, Sasha ------------------ original commit in Linus's tree ------------------ >From b18fc0ab837381c1a6ef28386602cd888f2d9edf Mon Sep 17 00:00:00 2001 From: Pierre-Eric Pelloux-Prayer Date: Mon, 9 Feb 2026 18:54:45 +0100 Subject: [PATCH] drm/amdgpu: fix sync handling in amdgpu_dma_buf_move_notify MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Invalidating a dmabuf will impact other users of the shared BO. In the scenario where process A moves the BO, it needs to inform process B about the move and process B will need to update its page table. The commit fixes a synchronisation bug caused by the use of the ticket: it made amdgpu_vm_handle_moved behave as if updating the page table immediately was correct but in this case it's not. An example is the following scenario, with 2 GPUs and glxgears running on GPU0 and Xorg running on GPU1, on a system where P2P PCI isn't supported: glxgears: export linear buffer from GPU0 and import using GPU1 submit frame rendering to GPU0 submit tiled->linear blit Xorg: copy of linear buffer The sequence of jobs would be: drm_sched_job_run # GPU0, frame rendering drm_sched_job_queue # GPU0, blit drm_sched_job_done # GPU0, frame rendering drm_sched_job_run # GPU0, blit move linear buffer for GPU1 access # amdgpu_dma_buf_move_notify -> update pt # GPU0 It this point the blit job on GPU0 is still running and would likely produce a page fault. Cc: stable@vger.kernel.org Fixes: a448cb003edc ("drm/amdgpu: implement amdgpu_gem_prime_move_notify v2") Signed-off-by: Pierre-Eric Pelloux-Prayer Reviewed-by: Christian König Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c index b9c38a4fe546a..656c267dbe587 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c @@ -514,8 +514,15 @@ amdgpu_dma_buf_move_notify(struct dma_buf_attachment *attach) r = dma_resv_reserve_fences(resv, 2); if (!r) r = amdgpu_vm_clear_freed(adev, vm, NULL); + + /* Don't pass 'ticket' to amdgpu_vm_handle_moved: we want the clear=true + * path to be used otherwise we might update the PT of another process + * while it's using the BO. + * With clear=true, amdgpu_vm_bo_update will sync to command submission + * from the same VM. + */ if (!r) - r = amdgpu_vm_handle_moved(adev, vm, ticket); + r = amdgpu_vm_handle_moved(adev, vm, NULL); if (r && r != -EBUSY) DRM_ERROR("Failed to invalidate VM page tables (%d))\n", -- 2.51.0