linux-kernel - Re: [PATCH 3/3] arm64/sve: Disentangle <uapi/asm/ptrace.h> from <uapi/asm/sigcontext.h>

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:   Wed, 19 Dec 2018 15:26:52 +0000
From:   Szabolcs Nagy <Szabolcs.Nagy@....com>
To:     Dave P Martin <Dave.Martin@....com>
CC:     nd <nd@....com>, kbuild test robot <lkp@...el.com>,
        Catalin Marinas <Catalin.Marinas@....com>,
        Will Deacon <Will.Deacon@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kbuild-all@...org" <kbuild-all@...org>,
        Alan Hayward <Alan.Hayward@....com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 3/3] arm64/sve: Disentangle <uapi/asm/ptrace.h> from
 <uapi/asm/sigcontext.h>

On 19/12/2018 15:23, Dave Martin wrote:
> On Wed, Dec 19, 2018 at 03:11:52PM +0000, Szabolcs Nagy wrote:
>> On 18/12/2018 12:14, Dave Martin wrote:
>>> On Sat, Dec 15, 2018 at 05:20:29PM +0800, kbuild test robot wrote:
> 
> [...]
> 
>>>>>> ./usr/include/asm/sve_context.h:30: found __[us]{8,16,32,64} type without #include <linux/types.h>
>>>
>>> Since the new header is not meant to be included directly (and has a
>>> guard to that effect), we don't strictly need to do anything here.
>>>
>>> The way to include <asm/sve_context.h> in userspace is via
>>> <asm/sigcontext.h> or <asm/ptrace.h>, both of which include
>>> <linux/types.h> first.
>>>
>>
>> i think there is no need to explicitly prevent the inclusion of
>> the header.
>>
>> it is enough to have a comment that it's not supposed to be
>> included by user code (so the header can be later refactored).
>>
>> and then such automated header checks (or whatever other hacks
>> ppl do temporarily) can continue to work.
> 
> The guard is in linux-next now AFAIK.
> 
> Are you saying that it's likely to break something and needs to be
> removed, or it is unnecessary but harmless?

unnecessary but harmless.

(i assumed the header check bot would want to include every
header on its own and see if there are undefined symbols, but
if it works with the guard then fine)