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/ 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
