From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/210 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: close(2) failure cases (was: some fixes to musl) Date: Sun, 24 Jul 2011 18:29:26 -0400 Message-ID: <20110724222926.GN132@brightrain.aerifal.cx> References: <20110721170255.GA7352@albatros> <20110721182101.GB132@brightrain.aerifal.cx> <20110724091918.GA6076@albatros> <20110724122402.GH132@brightrain.aerifal.cx> <20110724174901.GA3219@albatros> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1311547220 3566 80.91.229.12 (24 Jul 2011 22:40:20 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 24 Jul 2011 22:40:20 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-294-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jul 25 00:40:17 2011 Return-path: Envelope-to: gllmg-musl@lo.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by lo.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Ql7LN-0004tY-1e for gllmg-musl@lo.gmane.org; Mon, 25 Jul 2011 00:40:17 +0200 Original-Received: (qmail 17678 invoked by uid 550); 24 Jul 2011 22:40:16 -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 17667 invoked from network); 24 Jul 2011 22:40:16 -0000 Content-Disposition: inline In-Reply-To: <20110724174901.GA3219@albatros> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:210 Archived-At: On Sun, Jul 24, 2011 at 09:49:03PM +0400, Vasiliy Kulikov wrote: > Rich, > > On Sun, Jul 24, 2011 at 08:24 -0400, Rich Felker wrote: > > > Even if close() fails, the fd is freed. So fd leakage is impossible. > > > > Is this true even in the case of EINTR? > > For all types of fd the fd is deleted from fd table, then > FS-specific function is called. Any error would be returned to the > program, but fd would be already deregistered. Good to know. I may need to investigate and verify that this behaves as expected in conjunction with thread cancellation while blocked at close(), and if not, work on a work-around... Do you know any reliable way to setup the kernel to block/sleep for a measurable length of time on close() so that I could test this? > I agree with POSIX in part that close() should somehow signal about > failed IO (e.g. no free disk space) and error return code is good > enough. However, I feel it was wrong to leave undefined behaviour of fd in > case of error. If the file is so important that the error must be > handled by the program, it really should do *sync() and react on its > error. IMO close() should unconditionally close fd. (The same for > fclose(3), etc.) Note that the way POSIX leaves the state of the fd indeterminate if close fails makes it impossible to write robust portable multi-threaded programs that use files in any non-trivial way. You can't retry closing a file descriptor you already passed to close, because it might get assigned to a new file opened in another thread, in which case you would close the other thread's newly-opened file. I consider this a major flaw in the standard (one of the many oversights of not considering the interaction of certain behaviors with threads) and hope to raise the issue as a defect report and push for the next version of the standard to define the behavior that the fd always be freed. Rich