[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