diff options
author | Matt Bobrowski <[email protected]> | 2024-02-14 09:14:23 +0000 |
---|---|---|
committer | Andrii Nakryiko <[email protected]> | 2024-02-14 09:48:46 -0800 |
commit | 1159d27852207e8efb8d6ef2dae5aaa87ec4e225 (patch) | |
tree | b95004b53f9c6ea8b5bd0c9570668b1807933317 /scripts/gdb/linux/vmalloc.py | |
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 <[email protected]>
Signed-off-by: Andrii Nakryiko <[email protected]>
Acked-by: Jiri Olsa <[email protected]>
Link: https://lore.kernel.org/bpf/[email protected]
Diffstat (limited to 'scripts/gdb/linux/vmalloc.py')
0 files changed, 0 insertions, 0 deletions