From: Xavier Roche <roche@httrack.com>
To: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Would adding closefrom(2) syscall to the kernel make sense ?
Date: Wed, 3 Jun 2015 08:55:32 +0200 [thread overview]
Message-ID: <20150603065532.GA12224@proliant.localnet> (raw)
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 (<1396941142-24821-1-git-send-email-wenqing.lz@taobao.com> ; (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
reply other threads:[~2015-06-03 6:55 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150603065532.GA12224@proliant.localnet \
--to=roche@httrack.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox