The same kind of issue has been fixed in v4l2:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/driver...
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@gmail.com:
On Tue, Nov 11, 2014 at 9:28 AM, Daniel Thompson daniel.thompson@linaro.org wrote:
On 10/11/14 17:36, Rob Clark wrote:
On Mon, Nov 10, 2014 at 12:16 PM, Daniel Thompson daniel.thompson@linaro.org 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.