All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Jiri Olsa <jolsa@redhat.com>
Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>,
	Martin KaFai Lau <kafai@fb.com>, Jiri Olsa <jolsa@kernel.org>,
	dwarves@vger.kernel.org, bpf <bpf@vger.kernel.org>,
	Kernel Team <kernel-team@fb.com>,
	Andrii Nakryiko <andrii@kernel.org>
Subject: Re: [PATCH dwarves] btf: Generate btf for functions in the .BTF_ids section
Date: Tue, 27 Apr 2021 09:34:30 -0300	[thread overview]
Message-ID: <YIgE1hAaa3Hzwni8@kernel.org> (raw)
In-Reply-To: <YIf3rHTLqW7yZxFJ@krava>

Em Tue, Apr 27, 2021 at 01:38:20PM +0200, Jiri Olsa escreveu:
> On Mon, Apr 26, 2021 at 04:26:11PM -0700, Andrii Nakryiko wrote:
> > On Fri, Apr 23, 2021 at 2:37 PM Martin KaFai Lau <kafai@fb.com> wrote:
> > > BTF is currently generated for functions that are in ftrace list
> > > or extern.
> > >
> > > A recent use case also needs BTF generated for functions included in
> > > allowlist.  In particular, the kernel
> > > commit e78aea8b2170 ("bpf: tcp: Put some tcp cong functions in allowlist for bpf-tcp-cc")
> > > allows bpf program to directly call a few tcp cc kernel functions.  Those
> > > functions are specified under an ELF section .BTF_ids.  The symbols
> > > in this ELF section is like __BTF_ID__func__<kernel_func>__[digit]+.
> > > For example, __BTF_ID__func__cubictcp_init__1.  Those kernel
> > > functions are currently allowed only if CONFIG_DYNAMIC_FTRACE is
> > > set to ensure they are in the ftrace list but this kconfig dependency
> > > is unnecessary.
> > >
> > > pahole can generate BTF for those kernel functions if it knows they
> > > are in the allowlist.  This patch is to capture those symbols
> > > in the .BTF_ids section and generate BTF for them.

> > I wonder if we just record all functions how bad that would be. Jiri,
> > do you remember from the time you were experimenting with static
> > functions how much more functions we'd be recording if we didn't do
> > ftrace filtering?
 
> hum, I can't find that.. but should be just matter of removing
> that is_ftrace_func check
 
> if we decided to do that, maybe we could add some bit indicating
> that the function is traceable? it would save us check with
> available_filter_functions file

You mean encoding it in BTF, in 'struct btf_type'? Seems important to
have it, there are free bits there:

/* Max # of type identifier */
#define BTF_MAX_TYPE    0x000fffff
/* Max offset into the string section */
#define BTF_MAX_NAME_OFFSET     0x00ffffff
/* Max # of struct/union/enum members or func args */
#define BTF_MAX_VLEN    0xffff

struct btf_type {
        __u32 name_off;
        /* "info" bits arrangement
         * bits  0-15: vlen (e.g. # of struct's members)
         * bits 16-23: unused
         * bits 24-27: kind (e.g. int, ptr, array...etc)
         * bits 28-30: unused
         * bit     31: kind_flag, currently used by
         *             struct, union and fwd
         */
        __u32 info;
        /* "size" is used by INT, ENUM, STRUCT, UNION and DATASEC.
         * "size" tells the size of the type it is describing.
         *
         * "type" is used by PTR, TYPEDEF, VOLATILE, CONST, RESTRICT,
         * FUNC, FUNC_PROTO and VAR.
         * "type" is a type_id referring to another type.
         */
        union {
                __u32 size;
                __u32 type;
        };
};

And tools that expect to trace a function can get that information from
the BTF info instead of getting some failure when trying to trace those
functions, right?

- Arnaldo

  reply	other threads:[~2021-04-27 12:34 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-23 21:37 [PATCH dwarves] btf: Generate btf for functions in the .BTF_ids section Martin KaFai Lau
2021-04-26 23:26 ` Andrii Nakryiko
2021-04-27 11:38   ` Jiri Olsa
2021-04-27 12:34     ` Arnaldo Carvalho de Melo [this message]
2021-04-27 12:43       ` Jiri Olsa
2021-04-27 20:38       ` Andrii Nakryiko
2021-04-28 13:10         ` Arnaldo Carvalho de Melo
2021-04-28 19:45           ` Andrii Nakryiko
2021-04-28 22:05             ` Arnaldo Carvalho de Melo
2021-05-01  0:16     ` Martin KaFai Lau
2021-05-01 22:23       ` Jiri Olsa
2021-04-27 11:42 ` Jiri Olsa
2021-04-27 18:20   ` Martin KaFai Lau

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=YIgE1hAaa3Hzwni8@kernel.org \
    --to=acme@kernel.org \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=dwarves@vger.kernel.org \
    --cc=jolsa@kernel.org \
    --cc=jolsa@redhat.com \
    --cc=kafai@fb.com \
    --cc=kernel-team@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.