From owner-freebsd-hackers@freebsd.org Fri Jan 5 22:13:37 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C1860EC3E69 for ; Fri, 5 Jan 2018 22:13:37 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8F476169E; Fri, 5 Jan 2018 22:13:37 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 4894E5A9F14; Fri, 5 Jan 2018 22:13:30 +0000 (UTC) Date: Fri, 5 Jan 2018 22:13:30 +0000 From: Brooks Davis To: Alan Somers Cc: Ian Lepore , Yuri , Freebsd hackers list Subject: Re: Is it considered to be ok to not check the return code of close(2) in base? Message-ID: <20180105221330.GD95035@spindle.one-eyed-alien.net> References: <24acbd94-c52f-e71a-8a96-d608a10963c6@rawbw.com> <1514572041.12000.7.camel@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+nBD6E3TurpgldQp" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 22:13:37 -0000 --+nBD6E3TurpgldQp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 29, 2017 at 11:48:43AM -0700, Alan Somers wrote: > On Fri, Dec 29, 2017 at 11:27 AM, Ian Lepore wrote: >=20 > > On Fri, 2017-12-29 at 10:19 -0800, Yuri wrote: > > > Some base utilities sometimes close files that they open for their > > > purposes without checking the error code of close(2). > > > > > > Is this considered to be ok, because it's just a close call and we > > > are > > > done with that file descriptor, or is it considered to be more > > > appropriate to check close's error code? > > > > > > Maybe there is some policy that covers this? > > > > > > IMO, every system call's return value should be checked, just in > > > case. > > > > > > > > > Yuri > > > > > > > There's really no point in checking on a close from a file opened only > > for reading. You can argue it should be checked on a file open for > > writing, but often isn't because you're then confronted with the > > question "what should/can I do if there is an error?" If you report > > the error and exit, then what about other files that were open at the > > time? They're going to be closed by the kernel as part of process > > cleanup, with no error checking or reporting. > > > > Also, with the async nature of filesystems, IO errors can still happen > > after the close, unless fsync() was used. So if you're going to miss > > most of the errors because of that, why bother to check at all? >=20 > I would argue the opposite. There are very few reasons why close(s) would > ever fail, and the most likely is EBADF. EBADF indicates a programming > bug, like a double close or use of an uninitialized variable. Those could > easily turn into worse bugs in the future. So I think the best course of > action is to check the return code, assert() on EBADF, and ignore, or > possibly log, other errors. For this specific case, I think there would be value in an option to have the kernel kill any process that calls close(fd) where fd !=3D -1 where EBADF would be returned. -- Brooks --+nBD6E3TurpgldQp Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJaT/iJAAoJEKzQXbSebgfA7H0H/15jVVj8i+VQiKgNArRqgSXN aYWjS+ED53M9Vzca/1/clCmApw0qujYCDzhcKOQ7icIw0hnRYcB2pDTWoQDQ/NDd UC8y/PsLE2sSxHBefsCJUb2RX72BpVgiuW5ZrcCjZP6hm2ovxRAVbuMPbVWDMSa7 lID8x+kLT+8pE1Dq6zRwJPfWxZZnvwGZVROSt0rReXCjvreVid59YYbXYYfobHk2 /DqeFiCb7YgsC1YTyS3BhFnFUtYF+R5ZKLSKEAEAFWM1SAKepb8a/u09kpSry7R2 9K5dBHymjk4LbgwZ1MatrFpbEJkjwWmHaGVj8k1cyi0KqlSNxYx/UViH7mewV+w= =bbht -----END PGP SIGNATURE----- --+nBD6E3TurpgldQp--