From: Florian Weimer <fw@deneb.enyo.de>
To: David Daney <ddaney@caviumnetworks.com>
Cc: linux-kernel@vger.kernel.org, DSA <debian-admin@lists.debian.org>,
       team@security.debian.org, libpam-modules@packages.debian.org
Subject: Re: 2.6.28, rlimits, performance and debian etch
References: <20090121115219.GA2754@anguilla.noreply.org>
	<8763k5u3xs.fsf@mid.deneb.enyo.de>
	<497A3E62.6010706@caviumnetworks.com>
Date: Sun, 25 Jan 2009 11:59:06 +0100
In-Reply-To: <497A3E62.6010706@caviumnetworks.com> (David Daney's message of
	"Fri, 23 Jan 2009 14:02:10 -0800")
Message-ID: <87fxj74pol.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1379
Lines: 31

* David Daney:

> One problem is that for values of RLIMIT_NOFILE less than something
> like 4096, it is much faster to call sys_close() on all possible
> values than iterate through a handful of open files from /proc/self/fd
> using opendir(3)/readdir(3).

Really?  Yuck.

> The real solution is to convert your user space programs to use the
> new syscalls that allow for race-free setting of close-on-exec.
> Then you no longer need to mess around with iterating over these
> things.

These system calls are too recent to use in the next two Debian
releases.  In addition, we can't really be sure that all libraries use
the new calls.

I find the design of the CLOEXEC business somewhat revulsive, by the
way.  It reminds me of those DoSomethingEx APIs in another platform.
The *_at system calls are a similar wart.  Even with this stuff, I
still can't safely open a file with a different effective user ID in a
multithreaded application, or create a AF_UNIX socket with specific
file system permissions.  Some thread-specific context with what have
been traditionally considered per-process attributes might have been
better. 8-(
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/