diff options
author | Matt Bobrowski <mattbobrowski@google.com> | 2024-02-14 09:14:23 +0000 |
---|---|---|
committer | Andrii Nakryiko <andrii@kernel.org> | 2024-02-14 09:48:46 -0800 |
commit | 1159d27852207e8efb8d6ef2dae5aaa87ec4e225 (patch) | |
tree | b95004b53f9c6ea8b5bd0c9570668b1807933317 /kernel/bpf | |
parent | 7cc13adbd057f1905564ec2a254883d7fd407deb (diff) |
libbpf: Make remark about zero-initializing bpf_*_info structs
In some situations, if you fail to zero-initialize the
bpf_{prog,map,btf,link}_info structs supplied to the set of LIBBPF
helpers bpf_{prog,map,btf,link}_get_info_by_fd(), you can expect the
helper to return an error. This can possibly leave people in a
situation where they're scratching their heads for an unnnecessary
amount of time. Make an explicit remark about the requirement of
zero-initializing the supplied bpf_{prog,map,btf,link}_info structs
for the respective LIBBPF helpers.
Internally, LIBBPF helpers bpf_{prog,map,btf,link}_get_info_by_fd()
call into bpf_obj_get_info_by_fd() where the bpf(2)
BPF_OBJ_GET_INFO_BY_FD command is used. This specific command is
effectively backed by restrictions enforced by the
bpf_check_uarg_tail_zero() helper. This function ensures that if the
size of the supplied bpf_{prog,map,btf,link}_info structs are larger
than what the kernel can handle, trailing bits are zeroed. This can be
a problem when compiling against UAPI headers that don't necessarily
match the sizes of the same underlying types known to the kernel.
Signed-off-by: Matt Bobrowski <mattbobrowski@google.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Link: https://lore.kernel.org/bpf/ZcyEb8x4VbhieWsL@google.com
Diffstat (limited to 'kernel/bpf')
0 files changed, 0 insertions, 0 deletions