summaryrefslogtreecommitdiff
path: root/tools/testing/selftests/bpf/progs/test_tcpbpf_kern.c
diff options
context:
space:
mode:
authorAndrii Nakryiko <andrii@kernel.org>2024-01-20 00:02:01 +0300
committerAlexei Starovoitov <ast@kernel.org>2024-01-24 02:13:47 +0300
commitbc308d011ab8cc61bf1be15a2920bcd7d7b9b9d3 (patch)
tree54d3d250ff01c286ac139a659b9ed24af74b9b46 /tools/testing/selftests/bpf/progs/test_tcpbpf_kern.c
parentc80c6434aaccc689b2c7ff432d43abad8f4217b2 (diff)
downloadlinux-bc308d011ab8cc61bf1be15a2920bcd7d7b9b9d3.tar.xz
libbpf: call dup2() syscall directly
We've ran into issues with using dup2() API in production setting, where libbpf is linked into large production environment and ends up calling unintended custom implementations of dup2(). These custom implementations don't provide atomic FD replacement guarantees of dup2() syscall, leading to subtle and hard to debug issues. To prevent this in the future and guarantee that no libc implementation will do their own custom non-atomic dup2() implementation, call dup2() syscall directly with syscall(SYS_dup2). Note that some architectures don't seem to provide dup2 and have dup3 instead. Try to detect and pick best syscall. Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Song Liu <song@kernel.org> Acked-by: Yonghong Song <yonghong.song@linux.dev> Link: https://lore.kernel.org/r/20240119210201.1295511-1-andrii@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Diffstat (limited to 'tools/testing/selftests/bpf/progs/test_tcpbpf_kern.c')
0 files changed, 0 insertions, 0 deletions