diff options
| author | Daniel Vetter <[email protected]> | 2020-05-14 22:11:17 +0200 |
|---|---|---|
| committer | Daniel Vetter <[email protected]> | 2020-06-03 14:48:26 +0200 |
| commit | 8b6b7d84bfce9a2a29e66147d7acafd0be9bb211 (patch) | |
| tree | 1d0d460c873fac339c1a9d9a07a7c624058225e7 /tools/perf/scripts/python/netdev-times.py | |
| parent | e954f77f6330028ced7bac4ad22ea69ed64e5725 (diff) | |
drm/msm: Don't call dma_buf_vunmap without _vmap
I honestly don't exactly understand what's going on here, but the
current code is wrong for sure: It calls dma_buf_vunmap without ever
calling dma_buf_vmap.
What I'm not sure about is whether the WARN_ON is correct:
- msm imports dma-buf using drm_prime_sg_to_page_addr_arrays. Which is
a pretty neat layering violation of how you shouldn't peek behind
the curtain of the dma-buf exporter, but par for course. Note that
all the nice new helpers don't (and we should probably have a bit a
warning about this in the kerneldoc).
- but then in the get_vaddr() in msm_gem.c, we seems to happily wrap a
vmap() around any object with ->pages set (so including imported
dma-buf).
- I'm not seeing any guarantees that userspace can't use an imported
dma-buf for e.g. MSM_SUBMIT_CMD_BUF in a5xx_submit_in_rb, so no
guarantees that an imported dma-buf won't end up with a ->vaddr set.
But even if that WARN_ON is wrong, cleaning up a vmap() done by msm by
calling dma_buf_vunmap is the wrong thing to do.
v2: Rob said in review that we do indeed have a gap in get_vaddr() that
needs to be plugged. But the users I've found aren't legit users on
imported dma-buf, so we can just reject that.
Reviewed-by: Rob Clark <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Cc: Rob Clark <[email protected]>
Cc: Sean Paul <[email protected]>
Cc: [email protected]
Cc: [email protected]
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Diffstat (limited to 'tools/perf/scripts/python/netdev-times.py')
0 files changed, 0 insertions, 0 deletions