From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2965 Path: news.gmane.org!not-for-mail From: Zvi Gilboa Newsgroups: gmane.linux.lib.musl.general Subject: Re: Difficulty emulating F_DUPFD_CLOEXEC Date: Sat, 23 Mar 2013 22:10:10 -0400 Message-ID: <514E6082.4070104@eservices.virginia.edu> References: <20130324015923.GA5905@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1364091023 7372 80.91.229.3 (24 Mar 2013 02:10:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 24 Mar 2013 02:10:23 +0000 (UTC) To: Original-X-From: musl-return-2966-gllmg-musl=m.gmane.org@lists.openwall.com Sun Mar 24 03:10:49 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UJaOX-0000Qg-3z for gllmg-musl@plane.gmane.org; Sun, 24 Mar 2013 03:10:49 +0100 Original-Received: (qmail 25978 invoked by uid 550); 24 Mar 2013 02:10:25 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 25969 invoked from network); 24 Mar 2013 02:10:24 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 In-Reply-To: <20130324015923.GA5905@brightrain.aerifal.cx> X-Originating-IP: [71.206.170.124] Xref: news.gmane.org gmane.linux.lib.musl.general:2965 Archived-At: On 03/23/2013 09:59 PM, Rich Felker wrote: > Hi again, > > Old kernels lack fcntl F_DUPFD_CLOEXEC, which musl needs internally > and wants to provide to applications. Thus, I'd like to emulate it > like we do for pipe2, dup3, socket SOCK_CLOEXEC, etc.; the emulation > has a race condition that leaks fds, but it's better than nothing. > > The problem I'm having is how to detect the case where the kernel > lacks F_DUPFD_CLOEXEC. For other other atomic close-on-exec > operations, we either have ENOSYS (newly added syscall) or an > unambiguous EINVAL. But for fcntl, we could get EINVAL because > F_DUPFD_CLOEXEC is not recognized by the kernel, or because the > argument is larger than OPEN_MAX. So we need a test for the cause > behind EINVAL. > > False positives are not an option, because if we wrongly detect that > F_DUPFD_CLOEXEC was not supported, we would emulate it with the code > that has race conditions and fd leaks, even on new kernels which > should not have these problems. > > The best idea I have so far is: > > 1. Try F_DUPFD_CLOEXEC. If it succeeds or fails with any error other > than EINVAL, we're done. > > 2. If it fails with EINVAL, retry with an argument of 0. This will > eliminate the other cause of EINVAL, so now we should get EINVAL > only on old kernels that lack F_DUPFD_CLOEXEC. If this test > succeeds, we need to close the new duplicate fd we made (on the > wrong fd number) and report EINVAL back to the caller. > > 3. If the test in step 2 failed, F_DUPFD_CLOEXEC is unsupported, and > we have to use the fallback code with race conditions. > > This uglifies fcntl.c a bit more, but I think it works. Does the above > reasoning make sense? Any other ideas? In the hope that this matches the project's spirit... how about running these tests during the build, and have a script (or a simple test program) #define whether the target architecture supports F_DUPFD_CLOEXEC or not? Potentially, this test could be added at the very end of alltypes.h.sh > > Rich