Current codes using a brute-force traversal of all file descriptors do not scale on a system where the maximum number of file descriptors is set to a very large value (e.g.: in a Docker container of Manjaro distribution it is set to 1073741816). QEMU just looks frozen during start-up.
The close-on-exec flag (O_CLOEXEC) was introduced since Linux kernel 2.6.23, FreeBSD 8.3, OpenBSD 5.0, Solaris 11. While it's true QEMU doesn't need to manually close the fds for child process as the proper O_CLOEXEC flag should have been set properly on files with its own codes, QEMU uses a huge number of 3rd party libraries and we don't trust them to reliably be using O_CLOEXEC on everything they open. Modern Linux and BSDs have the close_range() call we can use to do the job, and on Linux we have one more way to walk through /proc/self/fd to complete the task efficiently, which is what qemu_close_range() does, a new API we add in utils/osdep.c. Changes in v2: - Change to use qemu_close_range() to close fds for child process efficiently - v1 link: https://lore.kernel.org/qemu-devel/20230406112041.798585-1-bm...@tinylab.org/ Bin Meng (4): tests/tcg/cris: Fix the coding style tests/tcg/cris: Correct the off-by-one error util/async-teardown: Fall back to close fds one by one utils/osdep: Introduce qemu_close_range() Zhangjin Wu (2): util/async-teardown: Use qemu_close_range() to close fds net: tap: Use qemu_close_range() to close fds include/qemu/osdep.h | 1 + net/tap.c | 23 ++++++------ tests/tcg/cris/libc/check_openpf5.c | 57 ++++++++++++++--------------- util/async-teardown.c | 37 +------------------ util/osdep.c | 47 ++++++++++++++++++++++++ 5 files changed, 87 insertions(+), 78 deletions(-) -- 2.34.1
