locking&resource refcounting for ttm_bo_kmap/dma_buf_vmap

[Christian König]

> What am I missing?
The assumption is that when you want to create a vmap of a DMA-buf 
buffer the buffer needs to be pinned somehow.

E.g. without dynamic dma-buf handling you would need to have an active 
attachment. With dynamic handling the requirements could be lowered to 
using the pin()/unpin() callbacks.

You also can't lock/unlock inside your vmap callback because you don't 
have any guarantee that the pointer stays valid as soon as your drop 
your lock.

BTW: What is vmap() still used for?

Regards,
Christian.

Am 20.11.19 um 12:47 schrieb Daniel Vetter:
> 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