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:

quoted

On 10/30/19 12:05 PM, Jesper Dangaard Brouer wrote:

quoted

On Wed, 30 Oct 2019 11:53:21 +0100
Björn Töpel [off-list ref] wrote:

quoted

On Wed, 30 Oct 2019 at 11:43, Jesper Dangaard Brouer [off-list ref] wrote:

[...]

quoted

quoted

quoted

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@quaco perf]$ git tag --contains 06f84d1989b7e58d56fa2e448664585749d41221
perf-core-for-mingo-5.5-20191011
perf-core-for-mingo-5.5-20191021
[acme@quaco 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