netdev - Re: Compile build issues with samples/bpf/ again

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]

Message-ID: <20191031105546.GA24528@pc-63.home>
Date:   Thu, 31 Oct 2019 11:55:46 +0100
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>
Cc:     Daniel Borkmann <borkmann@...earbox.net>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        Björn Töpel <bjorn.topel@...il.com>,
        Alexei Starovoitov <ast@...nel.org>,
        BPF-dev-list <bpf@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Eric Sage <eric@...e.org>,
        Andrii Nakryiko <andrii.nakryiko@...il.com>,
        Arnaldo Carvalho de Melo <acme@...hat.com>,
        Björn Töpel <bjorn.topel@...el.com>,
        Jiri Olsa <jolsa@...hat.com>,
        Toke Høiland-Jørgensen <toke@...hat.com>,
        Ivan Khoronzhuk <ivan.khoronzhuk@...aro.org>,
        Ilias Apalodimas <ilias.apalodimas@...aro.org>
Subject: Re: Compile build issues with samples/bpf/ again

On Wed, Oct 30, 2019 at 12:33:40PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Oct 30, 2019 at 04:07:32PM +0100, Daniel Borkmann escreveu:
> > On 10/30/19 12:05 PM, Jesper Dangaard Brouer wrote:
> > > On Wed, 30 Oct 2019 11:53:21 +0100
> > > Björn Töpel <bjorn.topel@...il.com> wrote:
> > > > On Wed, 30 Oct 2019 at 11:43, Jesper Dangaard Brouer <brouer@...hat.com> wrote:
> > [...]
> > > > > It is annoy to experience that simply building kernel tree samples/bpf/
> > > > > is broken as often as it is.  Right now, build is broken in both DaveM
> > > > > net.git and bpf.git.  ACME have some build fixes queued from Björn
> > > > > Töpel. But even with those fixes, build (for samples/bpf/task_fd_query_user.c)
> > > > > are still broken, as reported by Eric Sage (15 Oct), which I have a fix for.
> > > > 
> > > > Hmm, something else than commit e55190f26f92 ("samples/bpf: Fix build
> > > > for task_fd_query_user.c")?
> > > 
> > > I see, you already fixed this... and it is in the bpf.git tree.
> > > 
> > > Then we only need your other fixes from ACME's tree.  I just cloned a
> > > fresh version of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
> > > to check that 'make M=samples/bpf' still fails.
> > 
> > Correct, the two fixes from Bjorn which made the test_attr__* optional were
> > taken by Arnaldo given the main change was under tools/perf/perf-sys.h. If
> > you cherry pick these ...
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=06f84d1989b7e58d56fa2e448664585749d41221
> > https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=fce9501aec6bdda45ef3a5e365a5e0de7de7fe2d
> > 
> > ... into bpf tree, then all builds fine. When Arnaldo took them, my assumption
> > was that these fixes would have been routed by him to Linus' tree, and upon
> > resync we pull them automatically into bpf tree again.
> > 
> > Look like didn't happen yet at this point, Arnaldo?
> 
> Yes, it will go to Linus, I was just unsure when was that it should go,
> i.e. next or in the current window, so I've queued it up to next.
> 
> [acme@...co perf]$ git tag --contains 06f84d1989b7e58d56fa2e448664585749d41221
> perf-core-for-mingo-5.5-20191011
> perf-core-for-mingo-5.5-20191021
> [acme@...co perf]$
> 
> So its in tip, but queued for 5.5, while I think you guys expect this to
> fast track into 5.4, right? If so, please get that queued up or tell me
> if you prefer for me to do it.

Personally, I don't think it is super critical, but I tend to agree with
Jesper that samples code should compile before final release is out the
door. I can cherry-pick both from tip into bpf tree, no problem. The commit
will end up twice in git history, but we've done this in very rare occasions
in the past to get dependencies into bpf.

> I agree with Jesper that when one changes something in common code, then
> one does have to test all tools/ that may use that common code, but in
> this specific case the breakage happened because tools/perf/ code was
> used outside tools/perf/ which I completely didn't expect to happen,
> whatever that is in tools/perf/perf-sys.h better go to tools/include or
> tools/arch or some other common area, agreed?

Some of the BPF samples code seems to be using sys_perf_event_open(), for
other BPF bits under tools/ this seems not the case.

Thanks,
Daniel