From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753073AbbFCGzx (ORCPT ); Wed, 3 Jun 2015 02:55:53 -0400 Received: from smtp-2.httrack.com ([195.154.67.106]:36365 "EHLO smtp-2.httrack.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752380AbbFCGzp (ORCPT ); Wed, 3 Jun 2015 02:55:45 -0400 X-Spam-Filter: check_local@smtp-2.httrack.com by digitalanswers.org Date: Wed, 3 Jun 2015 08:55:32 +0200 From: Xavier Roche To: Linux Kernel Subject: Would adding closefrom(2) syscall to the kernel make sense ? Message-ID: <20150603065532.GA12224@proliant.localnet> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.3.9 (smtp-2.httrack.com [IPv6:2001:bc8:30e2::1]); Wed, 03 Jun 2015 08:55:38 +0200 (CEST) X-SPF-Scan-By: smf-spf v2.0.2 - http://smfs.sf.net/ Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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