This will allow us to stop using btfe->priv and eventually btf_elf
altogether for the BTF loader.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
So that we can get rid of that global base_btf and use the right way
to pass load configuration to the format loaders.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
We'll get rid of the 'base_btf' global variable in libbtf.c, so stop
using it in the BTF encoder.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
When loading a file, via btf__parse_split() libbtf will read the header
and have the endianness made available via the btf__endianness() API,
use it.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
This way we use libbtf to transparently load both ELF files with a BTF
section as well as raw BTF files, such as those in /sys/kernel/btf/ or
the ones generated using 'pahole --btf_encode_detached'
Suggested-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
To fix the build in systems where this isn't defined.
Reported-by: Marcos Paulo de Souza <mpdesouza@suse.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
To solve problems similar to _RH_KABI_REPLACE. The _RH_KABI_REPLACE(_orig, _new) macros perserve size alignment and kabi agreement between _orig and _new.Below is the definition of this macro:
union { \
_new; \
struct { \
_orig; \
} __UNIQUE_ID(rh_kabi_hide); \
__RH_KABI_CHECK_SIZE_ALIGN(_orig, _new); \
}
__UNIQUE_ID uses the __COUNTER__ macro, and the __COUNTER__ macro is automatically incremented by 1 every time it is precompiled. Therefore, in different compilation units, the same structure has different names.Here is a concrete example:
struct acpi_dev_node {
union {
struct acpi_device *companion;
struct {
void *handle;
} __UNIQUE_ID_rh_kabi_hide29;
union { };
};
};
struct acpi_dev_node {
union {
struct acpi_device *companion;
struct {
void *handle;
} __UNIQUE_ID_rh_kabi_hide31;
union { };
};
};
Finally, it will cause the btf algorithm to de-duplication efficiency is not high, and time-consuming. For example, running ./pahole -J vmlinux-3.10.0-1160.el7.x86_64 without --kabi_prefix flag, the running time is:
real 8m28.912s
user 8m27.271s
sys 0m1.471s
And the size of the generated btf segment is 30678240 bytes.
After adding the patch, running ./pahole --kabi_prefix=__UNIQUE_ID_rh_kabi_hide -J vmlinux-3.10.0-1160.el7.x86_64. The running time of the command is:
real 0m19.634s
user 0m18.457s
sys 0m1.169s
And the size of the generated btf segment is 3117719 bytes.
Signed-off-by: Shuyi Cheng <chengshuyi@linux.alibaba.com>
Acked-by: Jiri Olsa <jolsa@redhat.com>
Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Wenan Mao <wenan.mao@linux.alibaba.com>
Cc: dwarves@vger.kernel.org
Link: https://lore.kernel.org/dwarves/482e5543-d7da-7bed-098d-cc879d8db253@linux.alibaba.com/
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
btf_encoder is ignoring zero-sized per-CPU ELF symbols, but the same has to be
done for DWARF variables when matching them with ELF symbols. This is due to
zero-sized DWARF variables matching unrelated (non-zero-sized) variable that
happens to be allocated at the exact same address, leading to a lot of
confusion in BTF.
See [0] for when this causes big problems.
[0] https://lore.kernel.org/bpf/CAEf4BzZ0-sihSL-UAm21JcaCCY92CqfNxycHRZYXcoj8OYb=wA@mail.gmail.com/
Committer notes:
Kept the {} around the if block with more than one line, which
simplifies the original patch by just removing that assignment
to the 'dwarf_name' variable.
Reported-by: Michal Suchánek <msuchanek@suse.de>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: bpf@vger.kernel.org
Cc: dwarves@vger.kernel.org
Cc: kernel-team@fb.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
So that we handle const pointers, also zalloc() is much simpler just
calling calloc(1, size).
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
We were allocating it with malloc and then trying to initialize it with
dwarf_cu__init(), which may fail and leave the dwarf_cu instance not
completely initialized which would lead to problems when calling
dwarf_cu__delete(), use zalloc to make sure all is zeroed.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
It may be used uninitialized, fix it.
Error: UNINIT (CWE-457):
dwarves-1.21/ctracer.c:401: var_decl: Declaring variable "parm_list" without initializer.
dwarves-1.21/ctracer.c:470: uninit_use_in_call: Using uninitialized value "*parm_list" as argument to "%s" when calling "fprintf". [Note: The source code implementation of the function has been overridden by a builtin model.]
# 468| 1, "entry,exit");
# 469| }
# 470|-> fprintf(fp_converter,
# 471| "\\n\",\n\t\t\t %s);\n"
# 472| "\t}\n"
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Error: RESOURCE_LEAK (CWE-772):
dwarves-1.21/btf_loader.c:554: alloc_fn: Storage is returned from allocation function "btf_elf__new".
dwarves-1.21/btf_loader.c:554: var_assign: Assigning: "btfe" = storage returned from "btf_elf__new(filename, NULL, base_btf)".
dwarves-1.21/btf_loader.c:561: leaked_storage: Variable "btfe" going out of scope leaks the storage it points to.
# 559| struct cu *cu = cu__new(filename, btfe->wordsize, NULL, 0, filename);
# 560| if (cu == NULL)
# 561|-> return -1;
# 562|
# 563| cu->language = LANG_C;
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Error: RESOURCE_LEAK (CWE-772):
dwarves-1.21/btf_loader.c:293: alloc_fn: Storage is returned from allocation function "type__new".
dwarves-1.21/btf_loader.c:293: var_assign: Assigning: "enumeration" = storage returned from "type__new(DW_TAG_enumeration_type, tp->name_off, ((*tp).size ? (*tp).size * 8U : 32UL))".
dwarves-1.21/btf_loader.c:315: noescape: Resource "enumeration" is not freed or pointed-to in "enumeration__delete".
dwarves-1.21/btf_loader.c:316: leaked_storage: Variable "enumeration" going out of scope leaks the storage it points to.
# 314| out_free:
# 315| enumeration__delete(enumeration, btfe->priv);
# 316|-> return -ENOMEM;
# 317| }
# 318|
Error: RESOURCE_LEAK (CWE-772):
dwarves-1.21/ctf_loader.c:398: alloc_fn: Storage is returned from allocation function "type__new".
dwarves-1.21/ctf_loader.c:398: var_assign: Assigning: "enumeration" = storage returned from "type__new(DW_TAG_enumeration_type, ctf__get32(ctf, &tp->base.ctf_name), (size ?: 32UL))".
dwarves-1.21/ctf_loader.c:421: noescape: Resource "enumeration" is not freed or pointed-to in "enumeration__delete".
dwarves-1.21/ctf_loader.c:422: leaked_storage: Variable "enumeration" going out of scope leaks the storage it points to.
# 420| out_free:
# 421| enumeration__delete(enumeration, ctf->priv);
# 422|-> return -ENOMEM;
# 423| }
# 424|
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
When the CTF and later the BTF loaders were implemented they didn't use
obstacks, and then over time some functions, like type__delete(),
class__delete(), enumeration__delete() were shared, which can lead to
crashes by corrupting the obstack by not following its requirements or
to leaks, to avoid such corruption, stop using it.
There is a penalty, but I think its not worth the complexity to keep
using it.
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
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
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.
Those kernel functions are specified under an ELF section .BTF_ids.
There was an earlier attempt [0] to add another filter for the functions in
the .BTF_ids section. That discussion concluded that the ftrace filter
should be removed instead.
This patch is to remove the ftrace filter and its related functions.
Number of BTF FUNC with and without is_ftrace_func():
My kconfig in x86: 40643 vs 46225
Jiri reported on arm: 25022 vs 55812
[0]: https://lore.kernel.org/dwarves/20210423213728.3538141-1-kafai@fb.com/
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Tested-by: Nathan Chancellor <nathan@kernel.org> # build
Acked-by: Jiri Olsa <jolsa@kernel.org>
Acked-by: Jiri Slaby <jirislaby@kernel.org>
Cc: Andrii Nakryiko <andrii@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: kernel-team@fb.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Arnaldo Carvalho de Melo
Shuyi Cheng
Andrii Nakryiko
Sevan Janiyan
Martin KaFai Lau