diff options
| author | Chris Wilson <chris@chris-wilson.co.uk> | 2019-08-14 19:24:01 +0100 |
|---|---|---|
| committer | Chris Wilson <chris@chris-wilson.co.uk> | 2019-08-16 12:40:58 +0100 |
| commit | b016cd6ed4b772759804e0d6082bd1f5ca63b8ee (patch) | |
| tree | 278f8b1426b40316f5744cd6155ec51ecc9dd6c7 /drivers/dax | |
| parent | dc2e1e5b279966affbd11ff7cfef52eb634ca2c9 (diff) | |
| download | linux-b016cd6ed4b772759804e0d6082bd1f5ca63b8ee.tar.bz2 | |
dma-buf: Restore seqlock around dma_resv updates
This reverts
67c97fb79a7f ("dma-buf: add reservation_object_fences helper")
dd7a7d1ff2f1 ("drm/i915: use new reservation_object_fences helper")
0e1d8083bddb ("dma-buf: further relax reservation_object_add_shared_fence")
5d344f58da76 ("dma-buf: nuke reservation_object seq number")
The scenario that defeats simply grabbing a set of shared/exclusive
fences and using them blissfully under RCU is that any of those fences
may be reallocated by a SLAB_TYPESAFE_BY_RCU fence slab cache. In this
scenario, while keeping the rcu_read_lock we need to establish that no
fence was changed in the dma_resv after a read (or full) memory barrier.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190814182401.25009-1-chris@chris-wilson.co.uk
Diffstat (limited to 'drivers/dax')
0 files changed, 0 insertions, 0 deletions