netdev - Re: [PATCH bpf-next v3 11/15] tools/bpf: refactor some net macros to libbpf bpf_tracing

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, 23 Jun 2020 07:56:35 -0700
From:   Yonghong Song <yhs@...com>
To:     Andrii Nakryiko <andrii.nakryiko@...il.com>
CC:     bpf <bpf@...r.kernel.org>, Networking <netdev@...r.kernel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Kernel Team <kernel-team@...com>,
        Martin KaFai Lau <kafai@...com>
Subject: Re: [PATCH bpf-next v3 11/15] tools/bpf: refactor some net macros to
 libbpf bpf_tracing_net.h



On 6/22/20 11:45 PM, Andrii Nakryiko wrote:
> On Mon, Jun 22, 2020 at 5:38 PM Yonghong Song <yhs@...com> wrote:
>>
>> Refactor bpf_iter_ipv6_route.c and bpf_iter_netlink.c
>> so net macros, originally from various include/linux header
>> files, are moved to a new libbpf installable header file
>> bpf_tracing_net.h. The goal is to improve reuse so
>> networking tracing programs do not need to
>> copy these macros every time they use them.
>>
>> Signed-off-by: Yonghong Song <yhs@...com>
>> ---
>>   tools/lib/bpf/Makefile                           |  1 +
>>   tools/lib/bpf/bpf_tracing_net.h                  | 16 ++++++++++++++++
>>   .../selftests/bpf/progs/bpf_iter_ipv6_route.c    |  7 +------
>>   .../selftests/bpf/progs/bpf_iter_netlink.c       |  4 +---
>>   4 files changed, 19 insertions(+), 9 deletions(-)
>>   create mode 100644 tools/lib/bpf/bpf_tracing_net.h
>>
>> diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
>> index bf8ed134cb8a..3d766c80eb78 100644
>> --- a/tools/lib/bpf/Makefile
>> +++ b/tools/lib/bpf/Makefile
>> @@ -257,6 +257,7 @@ install_headers: $(BPF_HELPER_DEFS)
>>                  $(call do_install,bpf_helpers.h,$(prefix)/include/bpf,644); \
>>                  $(call do_install,$(BPF_HELPER_DEFS),$(prefix)/include/bpf,644); \
>>                  $(call do_install,bpf_tracing.h,$(prefix)/include/bpf,644); \
>> +               $(call do_install,bpf_tracing_net.h,$(prefix)/include/bpf,644); \
>>                  $(call do_install,bpf_endian.h,$(prefix)/include/bpf,644); \
>>                  $(call do_install,bpf_core_read.h,$(prefix)/include/bpf,644);
>>
>> diff --git a/tools/lib/bpf/bpf_tracing_net.h b/tools/lib/bpf/bpf_tracing_net.h
>> new file mode 100644
>> index 000000000000..1f38a1098727
>> --- /dev/null
>> +++ b/tools/lib/bpf/bpf_tracing_net.h
>> @@ -0,0 +1,16 @@
>> +/* SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause) */
>> +#ifndef __BPF_TRACING_NET_H__
>> +#define __BPF_TRACING_NET_H__
>> +
>> +#define IFNAMSIZ               16
>> +
>> +#define RTF_GATEWAY            0x0002
>> +
>> +#define fib_nh_dev             nh_common.nhc_dev
>> +#define fib_nh_gw_family       nh_common.nhc_gw_family
>> +#define fib_nh_gw6             nh_common.nhc_gw.ipv6
>> +
>> +#define sk_rmem_alloc          sk_backlog.rmem_alloc
>> +#define sk_refcnt              __sk_common.skc_refcnt
> 
> Question to networking guys. How probable it is for these and similar
> definitions to ever be changed?
> 
> I'm a bit hesitant to make any stability guarantees (which is implied
> by libbpf-provided headers). I don't want us to get into the game of
> trying to maintain this across multiple kernel versions, if they are
> going to be changed.
> 
> Let's for now keep bpf_tracing_net.h under selftests/bpf? It's still
> good to have these definitions, because we can point people to it.

I am using bpf_tracing_net.h name to somehow signal that it may
*potentially* change. But it does have long-time stability issue.
Will move to selftests/bpf then.

> 
>> +
>> +#endif
> 
> [...]
>