diff options
author | Andrii Nakryiko <andrii@kernel.org> | 2021-12-12 17:07:06 -0800 |
---|---|---|
committer | Alexei Starovoitov <ast@kernel.org> | 2021-12-12 17:26:24 -0800 |
commit | 4b443bc1785f28df56fdbd6a107dc68ef7d5aa8e (patch) | |
tree | 2c6e46dbfaff8bce7a0c22d5f067aac442f70480 /tools/testing/selftests/bpf/prog_tests/syscall.c | |
parent | f12468828c28ff90d20c99b234a94223401f7924 (diff) |
libbpf: Don't validate TYPE_ID relo's original imm value
During linking, type IDs in the resulting linked BPF object file can
change, and so ldimm64 instructions corresponding to
BPF_CORE_TYPE_ID_TARGET and BPF_CORE_TYPE_ID_LOCAL CO-RE relos can get
their imm value out of sync with actual CO-RE relocation information
that's updated by BPF linker properly during linking process.
We could teach BPF linker to adjust such instructions, but it feels
a bit too much for linker to re-implement good chunk of
bpf_core_patch_insns logic just for this. This is a redundant safety
check for TYPE_ID relocations, as the real validation is in matching
CO-RE specs, so if that works fine, it's very unlikely that there is
something wrong with the instruction itself.
So, instead, teach libbpf (and kernel) to ignore insn->imm for
BPF_CORE_TYPE_ID_TARGET and BPF_CORE_TYPE_ID_LOCAL relos.
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20211213010706.100231-1-andrii@kernel.org
Diffstat (limited to 'tools/testing/selftests/bpf/prog_tests/syscall.c')
0 files changed, 0 insertions, 0 deletions