linux/include
Tvrtko Ursulin 506aa8b02a dma-fence: Add safe access helpers and document the rules
Dma-fence objects currently suffer from a potential use after free problem
where fences exported to userspace and other drivers can outlive the
exporting driver, or the associated data structures.

The discussion on how to address this concluded that adding reference
counting to all the involved objects is not desirable, since it would need
to be very wide reaching and could cause unloadable drivers if another
entity would be holding onto a signaled fence reference potentially
indefinitely.

This patch enables the safe access by introducing and documenting a
contract between fence exporters and users. It documents a set of
contraints and adds helpers which a) drivers with potential to suffer from
the use after free must use and b) users of the dma-fence API must use as
well.

Premise of the design has multiple sides:

1. Drivers (fence exporters) MUST ensure a RCU grace period between
signalling a fence and freeing the driver private data associated with it.

The grace period does not have to follow the signalling immediately but
HAS to happen before data is freed.

2. Users of the dma-fence API marked with such requirement MUST contain
the complete access to the data within a single code block guarded by
rcu_read_lock() and rcu_read_unlock().

The combination of the two ensures that whoever sees the
DMA_FENCE_FLAG_SIGNALED_BIT not set is guaranteed to have access to a
valid fence->lock and valid data potentially accessed by the fence->ops
virtual functions, until the call to rcu_read_unlock().

3. Module unload (fence->ops) disappearing is for now explicitly not
handled. That would required a more complex protection, possibly needing
SRCU instead of RCU to handle callers such as dma_fence_release() and
dma_fence_wait_timeout(), where race between
dma_fence_enable_sw_signaling, signalling, and dereference of
fence->ops->wait() would need a sleeping SRCU context.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
Link: https://lore.kernel.org/r/20250610164226.10817-4-tvrtko.ursulin@igalia.com
2025-06-13 08:26:49 +01:00
..
acpi Merge branches 'acpi-processor' and 'acpi-cppc' 2025-05-26 18:37:38 +02:00
asm-generic hyperv-next for v6.16 2025-06-03 08:39:20 -07:00
clocksource
crypto Networking changes for 6.16. 2025-05-28 15:24:36 -07:00
cxl
drm Merge drm/drm-next into drm-misc-next 2025-06-11 09:01:34 +02:00
dt-bindings USB/Thunderbolt changes for 6.16-rc1 2025-06-06 12:45:35 -07:00
hyperv hyperv-next for v6.16 2025-06-03 08:39:20 -07:00
keys
kunit I've recently moved computers (among other things) so I'm sending this from a 2025-05-30 09:15:40 -07:00
kvm KVM: arm64: Resolve vLPI by host IRQ in vgic_v4_unset_forwarding() 2025-05-30 09:11:29 +01:00
linux dma-fence: Add safe access helpers and document the rules 2025-06-13 08:26:49 +01:00
math-emu
media
memory
misc
net Including fixes from CAN, wireless, Bluetooth, and Netfilter. 2025-06-05 12:34:55 -07:00
pcmcia
ras
rdma Linux 6.15 2025-05-26 15:33:52 -03:00
rv
scsi SCSI misc on 20250529 2025-05-29 22:17:52 -07:00
soc - The 3 patch series "hung_task: extend blocking task stacktrace dump to 2025-05-31 19:12:53 -07:00
sound USB/Thunderbolt changes for 6.16-rc1 2025-06-06 12:45:35 -07:00
target
trace dma-fence: Add safe access helpers and document the rules 2025-06-13 08:26:49 +01:00
uapi Merge drm/drm-next into drm-misc-next 2025-06-11 09:01:34 +02:00
ufs
vdso
video fbdev: atyfb: Remove unused PCI vendor ID 2025-05-31 10:24:01 +02:00
xen
Kbuild