netdev - Re: [PATCH bpf] tools: bpftool: fix compilation with older headers

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:   Tue, 6 Mar 2018 16:03:25 +0100
From:   Jiri Benc <jbenc@...hat.com>
To:     Daniel Borkmann <daniel@...earbox.net>
Cc:     netdev@...r.kernel.org, Alexei Starovoitov <ast@...nel.org>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>
Subject: Re: [PATCH bpf] tools: bpftool: fix compilation with older headers

On Tue, 6 Mar 2018 15:39:07 +0100, Daniel Borkmann wrote:
> Thanks for the fix, Jiri! The standard approach to resolve such header dependencies under
> tools/ would be to add a copy of magic.h uapi header into tools/include/uapi/linux/magic.h.
> 
> Both bpftool and libbpf have tools/include/uapi/ in their include path from their
> Makefile, so they would pull this in automatically and it would also allow to get rid
> of the extra ifdef in libbpf then. Could you look into that?

That's what I tried at first. But honestly, this is a shortcut to hell.
Eventually, we'd end up with most of uapi headers duplicated under
tools/include/uapi and hopelessly out of sync.

The right approach would be to export uapi headers from the currently
built kernel somewhere (a temporary directory, perhaps) and use that to
build the tools. We should not have duplicated and out of sync headers
in the kernel tree. Just look at the git log for tools/include/uapi to
see what I mean by "out of sync".

But that's certainly not a fix suitable for bpf.git, while I think the
build problem should be fixed in bpf.git. We can do something more
clever in bpf-next.

I can of course add the magic.h header if you have strong opinion about
that. I just don't think it's the right approach and seeing the
precedent in tools/lib/bpf/libbpf.c and tools/lib/api/fs/fs.c, I think
this minimal patch is better at this point until the duplicate headers
mess is sorted out.

Please let me know if you really want me to duplicate the magic.h file.

Thanks,

 Jiri