lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 11 Nov 2014 14:28:49 +0000
From:	Daniel Thompson <daniel.thompson@...aro.org>
To:	Rob Clark <robdclark@...il.com>
CC:	David Airlie <airlied@...ux.ie>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	Benjamin Gaignard <benjamin.gaignard@...aro.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"patches@...aro.org" <patches@...aro.org>,
	linaro-kernel@...ts.linaro.org,
	John Stultz <john.stultz@...aro.org>,
	Sumit Semwal <sumit.semwal@...aro.org>
Subject: Re: [PATCH v3.18-rc3] drm: msm: Allow exported dma-bufs to be mapped

On 10/11/14 17:36, Rob Clark wrote:
> On Mon, Nov 10, 2014 at 12:16 PM, Daniel Thompson
> <daniel.thompson@...aro.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).

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ