Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 05 Jan 2018 22:34:35 +0000
From:      "Poul-Henning Kamp" <phk@phk.freebsd.dk>
To:        Brooks Davis <brooks@freebsd.org>
Cc:        Alan Somers <asomers@freebsd.org>, Yuri <yuri@rawbw.com>, Ian Lepore <ian@freebsd.org>, 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:  <24173.1515191675@critter.freebsd.dk>
In-Reply-To: <20180105221330.GD95035@spindle.one-eyed-alien.net>
References:  <24acbd94-c52f-e71a-8a96-d608a10963c6@rawbw.com> <1514572041.12000.7.camel@freebsd.org> <CAOtMX2jSonHQ9xzVD3Q9XS2twBm_CT3Tquwn%2Bf6zmc7aV0QerQ@mail.gmail.com> <20180105221330.GD95035@spindle.one-eyed-alien.net>

next in thread | previous in thread | raw e-mail | index | archive | help
--------
In message <20180105221330.GD95035@spindle.one-eyed-alien.net>, Brooks Dav=
is writes:

>> I would argue the opposite.  There are very few reasons why close(s) wo=
uld
>> ever fail, and the most likely is EBADF.  EBADF indicates a programming
>> bug, like a double close or use of an uninitialized variable.  Those co=
uld
>> 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.

I fully agree on the seriousness of EBADF from close, but want to note
that close (2) used on sockets return a bestiarium of errors depending
on how the remote slammed the door.

>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.

I think -current ought to be much more paranoid towards bugs.

When I added phkmalloc to -current many years ago, I set the default
flags to AJ and the first program which exploded on me was fsck(8),
and the next dozen or so were all setuid or setgid.

Brookes suggestion, while well intentioned, wouldn't get very far,
because it is common for shells and shell-like programs to do:

	for (i =3D 3; i < ALOT; i++)
		(void)close(i);

To get rid of unwanted filedescriptors from syslog(3), getpwent(3) etc.
in the child process.

Yes, I know about closefrom(2), but a lot of programs still don't use it.

So yes please, make libc and the kernel complain about anything
which looks like programming errors in -current, but hold off on
the process-killing, and make it possible to silence these complaints
at boot-time.

Maybe we should simply add a "bootparanoia" flag like we have "bootverbose=
" ?


-- =

Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    =

Never attribute to malice what can adequately be explained by incompetence=
.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?24173.1515191675>