[Intel-gfx] [PATCH] drm/i915: Return -EPERM when i915_gem_mmap_ioctl handling prime objects

[Chris Wilson]

Quoting Chris Wilson (2017-08-15 15:32:41)
> Quoting Daniel Vetter (2017-08-15 15:25:46)
> > On Tue, Aug 15, 2017 at 3:18 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > > Quoting Daniel Vetter (2017-08-15 11:49:51)
> > >> On Tue, Aug 15, 2017 at 10:42 AM, Tina Zhang <tina.zhang at intel.com> wrote:
> > >> > Prime objects have no backing filp to GEM mmap pages from. So, for Prime
> > >> > objects, such operation is not permitted.
> > >>
> > >> EPERM is when you don't have enough permissions, but it's possible
> > >> (e.g. a feature requiring root, or drm master). -EINVAL is if
> > >> something is invalid, and not even root can change that. So from a
> > >> consistency pov, EINVAL is the right error code here I think.
> > >
> > > Consistency is that we wanted the same error code for all objects where
> > > you did not have the ability to change the underlying storage.
> > >
> > > The question is that an access issue or a permission issue. But at the
> > > very least, mmap_ioctl is the odd one out. Which the changelog did not
> > > explain and being sent out of context does not help.
> > 
> > Which other ioctl give you an EPERM for something that doesn't even
> > work when you're root and/or drm master or whatever it is that gives
> > you permission? I thought we've been pretty consistent with that one
> > ...
> 
> https://patchwork.freedesktop.org/series/28709/

Oops, https://patchwork.freedesktop.org/series/27844/
 
> Short story is that we add a new set of second class GEM objects that
> are not allowed to change the backing storage or details of the PTE.
> 
> Not happy about the dysfunctional GEM objects, but we do want a clear
> and consistent indication as to why we start rejecting certain ioctls.
> -Chris