The same kind of issue has been fixed in v4l2: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/drivers/media/v4l2-core/videobuf2-core.c?id=c1b96a236e94d49d9396d0bbceb5524519c5c66e I'm ok to add a DRM_RDWR flag, just do not remove the code from sti driver until I have been able to test it. Benjamin 2014-11-11 17:26 GMT+01:00 Rob Clark <robdclark@xxxxxxxxx>: > On Tue, Nov 11, 2014 at 9:28 AM, Daniel Thompson > <daniel.thompson@xxxxxxxxxx> wrote: >> On 10/11/14 17:36, Rob Clark wrote: >>> On Mon, Nov 10, 2014 at 12:16 PM, Daniel Thompson >>> <daniel.thompson@xxxxxxxxxx> wrote: >>>> diff --git a/drivers/gpu/drm/msm/msm_gem_prime.c b/drivers/gpu/drm/msm/msm_gem_prime.c >>>> index ad772fe36115..4e4fa5828d5d 100644 >>>> --- a/drivers/gpu/drm/msm/msm_gem_prime.c >>>> +++ b/drivers/gpu/drm/msm/msm_gem_prime.c >>>> @@ -20,6 +20,14 @@ >>>> >>>> #include <linux/dma-buf.h> >>>> >>>> +struct dma_buf *msm_gem_prime_export(struct drm_device *dev, >>>> + struct drm_gem_object *obj, int flags) >>>> +{ >>>> + /* we want to be able to write in mmapped buffer */ >>>> + flags |= O_RDWR; >>>> + return drm_gem_prime_export(dev, obj, flags); >>>> +} >>>> + >>> >>> seems like this probably should be done more centrally.. and in fact, >>> might be better to have something like this in >>> drm_prime_handle_to_fd_ioctl: >>> >>> /* check flags are valid */ >>> - if (args->flags & ~DRM_CLOEXEC) >>> + if (args->flags & ~(DRM_CLOEXEC | O_RDWR)) >>> return -EINVAL; >>> >>> so exporter can specify whether to allow mmap or not. >> >> That makes sense I'll try this. >> >> Do we need to wrap O_RDWR in the same way we wrap O_CLOEXEC? (I don't >> really understand why DRM_CLOEXEC exists; even the patch description >> from when the symbol was introduced names it O_CLOEXEC). > > I *think* wrapping it w/ DRM_CLOEXEC was mostly just for purposes of > making it clear which flags are appropriate.. probably best to do the > same w/ a DRM_RDWR I guess > > BR, > -R > >> Also the "flags |= O_RDWR" approach is copied from the sti driver. I'll >> share a patch to remove it but that will definitely needs Benjamin's ack >> because it will stop some userspaces working correctly (however I >> suspect that Benjamin may be the only person currently with such a >> userspace and that he can be persuaded not to call it a regression). >> >> >> Daniel. -- Benjamin Gaignard Graphic Working Group Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
