From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793267915; b=QTI7p51ynBMs2mLb/WT00Bdm7IoLt+DjKOcRc1YtdMcIXDy7C7+LcAAgXcYdDluYIrHD aElOX12JDansrk2VOfWxAACu0IhgW/kJTynvmyAstU/R/eqUq8BWVAfcT1AafyV+ZTklK /9mB4D74kKFzlG/NAxwjsb/GwsPDgV+Du6mC1LBQq84AkWZTngFqn5Dnbgb6XCk0sr6h1 XLxBq0eSBbivfGqeH8BMcIfOSOybg+kzUC6MjM1Vl2BRZnRit8W47VmT4VodFliQIGAzx sw3ffJCQ2SIdHoHdpFyQaWgInzDCFiN0p9DgXSNB9sxN71J3CQqXX+RT3OZRkdc8wbw== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793267915; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: MIME-Version:Content-Transfer-Encoding; bh=pvyVptf34gNXi8Bay+Y0wQ1+su1zbi4JW/reYBgb1VQ=; b=iXWipHfQ9P8yqBpD1L+ahnnTIzBFtQ7ppqeF9S6cpC9TBDMCC9eQ/2GMzz2KM9H6EUhg 6G7RWEZxcq6f2/Jr60SFJJjBUvWbY4jQJbPgCGMJAmxzuSlD0w7/BJ40ndvsucV9BrQvS iejOUI4ddT/0uxjaK4/vTFQx338G7xmI21OdUZZ7v6SpeYsM3I/IGCgzI9JKm4bMSBJ8G XIbZ8I4Dj3Q6cGQsigL3VhiHO2+Cs8aXbD1Zbse0sTqapXYnptvIa2NddeJZZaR860pjq Z2FxYFZCMoguMfYqseNBTip+zeJTmHrUUdn2PLs9+AA1OqUTR+JnqcHRRZ7IU0v8WRA== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=E9blAECY; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8E047606A31C; Thu, 29 Oct 2026 09:58:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=E9blAECY Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6D52E1F01825; Thu, 29 Oct 2026 09:58:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1793267915; bh=pvyVptf34gNXi8Bay+Y0wQ1+su1zbi4JW/reYBgb1VQ=; h=From:To:Cc:Subject:Date; b=E9blAECYp6KG8AN9sCB1a35WZl4tql7Y8ZXp0RDyDE91uhItcOlCubJTDFxxfFQ1c FQ1oLcDZUFCI5NNc2ysWVgB/YRzMjzSxsJmTuSY+45io7wuL8LjueztYWrgRcpOECH VewapS1H9J02mVTfUi3oCFQKKGmnMRyzM3asO2oNSoHkcLOi0Td6e3tzSkHmyLmid0 hdfX9MCzFdHpolJc2F/hD/ot11Mq8ijC0ZN/oRoyiR3cb6617vJjq0MXOsWWjMlgvu 0oeqVetAnnaBq4kfE+Rq5DaPVbXmQggZR+obBEtf/xce5dNpC92pf3UDffILLhhSf6 rLTIHQ1YDRYGA== From: Philipp Stanner To: Min Ma , Lizhi Hou , Oded Gabbay , "Rob Herring (Arm)" , Tomeu Vizoso , Karol Wachowski , Andrzej Kacprowski , Sumit Semwal , =?UTF-8?q?Christian=20K=C3=B6nig?= , Felix Kuehling , Alex Deucher , David Airlie , Simona Vetter , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Lucas Stach , Russell King , Christian Gmeiner , Jani Nikula , Joonas Lahtinen , Rodrigo Vivi , Tvrtko Ursulin , Alessio Belle , Luigi Santivetti , Qiang Yu , Rob Clark , Dmitry Baryshkov , Abhinav Kumar , Jessica Zhang , Sean Paul , Marijn Suijten , Lyude Paul , Danilo Krummrich , Boris Brezillon , Steven Price , =?UTF-8?q?Adri=C3=A1n=20Larumbe?= , Liviu Dudau , Dave Airlie , Gerd Hoffmann , Matthew Brost , Philipp Stanner , Natalie Vock , Arun Pravin , Matthew Auld , =?UTF-8?q?Thomas=20Hellstr=C3=B6m?= , Melissa Wen , =?UTF-8?q?Ma=C3=ADra=20Canal?= , Dave Stevenson , Raspberry Pi Kernel Maintenance , Dmitry Osipenko , Gurchetan Singh , Chia-I Wu , Zack Rusin , Broadcom internal kernel review list , Thierry Reding , Mikko Perttunen , Jonathan Cameron , David Lechner , =?UTF-8?q?Nuno=20S=C3=A1?= , Andy Shevchenko , Greg Kroah-Hartman , Sunil Khatri , Kees Cook , Jesse Zhang , =?UTF-8?q?Timur=20Krist=C3=B3f?= , Srinivasan Shanmugam , Kexin Sun , Prike Liang , David Rosca , Krzysztof Karas , Marco Crivellari , Shixiong Ou , =?UTF-8?q?Jouni=20H=C3=B6gander?= , Thadeu Lima de Souza Cascardo , Pierre-Eric Pelloux-Prayer , Joel Fernandes , Al Viro , Neill Kapron , Michael Bommarito , Sam Day , Gabriel Prostitis Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, amd-gfx@lists.freedesktop.org, etnaviv@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, imagination@lists.freedesktop.org, lima@lists.freedesktop.org, linux-arm-msm@vger.kernel.org, freedreno@lists.freedesktop.org, nouveau@lists.freedesktop.org, virtualization@lists.linux.dev, spice-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org, linux-tegra@vger.kernel.org, linux-iio@vger.kernel.org, linux-usb@vger.kernel.org Subject: [RFC PATCH 0/6] dma-buf: Phase out is_signaled() race Date: Thu, 29 Oct 2026 10:55:37 +0100 Message-ID: <20261029095542.1526750-3-phasta@kernel.org> X-Mailer: git-send-email 2.56.0 X-Mailing-List: linux-usb@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit dma_fence_is_signaled() can return true *while* the fence is signaling. This has caused explosions before and I guess we can agree that it's just not ideal. The fundamental issue is that the fence-signaled-bit is set under lock protection but read without it. So ideally, we would read it with the lock. This would not change the relative order, i.e. the bit would still be true in the fence callbacks. Christian informs us that taking the lock causes people to complain about performance regressions because the lock-taking shoots down copied cache-lines. (which is weird since it would mean that someone is repeatedly polling on fences instead of just registering a callback to notify himself once it signals) Let's accept the potential for regressions as true for now. Nevertheless, I think I can propose a path towards removing the race: This series suggests taking the lock in dma_fence_is_signaled() *unless* the driver explicitly asks for a check with a race-condition. As a preparation, I allow drivers to set flags when initializing fences. Then, we add a flag with which the driver can switch locking off for that particular function. By default, we let all drivers take the lock. Should we then, in the kernel release process get reports about regressions, we can set the race-flag for the affected driver and restore the old behavior. Should there be no reports, we could phase the flag out again after a few releases, always taking the lock. New users would always see the lock. I put all potentially affected parties on Cc. Please point out if you can already foresee your driver being negatively affected by this. P. Philipp Stanner (6): dma-buf: dma-fence: Add flags parameter to dma_fence_init() dma-buf: dma-fence: Add flag for using 64-bit seqnos dma-buf: Port users of dma_fence_init64() dma-buf: dma-fence: remove dma_fence_init64() dma-buf: dma-fence: Close race in dma_fence_is_signaled() by default drm/nouveau: Remove hacky fence check drivers/accel/amdxdna/amdxdna_ctx.c | 2 +- drivers/accel/ethosu/ethosu_job.c | 2 +- drivers/accel/ivpu/ivpu_job.c | 2 +- drivers/accel/rocket/rocket_job.c | 2 +- drivers/dma-buf/dma-fence-array.c | 2 +- drivers/dma-buf/dma-fence-chain.c | 4 +- drivers/dma-buf/dma-fence.c | 44 +++++------------ drivers/dma-buf/st-dma-fence-chain.c | 2 +- drivers/dma-buf/st-dma-fence-unwrap.c | 2 +- drivers/dma-buf/st-dma-fence.c | 2 +- drivers/dma-buf/st-dma-resv.c | 2 +- drivers/dma-buf/sw_sync.c | 2 +- .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c | 2 +- .../drm/amd/amdgpu/amdgpu_eviction_fence.c | 7 +-- drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 2 +- .../gpu/drm/amd/amdgpu/amdgpu_userq_fence.c | 5 +- .../gpu/drm/amd/amdgpu/amdgpu_vm_tlb_fence.c | 5 +- drivers/gpu/drm/drm_crtc.c | 2 +- drivers/gpu/drm/drm_writeback.c | 2 +- drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 2 +- drivers/gpu/drm/i915/i915_request.c | 2 +- drivers/gpu/drm/i915/i915_sw_fence_work.c | 2 +- drivers/gpu/drm/i915/i915_vma_resource.c | 2 +- .../gpu/drm/i915/selftests/i915_sw_fence.c | 2 +- drivers/gpu/drm/imagination/pvr_ccb.c | 2 +- drivers/gpu/drm/imagination/pvr_queue.c | 2 +- drivers/gpu/drm/lima/lima_sched.c | 2 +- drivers/gpu/drm/msm/msm_fence.c | 2 +- drivers/gpu/drm/nouveau/nouveau_drm.c | 13 ----- drivers/gpu/drm/nouveau/nouveau_fence.c | 4 +- drivers/gpu/drm/panfrost/panfrost_job.c | 2 +- drivers/gpu/drm/panthor/panthor_sched.c | 2 +- drivers/gpu/drm/qxl/qxl_release.c | 2 +- drivers/gpu/drm/radeon/radeon_fence.c | 2 +- drivers/gpu/drm/scheduler/sched_fence.c | 4 +- .../gpu/drm/scheduler/tests/mock_scheduler.c | 2 +- drivers/gpu/drm/ttm/tests/ttm_bo_test.c | 2 +- .../gpu/drm/ttm/tests/ttm_bo_validate_test.c | 2 +- drivers/gpu/drm/v3d/v3d_fence.c | 2 +- drivers/gpu/drm/vc4/vc4_gem.c | 2 +- drivers/gpu/drm/vgem/vgem_fence.c | 2 +- drivers/gpu/drm/virtio/virtgpu_fence.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 2 +- drivers/gpu/drm/xe/xe_hw_fence.c | 2 +- drivers/gpu/drm/xe/xe_oa.c | 2 +- drivers/gpu/drm/xe/xe_preempt_fence.c | 2 +- drivers/gpu/drm/xe/xe_tlb_inval.c | 2 +- drivers/gpu/host1x/fence.c | 2 +- drivers/iio/industrialio-buffer.c | 2 +- drivers/usb/gadget/function/f_fs.c | 2 +- include/linux/dma-fence.h | 48 +++++++++++++++++-- 52 files changed, 115 insertions(+), 105 deletions(-) -- 2.56.0