public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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