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  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:   Fri, 16 Oct 2020 14:18:53 +0800
From:   Yuehaibing <>
To:     Alexei Starovoitov <>,
        Jakub Kicinski <>
CC:     "David S. Miller" <>,
        Alexei Starovoitov <>,
        Daniel Borkmann <>,
        Martin KaFai Lau <>,
        Song Liu <>, Yonghong Song <>,
        Andrii Nakryiko <>,
        John Fastabend <>,
        KP Singh <>,
        Masahiro Yamada <>,
        Network Development <>,
        bpf <>, LKML <>
Subject: Re: [PATCH] bpfilter: Fix build error with CONFIG_BPFILTER_UMH

On 2020/10/16 3:57, Alexei Starovoitov wrote:
> On Thu, Oct 15, 2020 at 12:26 PM Jakub Kicinski <> wrote:
>> On Thu, 15 Oct 2020 12:03:14 -0700 Alexei Starovoitov wrote:
>>> On Thu, Oct 15, 2020 at 11:56 AM Jakub Kicinski <> wrote:
>>>> How so? It's using in-tree headers instead of system ones.
>>>> Many samples seem to be doing the same thing.
>>> There is no such thing as "usr/include" in the kernel build and source trees.
>> Hm. I thought bpfilter somehow depends on make headers. But it doesn't
>> seem to. Reverting now.
> Thanks!
> Right. To explain it a bit further for the author of the patch:
> Some samples makefiles use this -I usr/include pattern.
> That's different. This local "usr/include" is a result of 'make
> headers_install'.

I didn't notice this, sorry for the wrong fix.

> For samples and such it's ok to depend on that, but bpfilter is
> the part of the kernel build.
> It cannot depend on the 'make headers_install' step,
> so the fix has to be different.

Yes, this should rework.

>>>>> Also please don't take bpf patches.
>>>> You had it marked it as netdev in your patchwork :/
>>> It was delegated automatically by the patchwork system.
>>> I didn't have time to reassign, but you should have known better
>>> when you saw 'bpfilter' in the subject.
>> The previous committers for bpfilter are almost all Dave, so I checked
>> your patchwork to make sure and it was netdev...
> It was my fault. I was sloppy in the past and didn't pay enough attention
> to bpfilter and it started to bitrot because Dave was applying patches
> with his normal SLAs while I was silent.
> .

Powered by blists - more mailing lists