This is the mail archive of the
mailing list for the glibc project.
Re: [RFC][BZ #14627] Make linux close errno to EINPROGRESS when interrupted in signal.
- From: Rich Felker <dalias at aerifal dot cx>
- To: David Miller <davem at davemloft dot net>
- Cc: eagle at eyrie dot org, libc-alpha at sourceware dot org
- Date: Thu, 5 Dec 2013 19:53:37 -0500
- Subject: Re: [RFC][BZ #14627] Make linux close errno to EINPROGRESS when interrupted in signal.
- Authentication-results: sourceware.org; auth=none
- References: <20131205 dot 155009 dot 707968344039994800 dot davem at davemloft dot net> <87ob4vggn3 dot fsf at windlord dot stanford dot edu> <20131205223223 dot GQ24286 at brightrain dot aerifal dot cx> <20131205 dot 193739 dot 882517176297322058 dot davem at davemloft dot net>
On Thu, Dec 05, 2013 at 07:37:39PM -0500, David Miller wrote:
> From: Rich Felker <firstname.lastname@example.org>
> Date: Thu, 5 Dec 2013 17:32:23 -0500
> > http://austingroupbugs.net/view.php?id=529
> > The new requirement is that EINTR means the fd is still open and
> > EINPROGRESS means the operation was interrupted by a signal but the fd
> > is no longer valid.
> A behavior specified by POSIX is quite pointless considering decades
> of precedence, which to me is more important than any standards
If you read the above link, the decades of precedence were that, on
systems where it's actually implemented and matters, EINTR from close
meant the fd was still open. IIRC it was mainly for tape drives that
blocked in close until the tape was rewound, which was obviously a
stupid design to begin with, but applications were depending on it.
> close() cannot error if it is given a valid file descriptor, it would
> break decades worth of existing code. And practically speaking,
> returning errors on close() was tried for NFS in the Linux kernel
> about 12 or 13 years ago, things broke and we had to revert that
> change immediately. You simply cannot do it.
At least in the current kernel, EINTR _can_ happen if the device goes
into interruptible sleep during flush. I have a test module that
implements such a driver and you can observe close returning EINTR.
I'm not sure whether there are drivers in the official kernel that can
return EINTR, but I wouldn't be surprised if some tape drivers do it,
since that was the legacy/historical behavior for tapes.
I do agree that it shouldn't happen. I'm all in favor of making the
kernel guarantee that close never returns anything but 0 or EBADF.
> Leaving a file descriptor open after a close() is also asking for very
> serious security problems. Just unpack an arbitary source tree and
> grep for close() calls, how many are checking for errors at all?
Most are not, hopefully, since they only thing they could do by
checking (assuming the current Linux behavior) is make their behavior
> Of the few that do, how do they handle it? Most just do something on
> the order of abort().
Most GNU programs using gnulib check for an error closing stdout
before they exit and adjust their exit status accordingly. I doubt
anything else checks.