netdev - Re: [PATCH bpf 1/2] net/ipv4: fix linux/in.h header dependencies

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:   Mon, 7 Nov 2022 16:56:16 -0800
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Yonghong Song <yhs@...a.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 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.

> >
> > You are awesome, thank you!