Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751747AbaKKO3A (ORCPT ); Tue, 11 Nov 2014 09:29:00 -0500 Received: from mail-wi0-f182.google.com ([209.85.212.182]:55636 "EHLO mail-wi0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750980AbaKKO25 (ORCPT ); Tue, 11 Nov 2014 09:28:57 -0500 Message-ID: <54621D21.2000100@linaro.org> Date: Tue, 11 Nov 2014 14:28:49 +0000 From: Daniel Thompson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Rob Clark CC: David Airlie , "dri-devel@lists.freedesktop.org" , Benjamin Gaignard , Linux Kernel Mailing List , "patches@linaro.org" , linaro-kernel@lists.linaro.org, John Stultz , Sumit Semwal Subject: Re: [PATCH v3.18-rc3] drm: msm: Allow exported dma-bufs to be mapped References: <1415639805-17477-1-git-send-email-daniel.thompson@linaro.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/11/14 17:36, Rob Clark wrote: > On Mon, Nov 10, 2014 at 12:16 PM, Daniel Thompson > 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 >> >> +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). 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/