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@xxxxxxxxxxxxxxxxxx> wrote: > > > Quoting Daniel Vetter (2017-08-15 11:49:51) > > >> On Tue, Aug 15, 2017 at 10:42 AM, Tina Zhang <tina.zhang@xxxxxxxxx> 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
