[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200531151039.GA881900@krava>
Date: Sun, 31 May 2020 17:10:39 +0200
From: Jiri Olsa <jolsa@...hat.com>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc: Alexei Starovoitov <alexei.starovoitov@...il.com>,
Jiri Olsa <jolsa@...nel.org>,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
Yonghong Song <yhs@...com>, Martin KaFai Lau <kafai@...com>,
David Miller <davem@...hat.com>,
John Fastabend <john.fastabend@...il.com>,
Jesper Dangaard Brouer <hawk@...nel.org>,
Wenbo Zhang <ethercflow@...il.com>,
KP Singh <kpsingh@...omium.org>,
Andrii Nakryiko <andriin@...com>,
Brendan Gregg <bgregg@...flix.com>,
Florent Revest <revest@...omium.org>,
Al Viro <viro@...iv.linux.org.uk>
Subject: Re: [PATCH 7/9] bpf: Compile the BTF id whitelist data in vmlinux
On Fri, May 29, 2020 at 01:48:58PM -0700, Andrii Nakryiko wrote:
> On Thu, May 28, 2020 at 10:24 AM Jiri Olsa <jolsa@...hat.com> wrote:
> >
> > On Thu, May 14, 2020 at 03:46:26PM -0700, Andrii Nakryiko wrote:
> >
> > SNIP
> >
> > > > I was thinking of putting the names in __init section and generate the BTF
> > > > ids on kernel start, but the build time generation seemed more convenient..
> > > > let's see the linking times with 'real size' whitelist and we can reconsider
> > > >
> > >
> > > Being able to record such places where to put BTF ID in code would be
> > > really nice, as Alexei mentioned. There are many potential use cases
> > > where it would be good to have BTF IDs just put into arbitrary
> > > variables/arrays. This would trigger compilation error, if someone
> > > screws up the name, or function is renamed, or if function can be
> > > compiled out under some configuration. E.g., assuming some reasonable
> > > implementation of the macro
> >
> > hi,
> > I'm struggling with this part.. to get some reasonable reference
> > to function/name into 32 bits? any idea? ;-)
> >
>
> Well, you don't have to store actual pointer, right? E.g, emitting
> something like this in assembly:
>
> .global __BTF_ID___some_function
> .type __BTF_ID___some_function, @object
> .size __BTF_ID___some_function, 4
> __BTF_ID___some_function:
> .zero 4
>
> Would reserve 4 bytes and emit __BTF_ID___some_function symbol. If we
> can then post-process vmlinux image and for all symbols starting with
> __BTF_ID___ find some_function BTF type id and put it into those 4
> bytes, that should work, no?
>
> Maybe generalize it to __BTF_ID__{func,struct,typedef}__some_function,
> whatever, not sure. Just an idea.
nice, so something like below?
it'd be in .S file, or perhaps in inline asm, assuming I'll be
able to pass macro arguments to asm("")
with externs defined in some header file:
extern const int bpf_skb_output_btf_ids[];
extern const int btf_whitelist_d_path[];
$ objdump -x ./kernel/bpf/whitelist.o
...
0000000000000000 l O .data 0000000000000004 __BTF_ID__func__vfs_truncate
0000000000000004 l O .data 0000000000000004 __BTF_ID__func__vfs_fallocate
0000000000000008 l O .data 0000000000000004 __BTF_ID__func__krava
0000000000000010 l O .data 0000000000000004 __BTF_ID__struct__sk_buff
0000000000000000 g .data 0000000000000000 btf_whitelist_d_path
0000000000000010 g .data 0000000000000000 bpf_skb_output_btf_ids
also it'd be nice to get rid of BTF_ID__ symbols in the final link
thanks,
jirka
---
#define BTF_ID(prefix, name) \
.local __BTF_ID__##prefix##__##name; \
.type __BTF_ID__##prefix##__##name, @object; \
.size __BTF_ID__##prefix##__##name, 4; \
__BTF_ID__##prefix##__##name: \
.zero 4
#define BTF_ID_LIST(name) \
.global name; \
name:
#define ZERO .zero 4
.data
BTF_ID_LIST(btf_whitelist_d_path)
BTF_ID(func, vfs_truncate)
BTF_ID(func, vfs_fallocate)
BTF_ID(func, krava)
ZERO
BTF_ID_LIST(bpf_skb_output_btf_ids)
BTF_ID(struct, sk_buff)
Powered by blists - more mailing lists