Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753180AbbFSPrB (ORCPT ); Fri, 19 Jun 2015 11:47:01 -0400 Received: from mail-wg0-f48.google.com ([74.125.82.48]:35561 "EHLO mail-wg0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750732AbbFSPqw (ORCPT ); Fri, 19 Jun 2015 11:46:52 -0400 Date: Fri, 19 Jun 2015 17:49:36 +0200 From: Daniel Vetter To: Daniel Thompson Cc: David Airlie , linaro-kernel@lists.linaro.org, patches@linaro.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Benjamin Gaignard , Damien Hobson-Garcia Subject: Re: [RESEND PATCH v2 v4.1-rc8 1/2] drm: prime: Honour O_RDWR during prime-handle-to-fd Message-ID: <20150619154936.GF25769@phenom.ffwll.local> Mail-Followup-To: Daniel Thompson , David Airlie , linaro-kernel@lists.linaro.org, patches@linaro.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Benjamin Gaignard , Damien Hobson-Garcia References: <1434721949-25732-1-git-send-email-daniel.thompson@linaro.org> <1434721949-25732-2-git-send-email-daniel.thompson@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1434721949-25732-2-git-send-email-daniel.thompson@linaro.org> X-Operating-System: Linux phenom 4.0.0-rc3+ User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2880 Lines: 80 On Fri, Jun 19, 2015 at 02:52:28PM +0100, Daniel Thompson wrote: > Currently DRM_IOCTL_PRIME_HANDLE_TO_FD rejects all flags except > (DRM|O)_CLOEXEC making it difficult (maybe impossible) for userspace > to mmap() the resulting dma-buf even when this is supported by the > DRM driver. > > It is trivial to relax the restriction and permit read/write access. > This is safe because the flags are seldom touched by drm; mostly they > are passed verbatim to dma_buf calls. > > Signed-off-by: Daniel Thompson > --- > drivers/gpu/drm/drm_prime.c | 9 +++------ > include/uapi/drm/drm.h | 1 + > 2 files changed, 4 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c > index 7fec191b45f7..6d2cf4fb4038 100644 > --- a/drivers/gpu/drm/drm_prime.c > +++ b/drivers/gpu/drm/drm_prime.c > @@ -331,7 +331,7 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops = { > * drm_gem_prime_export - helper library implementation of the export callback > * @dev: drm_device to export from > * @obj: GEM object to export > - * @flags: flags like DRM_CLOEXEC > + * @flags: flags like DRM_CLOEXEC and DRM_RDWR > * > * This is the implementation of the gem_prime_export functions for GEM drivers > * using the PRIME helpers. > @@ -639,14 +639,11 @@ int drm_prime_handle_to_fd_ioctl(struct drm_device *dev, void *data, > return -ENOSYS; > > /* check flags are valid */ > - if (args->flags & ~DRM_CLOEXEC) > + if (args->flags & ~(DRM_CLOEXEC | DRM_RDWR)) > return -EINVAL; I think we should reject DRM_RDWR if there's no mmap implementation in the underlying dma-buf vfunc table. Or in the gem version of those. Otherwise looks ok to me, if we first resolve the dma-buf userspace mmap coherency issue. -Daniel > > - /* we only want to pass DRM_CLOEXEC which is == O_CLOEXEC */ > - flags = args->flags & DRM_CLOEXEC; > - > return dev->driver->prime_handle_to_fd(dev, file_priv, > - args->handle, flags, &args->fd); > + args->handle, args->flags, &args->fd); > } > > int drm_prime_fd_to_handle_ioctl(struct drm_device *dev, void *data, > diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h > index ff6ef62d084b..092fe3fa8ec0 100644 > --- a/include/uapi/drm/drm.h > +++ b/include/uapi/drm/drm.h > @@ -668,6 +668,7 @@ struct drm_set_client_cap { > __u64 value; > }; > > +#define DRM_RDWR O_RDWR > #define DRM_CLOEXEC O_CLOEXEC > struct drm_prime_handle { > __u32 handle; > -- > 2.4.3 > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/