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:   Mon, 7 Nov 2022 17:08:05 -0800
From:   Yonghong Song <yhs@...a.com>
To:     Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc:     patchwork-bot+netdevbpf@...nel.org,
        Andrii Nakryiko <andrii@...nel.org>, bpf@...r.kernel.org,
        ast@...nel.org, daniel@...earbox.net, netdev@...r.kernel.org,
        kuba@...nel.org, kernel-team@...com, gustavoars@...nel.org
Subject: Re: [PATCH bpf 1/2] net/ipv4: fix linux/in.h header dependencies



On 11/7/22 4:56 PM, Andrii Nakryiko wrote:
> On Thu, Nov 3, 2022 at 9:18 AM Yonghong Song <yhs@...a.com> wrote:
>>
>>
>>
>> On 11/3/22 5:50 AM, patchwork-bot+netdevbpf@...nel.org wrote:
>>> Hello:
>>>
>>> This series was applied to bpf/bpf.git (master)
>>> by Daniel Borkmann <daniel@...earbox.net>:
>>>
>>> On Wed, 2 Nov 2022 11:25:16 -0700 you wrote:
>>>> __DECLARE_FLEX_ARRAY is defined in include/uapi/linux/stddef.h but
>>>> doesn't seem to be explicitly included from include/uapi/linux/in.h,
>>>> which breaks BPF selftests builds (once we sync linux/stddef.h into
>>>> tools/include directory in the next patch). Fix this by explicitly
>>>> including linux/stddef.h.
>>>>
>>>> Given this affects BPF CI and bpf tree, targeting this for bpf tree.
>>>>
>>>> [...]
>>>
>>> Here is the summary with links:
>>>     - [bpf,1/2] net/ipv4: fix linux/in.h header dependencies
>>>       https://git.kernel.org/bpf/bpf/c/aec1dc972d27
>>>     - [bpf,2/2] tools headers uapi: pull in stddef.h to fix BPF selftests build in CI
>>>       https://git.kernel.org/bpf/bpf/c/a778f5d46b62
>>
>> Can we put this patch set into bpf-next as well? Apparently we have the
>> same issue in bpf-next.
>>
> 
> Unfortunately we can't because they are already in bpf, and if we have
> them in bpf-next, they will cause merge conflicts. So I currently
> cherry-pick those two patches locally when compiling selftests. This
> should hopefully will be fixed soon and bpf and bpf-next will
> converge.

Thanks. This should be fine. I guess most people will do the same
thing (cherry-pick locally).

> 
>>>
>>> You are awesome, thank you!

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ