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:   Fri, 19 Aug 2016 19:11:36 +0200
From:   Daniel Vetter <daniel@...ll.ch>
To:     Marek Olšák <maraeo@...il.com>
Cc:     Mikko Rapeli <mikko.rapeli@....fi>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>
Subject: Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and
 __u64 from <linux/types.h>"

On Fri, Aug 19, 2016 at 5:22 PM, Marek Olšák <maraeo@...il.com> wrote:
> On Fri, Aug 19, 2016 at 4:52 PM, Mikko Rapeli <mikko.rapeli@....fi> wrote:
>> On Fri, Aug 19, 2016 at 04:26:40PM +0200, Christian König wrote:
>>> Am 19.08.2016 um 15:50 schrieb Marek Olšák:
>>> >From: Marek Olšák <marek.olsak@....com>
>>> >
>>> >This reverts commit 2ce9dde0d47f2f94ab25c73a30596a7328bcdf1f.
>>> >
>>> >See the comment in the code. Basically, don't do cleanups in this header.
>>> >
>>> >Signed-off-by: Marek Olšák <marek.olsak@....com>
>>>
>>> I completely agree with you that this was a bad move, but I fear that we
>>> will run into opposition with that.
>>>
>>> Adding Mikko Rapeli who made the reverted patch to comment.
>>
>> But this header is part of Linux kernel uapi. Remove it from there too then.
>
> That's a good idea, but it really is a uapi header in the sense that
> it defines the kernel driver interface for a specific kernel version.
> However, it is not a header that the userspace stack should include,
> because userspace should get it from libdrm. (it makes userspace more
> independent from the currently running kernel)

Please don't remove it from the kernel side if it's included in
libdrm. Emil&I just spent a bit of time making sure those two sets of
headers match when we produce them using the make headers_install
target.

drm is indeed special, as in our headers aren't shipped with the
kernel-headers package but libdrm. But otherwise they are supposed to
work exactly like any other uapi headers. No need to move them out of
the uapi headers - I'd even say that would be bad since it removes the
visibility and clear marker that this header must be considered uapi!

Also the very loud comment at the top is definitely misleading,
there's nothing that guarnatees that the libdrm and kernel copy are in
sync when you build or run userspace. Also maybe for context, but what
exactly  is the problem with the __ types?

Adding Emil.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ