[PATCH v3 1/2] drm/gem: drm_gem_dumb_map_offset(): reject dma-buf

[Daniel Vetter]

On Fri, Aug 18, 2017 at 10:41:21AM -0700, Eric Anholt wrote:
> Noralf Trønnes <noralf at tronnes.org> writes:
> > Den 18.08.2017 09.46, skrev Daniel Vetter:
> >> On Thu, Aug 17, 2017 at 06:21:30PM +0200, Noralf Trønnes wrote:
> >>> Reject mapping an imported dma-buf since is's an invalid use-case.
> >>>
> >>> Cc: Philipp Zabel <p.zabel at pengutronix.de>
> >>> Cc: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
> >>> Cc: Sean Paul <seanpaul at chromium.org>
> >>> Cc: Daniel Vetter <daniel.vetter at ffwll.ch>
> >>> Signed-off-by: Noralf Trønnes <noralf at tronnes.org>
> >> I think acks from someone using mali would be good too. amdgpu already has
> >> such checks, so I think on the desktop side we're ok.
> >>
> >> Acked-by: Daniel Vetter <daniel.vetter at ffwll.ch>
> >>
> >> But I think this one here definitely needs a few more acks. I could break
> >> uabi if we're unlucky, so let's not rush it.
> >
> > Ok, I've CC'ed the affected parties to increase the odds that they look
> > at this. These are the drivers using drm_gem_dumb_map_offset()
> > (hopefully I got the list right):
> 
> If I understand the affected path right, this would break the PL111+VC4
> combination: PL111 makes (dumb) buffers for scanout, and VC4 imports
> them and uses them for rendering.  A vc4 glReadPixels of the window
> system buffer would map it and fail.

It only rejects the map call on dumb buffers, and mmap on imported dma-buf
tends to not really work well, or at least break a few abstractions. Are
you sure this works currently?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch