All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <jolsa@redhat.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	Jiri Olsa <jolsa@kernel.org>, Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>,
	Yonghong Song <yhs@fb.com>, Martin KaFai Lau <kafai@fb.com>,
	David Miller <davem@redhat.com>,
	John Fastabend <john.fastabend@gmail.com>,
	Jesper Dangaard Brouer <hawk@kernel.org>,
	Wenbo Zhang <ethercflow@gmail.com>,
	KP Singh <kpsingh@chromium.org>, Andrii Nakryiko <andriin@fb.com>,
	Brendan Gregg <bgregg@netflix.com>,
	Florent Revest <revest@chromium.org>,
	Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH 7/9] bpf: Compile the BTF id whitelist data in vmlinux
Date: Sun, 31 May 2020 17:10:39 +0200	[thread overview]
Message-ID: <20200531151039.GA881900@krava> (raw)
In-Reply-To: <CAEf4BzbM-5-_QzDhrJDFJefo-m0OWDhvjsK_F1vA-ja4URVE9Q@mail.gmail.com>

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@redhat.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)


  reply	other threads:[~2020-05-31 15:10 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-06 13:29 [RFCv2 0/9] bpf: Add d_path helper Jiri Olsa
2020-05-06 13:29 ` [PATCH 1/9] " Jiri Olsa
2020-05-14 22:06   ` Andrii Nakryiko
2020-05-15 14:59     ` Jiri Olsa
2020-05-06 13:29 ` [PATCH 2/9] bpf: Add d_path whitelist Jiri Olsa
2020-05-06 13:29 ` [PATCH 3/9] bpf: Add bpfwl tool to construct bpf whitelists Jiri Olsa
2020-05-14 22:20   ` Andrii Nakryiko
2020-05-15 14:58     ` Jiri Olsa
2020-05-06 13:29 ` [PATCH 4/9] bpf: Allow nested BTF object to be refferenced by BTF object + offset Jiri Olsa
2020-05-14 22:32   ` Andrii Nakryiko
2020-05-06 13:29 ` [PATCH 5/9] bpf: Add support to check on BTF id whitelist for d_path helper Jiri Olsa
2020-05-06 13:29 ` [PATCH 6/9] bpf: Compile bpfwl tool at kernel compilation start Jiri Olsa
2020-05-14 22:38   ` Andrii Nakryiko
2020-05-15 14:57     ` Jiri Olsa
2020-05-06 13:29 ` [PATCH 7/9] bpf: Compile the BTF id whitelist data in vmlinux Jiri Olsa
2020-05-13 18:29   ` Alexei Starovoitov
2020-05-14  8:05     ` Jiri Olsa
2020-05-14 22:46       ` Andrii Nakryiko
2020-05-15 14:57         ` Jiri Olsa
2020-05-28 17:23         ` Jiri Olsa
2020-05-29 20:48           ` Andrii Nakryiko
2020-05-31 15:10             ` Jiri Olsa [this message]
2020-06-01 19:06               ` Andrii Nakryiko
2020-06-02  8:16                 ` Jiri Olsa
2020-05-06 13:29 ` [PATCH 8/9] selftests/bpf: Add test for d_path helper Jiri Olsa
2020-05-14 22:48   ` Andrii Nakryiko
2020-05-15 14:57     ` Jiri Olsa
2020-05-06 13:29 ` [PATCH 9/9] selftests/bpf: Add verifier " Jiri Olsa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200531151039.GA881900@krava \
    --to=jolsa@redhat.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andriin@fb.com \
    --cc=ast@kernel.org \
    --cc=bgregg@netflix.com \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@redhat.com \
    --cc=ethercflow@gmail.com \
    --cc=hawk@kernel.org \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kafai@fb.com \
    --cc=kpsingh@chromium.org \
    --cc=netdev@vger.kernel.org \
    --cc=revest@chromium.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=yhs@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.