locking&resource refcounting for ttm_bo_kmap/dma_buf_vmap

Daniel Vetter daniel.vetter at ffwll.ch
Wed Nov 20 11:47:42 UTC 2019


Hi all,

I've been looking at dma_buf_v(un)map, with a goal to standardize
locking for at least dynamic dma-buf exporters/importers, most likely
by requiring dma_resv_lock. And I got questions around how this is
supposed to work, since a big chunk of drivers seem to entirely lack
locking around ttm_bo_kmap. Two big ones:

- ttm_bo_kmap looks at bo->mem to figure out what/where to kmap to get
at that buffer. bo->mem is supposed to be protected with
dma_resv_lock, but at least amgpu/nouveau/radeon/qxl don't grab that
in their prime vmap function.

- between the vmap and vunmap something needs to make sure the backing
storage doesn't move around. I didn't find that either anywhere,
ttm_bo_kmap simply seems to set up the mapping, leaving locking and
refcounting to callers.

- vram helpers have at least locking, but I'm still missing the
refcounting. vmwgfx doesn't bother with vmap.

What am I missing?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


More information about the dri-devel mailing list