From owner-freebsd-hackers@freebsd.org Fri Jan 5 22:13:37 2018 Return-Path: <owner-freebsd-hackers@freebsd.org> 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 <freebsd-hackers@mailman.ysv.freebsd.org>; 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 <brooks@freebsd.org> To: Alan Somers <asomers@freebsd.org> Cc: Ian Lepore <ian@freebsd.org>, Yuri <yuri@rawbw.com>, Freebsd hackers list <freebsd-hackers@freebsd.org> 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> <CAOtMX2jSonHQ9xzVD3Q9XS2twBm_CT3Tquwn+f6zmc7aV0QerQ@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+nBD6E3TurpgldQp" Content-Disposition: inline In-Reply-To: <CAOtMX2jSonHQ9xzVD3Q9XS2twBm_CT3Tquwn+f6zmc7aV0QerQ@mail.gmail.com> 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 <freebsd-hackers.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-hackers>, <mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers/> List-Post: <mailto:freebsd-hackers@freebsd.org> List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, <mailto:freebsd-hackers-request@freebsd.org?subject=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 <ian@freebsd.org> 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--