linux-kernel - Re: [RFC 1/6] drm/fence: add FENCE

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] [day] [month] [year] [list]

Date:	Tue, 5 Apr 2016 11:23:02 -0400
From:	Rob Clark <robdclark@...il.com>
To:	Daniel Stone <daniel@...ishbar.org>
Cc:	Gustavo Padovan <gustavo@...ovan.org>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	Arve Hjønnevåg <arve@...roid.com>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Riley Andrews <riandrews@...roid.com>,
	Gustavo Padovan <gustavo.padovan@...labora.co.uk>,
	John Harrison <John.C.Harrison@...el.com>
Subject: Re: [RFC 1/6] drm/fence: add FENCE_FD property to planes

On Tue, Apr 5, 2016 at 10:19 AM, Daniel Stone <daniel@...ishbar.org> wrote:
>
>> hmm, I'm assuming that the in/out arrays are handled in
>> drm_mode_atomic_ioctl() and the drivers never see 'em..
>
> True, but it complicates the (already not hugely straightforward)
> parsing that the ioctl has to do. It also makes extending the ioctl a
> little harder to do in future, because you're adding in two
> variable-size elements, and have to do some fairly complicated parsing
> to even figure out what the size _should_ be. So I'd rather not do it
> if there was any way out of it; at the very least it'd have to be
> userptr rather than array.


oh, I was assuming ptr to a user array (rather than var length ioctl
struct) for both in and out fences.  I guess my wording didn't make
that clear.  But yeah, it would be madness to do anything else.

BR,
-R