summaryrefslogtreecommitdiff
path: root/MAINTAINERS
diff options
context:
space:
mode:
authorDaniel Vetter <daniel.vetter@ffwll.ch>2013-08-15 00:02:46 +0200
committerInki Dae <inki.dae@samsung.com>2014-10-15 20:05:12 +0900
commit0e7641b8ae328e7179a49f52b38216a974c2af97 (patch)
tree7007d2eb71791d70fc3ffb70fc2c29a4353cb2b0 /MAINTAINERS
parentb292cfdc7cd475fb805dd80e5b3194ff49107730 (diff)
downloadlinux-3.10-0e7641b8ae328e7179a49f52b38216a974c2af97.tar.gz
linux-3.10-0e7641b8ae328e7179a49f52b38216a974c2af97.tar.bz2
linux-3.10-0e7641b8ae328e7179a49f52b38216a974c2af97.zip
drm/prime: proper locking+refcounting for obj->dma_buf link
The export dma-buf cache is semantically similar to an flink name. So semantically it makes sense to treat it the same and remove the name (i.e. the dma_buf pointer) and its references when the last gem handle disappears. Again we need to be careful, but double so: Not just could someone race and export with a gem close ioctl (so we need to recheck obj->handle_count again when assigning the new name), but multiple exports can also race against each another. This is prevented by holding the dev->object_name_lock across the entire section which touches obj->dma_buf. With the new scheme we also need to reinstate the obj->dma_buf link at import time (in case the only reference userspace has held in-between was through the dma-buf fd and not through any native gem handle). For simplicity we don't check whether it's a native object but unconditionally set up that link - with the new scheme of removing the obj->dma_buf reference when the last handle disappears we can do that. To make it clear that this is not just for exported buffers anymore als rename it from export_dma_buf to dma_buf. To make sure that now one can race a fd_to_handle or handle_to_fd with gem_close we use the same tricks as in flink of extending the dev->object_name_locking critical section. With this change we finally have a guaranteed 1:1 relationship (at least for native objects) between gem objects and dma-bufs, even accounting for races (which can happen since the dma-buf itself holds a reference while in-flight). This prevent igt/prime_self_import/export-vs-gem_close-race from Oopsing the kernel. There is still a leak though since the per-file priv dma-buf/handle cache handling is racy. That will be fixed in a later patch. v2: Remove the bogus dma_buf_put from the export_and_register_object failure path if we've raced with the handle count dropping to 0. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Chanho Park <chanho61.park@samsung.com> Conflicts: drivers/gpu/drm/drm_gem.c Change-Id: I915b0e73cedffa0ba358cf00510e19dccfcb4703
Diffstat (limited to 'MAINTAINERS')
0 files changed, 0 insertions, 0 deletions