On 1/19/24 1:02 PM, Andrii Nakryiko wrote:
We've ran into issues with using dup2() API in production setting, where libbpf is linked into large production environment and ends up calling uninteded 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@xxxxxxxxxx>
Acked-by: Yonghong Song <yonghong.song@xxxxxxxxx>