All of lore.kernel.org
 help / color / mirror / Atom feed
* Independence for dma_fences! v7
@ 2026-02-10 10:01 Christian König
  2026-02-10 10:01 ` [PATCH 1/8] dma-buf: protected fence ops by RCU v5 Christian König
                   ` (7 more replies)
  0 siblings, 8 replies; 34+ messages in thread
From: Christian König @ 2026-02-10 10:01 UTC (permalink / raw)
  To: phasta, matthew.brost, sumit.semwal; +Cc: dri-devel, linaro-mm-sig

Hi everyone,

dma_fences have ever lived under the tyranny dictated by the module
lifetime of their issuer, leading to crashes should anybody still holding
a reference to a dma_fence when the module of the issuer was unloaded.

The basic problem is that when buffer are shared between drivers
dma_fence objects can leak into external drivers and stay there even
after they are signaled. The dma_resv object for example only lazy releases
dma_fences.

So what happens is that when the module who originally created the dma_fence
unloads the dma_fence_ops function table becomes unavailable as well and so
any attempt to release the fence crashes the system.

Previously various approaches have been discussed, including changing the
locking semantics of the dma_fence callbacks (by me) as well as using the
drm scheduler as intermediate layer (by Sima) to disconnect dma_fences
from their actual users, but none of them are actually solving all problems.

Tvrtko did some really nice prerequisite work by protecting the returned
strings of the dma_fence_ops by RCU. This way dma_fence creators where
able to just wait for an RCU grace period after fence signaling before
they could be save to free those data structures.

Now this patch set here goes a step further and protects the whole
dma_fence_ops structure by RCU, so that after the fence signals the
pointer to the dma_fence_ops is set to NULL when there is no wait nor
release callback given. All functionality which use the dma_fence_ops
reference are put inside an RCU critical section, except for the
deprecated issuer specific wait and of course the optional release
callback.

Additional to the RCU changes the lock protecting the dma_fence state
previously had to be allocated external. This set here now changes the
functionality to make that external lock optional and allows dma_fences
to use an inline lock and be self contained.

v4:

Rebases the whole set on upstream changes, especially the cleanup
from Philip in patch "drm/amdgpu: independence for the amdkfd_fence!".

Adding two patches which brings the DMA-fence self tests up to date.
The first selftest changes removes the mock_wait and so actually starts
testing the default behavior instead of some hacky implementation in the
test. This one got upstreamed independent of this set.
The second drops the mock_fence as well and tests the new RCU and inline
spinlock functionality.

v5:

Rebase on top of drm-misc-next instead of drm-tip, leave out all driver
changes for now since those should go through the driver specific paths
anyway.

Address a few more review comments, especially some rebase mess and
typos. And finally fix one more bug found by AMDs CI system.

v6:

Minor style changes, re-ordered patch #1, dropped the scheduler fence
change for now

v7:

The patch adding the dma_fence_was_initialized() function was pushed
upstream individually since that is really an independent cleanup.

Fixed some missing i915 bits in patch "dma-buf: abstract fence locking".

Please review and comment,
Christian.


^ permalink raw reply	[flat|nested] 34+ messages in thread
[parent not found: <20260219160822.1529-1-christian.koenig@amd.com>]

end of thread, other threads:[~2026-02-19 16:08 UTC | newest]

Thread overview: 34+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-02-10 10:01 Independence for dma_fences! v7 Christian König
2026-02-10 10:01 ` [PATCH 1/8] dma-buf: protected fence ops by RCU v5 Christian König
2026-02-11 10:06   ` Philipp Stanner
2026-02-11 15:43     ` Christian König
2026-02-12  8:56       ` Philipp Stanner
2026-02-19 10:23         ` Christian König
2026-02-19 10:35           ` Philipp Stanner
2026-02-19 12:49             ` Christian König
2026-02-12  9:03       ` Tvrtko Ursulin
2026-02-12  9:31   ` Tvrtko Ursulin
2026-02-13 14:20   ` Boris Brezillon
2026-02-10 10:01 ` [PATCH 2/8] dma-buf: detach fence ops on signal v2 Christian König
2026-02-13 14:22   ` Boris Brezillon
2026-02-19 12:52     ` Christian König
2026-02-19 15:49       ` Boris Brezillon
2026-02-10 10:01 ` [PATCH 3/8] dma-buf: abstract fence locking v2 Christian König
2026-02-12  9:07   ` Tvrtko Ursulin
2026-02-10 10:01 ` [PATCH 4/8] dma-buf: inline spinlock for fence protection v4 Christian König
2026-02-11  9:50   ` Philipp Stanner
2026-02-11 14:59     ` Christian König
2026-02-12  9:01       ` Philipp Stanner
2026-02-12  9:16   ` Tvrtko Ursulin
2026-02-13 14:27   ` Boris Brezillon
2026-02-15  8:48     ` Boris Brezillon
2026-02-16  7:33     ` Philipp Stanner
2026-02-16  9:48       ` Boris Brezillon
2026-02-10 10:02 ` [PATCH 5/8] dma-buf/selftests: test RCU ops and inline lock v2 Christian König
2026-02-10 10:02 ` [PATCH 6/8] dma-buf: use inline lock for the stub fence v2 Christian König
2026-02-13 14:32   ` Boris Brezillon
2026-02-10 10:02 ` [PATCH 7/8] dma-buf: use inline lock for the dma-fence-array Christian König
2026-02-13 14:33   ` Boris Brezillon
2026-02-10 10:02 ` [PATCH 8/8] dma-buf: use inline lock for the dma-fence-chain Christian König
2026-02-13 14:33   ` Boris Brezillon
     [not found] <20260219160822.1529-1-christian.koenig@amd.com>
2026-02-19 16:07 ` Christian König

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.