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

Chris Wilson chris at chris-wilson.co.uk
Fri Aug 18 08:21:11 UTC 2017


Quoting Laurent Pinchart (2017-08-18 09:01:38)
> Hi Daniel,
> 
> On Friday 18 Aug 2017 09:45:48 Daniel Vetter wrote:
> > On Fri, Aug 18, 2017 at 01:35:41AM +0300, Laurent Pinchart wrote:
> > > Fair enough. I wonder, however, why mmap()ing an imported buffer through
> > > the dumb buffers API is an invalid use case, while doing the same through
> > > the driver-specific buffer API isn't.
> > 
> > Because i915 is special. Our offset-based mmap goes throug the gart, and
> > for that all we need is to dma-map the sg table, which is the primary
> > use-case for dma-buf. Which means we can always do that. But yeah it's
> > special.
> 
> I'll take this as meaning that i915 shouldn't allow this use case, but does 
> and will need to continue doing so because we can't break userspace (it would 
> be nice to start moving userspace away from mmap()ing imported buffers 
> though).

We do like pretend ingthat all GEM handles userspace has are equal. Partly
this is due to the lack of side-channels in protocols like DRI2/DRI3 where
all shared buffers must be fully capable or else either party may die in
weird ways. Keeping everything first class allows for a simple agnostic
userspace. Alas that is not the case, but the one thing we do have atm
is that we can rely on using a mmap via the GTT. If we throw that out
the window, we have teach all of our userspace about transfer buffers as
the final fallback. (Yes, history repeats.)
-Chris


More information about the dri-devel mailing list