Hi folks,
Would a closefrom syscall (ie. close all fd above a certain fd) make sense in
the kernel, or is this something deemed /undesirable/ ?
Zheng Liu submitted a patch some time ago
(<[email protected]> ; (3)) to add this
feature, but with minor code issues, and no followup was made.
Rationale:
Many real-life programs use fork()/exec() to spawn child, and, before calling
exec(), use close() on all file descriptors above 3. This is typically used
using closefrom() when available, or, when unavailable, through regular close()
calls from fd=3 to fd=sysconf(_SC_OPEN_MAX)-1 (or by listing /proc/self/fd, and
taking note of the highest fd).
The reason to close "all file descriptors above 3" is a pragmatic approach over
the existing dirty universe, where almost everybody forget to clear the "close
on exec" flag, leading to inherit fd in forked task.
Clearing the "close on exec" flag for all file descriptors is cumbersome enough
for most programmers to forget to comply:
open(..., ...) => open(..., ... | O_CLOEXEC)
fopen(..., ...) => open(..., ... | O_CLOEXEC) + fdopen(...) OR
fopen(..., ... + "e")
dup(...) => fcntl(..., F_DUPFD_CLOEXEC, (long) 0)
dup2(..., ...) => dup3(..., ..., O_CLOEXEC)
opendir(...) => open(..., O_RDONLY | O_DIRECTORY | O_CLOEXEC) +
fdopendir(...)
pipe(...) => pipe2(..., O_CLOEXEC)
acept(..., ..., ...) => accept4(..., ..., ..., O_CLOEXEC)
socket(..., ..., ...) => socket(..., ... | SOCK_CLOEXEC, ...)
etc.
(some of the solutions listed are unavailable depending on the kernel version,
glibc version, etc.)
This situation leads to thousands of useless close() syscall (see for example
(4)), and a better solution might be desirable rather than relying on the
hypothetic cleaning of the known universe.
Both BSD (2) and Solaris (3) support this feature, by the way. (I know, some
people will consider this as a rebuttal to add this feature, but anyway)
(1) https://lwn.net/Articles/593778/
(2) http://www.unix.com/man-page/freebsd/2/closefrom/
(3) http://docs.oracle.com/cd/E26505_01/html/816-5168/fdwalk-3c.html
(4) https://bugs.openjdk.java.net/browse/JDK-4791640
Regards,
Xavier
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
