On Tue, Aug 15, 2017 at 4:35 PM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > 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. I guess two questions: - Does userspace really care about the different return value? Or is the use case more that we have very specific userspace which knows not to do stupid things with these special gvt dma-bufs? If no, then I'd go with EINVAL + DRM_DEBUG_DRIVER. - If we need that special errno, can we take something else? EPERM imo has fairly specific meaning. ENODEV/ENOTTY are more the "not supported on this thing" error codes, if we need a special one. They also have other meanings attached already, but then everything excpe EINVAL has when we do an ioctl, since the vfs can already throw these at you anyway. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
