linux-stable.git/tools/lib, branch v5.16.3

libbpf: Remove deprecation attribute from struct bpf_prog_prep_result

2022-01-27T11:02:54+00:00

commit 5c5edcdebfcf3a95257b0d8ef27a60af0e0ea03a upstream.

This deprecation annotation has no effect because for struct deprecation
attribute has to be declared after struct definition. But instead of
moving it to the end of struct definition, remove it. When deprecation
will go in effect at libbpf v0.7, this deprecation attribute will cause
libbpf's own source code compilation to trigger deprecation warnings,
which is unavoidable because libbpf still has to support that API.

So keep deprecation of APIs, but don't mark structs used in API as
deprecated.

Fixes: e21d585cb3db ("libbpf: Deprecate multi-instance bpf_program APIs")
Signed-off-by: Andrii Nakryiko 
Signed-off-by: Alexei Starovoitov 
Acked-by: Dave Marchevsky 
Link: https://lore.kernel.org/bpf/20211103220845.2676888-8-andrii@kernel.org
Signed-off-by: Greg Kroah-Hartman

libbpf: Accommodate DWARF/compiler bug with duplicated structs

2022-01-27T11:02:15+00:00

[ Upstream commit efdd3eb8015e7447095f02a26eaabd164cd18004 ]

According to [0], compilers sometimes might produce duplicate DWARF
definitions for exactly the same struct/union within the same
compilation unit (CU). We've had similar issues with identical arrays
and handled them with a similar workaround in 6b6e6b1d09aa ("libbpf:
Accomodate DWARF/compiler bug with duplicated identical arrays"). Do the
same for struct/union by ensuring that two structs/unions are exactly
the same, down to the integer values of field referenced type IDs.

Solving this more generically (allowing referenced types to be
equivalent, but using different type IDs, all within a single CU)
requires a huge complexity increase to handle many-to-many mappings
between canonidal and candidate type graphs. Before we invest in that,
let's see if this approach handles all the instances of this issue in
practice. Thankfully it's pretty rare, it seems.

  [0] https://lore.kernel.org/bpf/YXr2NFlJTAhHdZqq@krava/

Reported-by: Jiri Olsa 
Signed-off-by: Andrii Nakryiko 
Signed-off-by: Daniel Borkmann 
Link: https://lore.kernel.org/bpf/20211117194114.347675-1-andrii@kernel.org
Signed-off-by: Sasha Levin

libbpf: Improve sanity checking during BTF fix up

2022-01-27T11:02:12+00:00

[ Upstream commit 88918dc12dc357a06d8d722a684617b1c87a4654 ]

If BTF is corrupted DATASEC's variable type ID might be incorrect.
Prevent this easy to detect situation with extra NULL check.
Reported by oss-fuzz project.

Signed-off-by: Andrii Nakryiko 
Signed-off-by: Alexei Starovoitov 
Acked-by: Yonghong Song 
Link: https://lore.kernel.org/bpf/20211103173213.1376990-3-andrii@kernel.org
Signed-off-by: Sasha Levin

libbpf: Detect corrupted ELF symbols section

2022-01-27T11:02:12+00:00

[ Upstream commit 833907876be55205d0ec153dcd819c014404ee16 ]

Prevent divide-by-zero if ELF is corrupted and has zero sh_entsize.
Reported by oss-fuzz project.

Signed-off-by: Andrii Nakryiko 
Signed-off-by: Alexei Starovoitov 
Acked-by: Yonghong Song 
Link: https://lore.kernel.org/bpf/20211103173213.1376990-2-andrii@kernel.org
Signed-off-by: Sasha Levin

libbpf: Use probe_name for legacy kprobe

2022-01-27T11:01:55+00:00

[ Upstream commit 71cff670baff5cc6a6eeb0181e2cc55579c5e1e0 ]

Fix a bug in commit 46ed5fc33db9, which wrongly used the
func_name instead of probe_name to register legacy kprobe.

Fixes: 46ed5fc33db9 ("libbpf: Refactor and simplify legacy kprobe code")
Co-developed-by: Chengming Zhou 
Signed-off-by: Qiang Wang 
Signed-off-by: Chengming Zhou 
Signed-off-by: Andrii Nakryiko 
Tested-by: Hengqi Chen 
Reviewed-by: Hengqi Chen 
Link: https://lore.kernel.org/bpf/20211227130713.66933-1-wangqiang.wq.frank@bytedance.com
Signed-off-by: Sasha Levin

libbpf: Fix gen_loader assumption on number of programs.

2022-01-27T11:01:45+00:00

[ Upstream commit 259172bb6514758ce3be1610c500b51a9f44212a ]

libbpf's obj->nr_programs includes static and global functions. That number
could be higher than the actual number of bpf programs going be loaded by
gen_loader. Passing larger nr_programs to bpf_gen__init() doesn't hurt. Those
exra stack slots will stay as zero. bpf_gen__finish() needs to check that
actual number of progs that gen_loader saw is less than or equal to
obj->nr_programs.

Fixes: ba05fd36b851 ("libbpf: Perform map fd cleanup for gen_loader in case of error")
Signed-off-by: Alexei Starovoitov 
Signed-off-by: Sasha Levin

libbpf: Add "bool skipped" to struct bpf_map

2022-01-27T11:01:44+00:00

[ Upstream commit 229fae38d0fc0d6ff58d57cbeb1432da55e58d4f ]

Fix error: "failed to pin map: Bad file descriptor, path:
/sys/fs/bpf/_rodata_str1_1."

In the old kernel, the global data map will not be created, see [0]. So
we should skip the pinning of the global data map to avoid
bpf_object__pin_maps returning error. Therefore, when the map is not
created, we mark “map->skipped" as true and then check during relocation
and during pinning.

Fixes: 16e0c35c6f7a ("libbpf: Load global data maps lazily on legacy kernels")
Signed-off-by: Shuyi Cheng 
Signed-off-by: Andrii Nakryiko 
Signed-off-by: Sasha Levin

libbpf: Clean gen_loader's attach kind.

2022-01-27T11:01:38+00:00

[ Upstream commit 19250f5fc0c283892a61f3abf9d65e6325f63897 ]

The gen_loader has to clear attach_kind otherwise the programs
without attach_btf_id will fail load if they follow programs
with attach_btf_id.

Fixes: 67234743736a ("libbpf: Generate loader program out of BPF ELF file.")
Signed-off-by: Alexei Starovoitov 
Signed-off-by: Andrii Nakryiko 
Acked-by: Andrii Nakryiko 
Link: https://lore.kernel.org/bpf/20211201181040.23337-12-alexei.starovoitov@gmail.com
Signed-off-by: Sasha Levin

libbpf: Silence uninitialized warning/error in btf_dump_dump_type_data

2022-01-27T11:01:35+00:00

[ Upstream commit 43174f0d4597325cb91f1f1f55263eb6e6101036 ]

When compiling libbpf with gcc 4.8.5, we see:

  CC       staticobjs/btf_dump.o
btf_dump.c: In function ‘btf_dump_dump_type_data.isra.24’:
btf_dump.c:2296:5: error: ‘err’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
  if (err < 0)
     ^
cc1: all warnings being treated as errors
make: *** [staticobjs/btf_dump.o] Error 1

While gcc 4.8.5 is too old to build the upstream kernel, it's possible it
could be used to build standalone libbpf which suffers from the same problem.
Silence the error by initializing 'err' to 0.  The warning/error seems to be
a false positive since err is set early in the function.  Regardless we
shouldn't prevent libbpf from building for this.

Fixes: 920d16af9b42 ("libbpf: BTF dumper support for typed data")
Signed-off-by: Alan Maguire 
Signed-off-by: Andrii Nakryiko 
Link: https://lore.kernel.org/bpf/1638180040-8037-1-git-send-email-alan.maguire@oracle.com
Signed-off-by: Sasha Levin

libbpf: Fix using invalidated memory in bpf_linker

2022-01-27T11:01:34+00:00

[ Upstream commit 593835377f24ca1bb98008ec1dc3baefe491ad6e ]

add_dst_sec() can invalidate bpf_linker's section index making
dst_symtab pointer pointing into unallocated memory. Reinitialize
dst_symtab pointer on each iteration to make sure it's always valid.

Fixes: faf6ed321cf6 ("libbpf: Add BPF static linker APIs")
Signed-off-by: Andrii Nakryiko 
Signed-off-by: Daniel Borkmann 
Link: https://lore.kernel.org/bpf/20211124002325.1737739-7-andrii@kernel.org
Signed-off-by: Sasha Levin