Re: [PATCH] Manual should discourage mixing TEMP_FAILURE_RETRY and close

[Rich Felker <dalias at aerifal dot cx>]

On Wed, Dec 04, 2013 at 01:08:21AM +0100, OndÅej BÃlka wrote:
> On Tue, Dec 03, 2013 at 01:05:21PM -0500, Mark Mentovai wrote:
> > When the close system call is interrupted by a signal, the state of its
> > file descriptor argument is not specified[1]. On Linux, a close that
> > fails with EINTR must not be restarted because the file descriptor is
> > guaranteed to have been closed at that point[2]. Note that the kernel
> > itself never restarts a close when SA_RESTART is set or when no
> > user-space signal handler is present[3].
> >
> This is linux problem, POSIX now says
> 
> http://austingroupbugs.net/view.php?id=529 
> 
> If close( ) is interrupted by a signal that is to be caught, then it
> is unspecified whether it returns -1 with errno set to [EINTR] with
> fildes remaining open, or returns -1 with errno set to [EINPROGRESS]
> [...]

Assuming Linux will never switch to the correct POSIX EINTR behavior
(the kernel folks are adamantly against it), would it be acceptable
for glibc to fix up the resulting errno value from EINTR to
EINPROGRESS, so that correct applications following POSIX will not
loop on EINTR and introduce (extremely dangerous) double-close bugs?
As long as the kernel folks are committed to keeping the current
behavior, getting EINTR from the kernel essentially means EINPROGRESS
and I think the replacement is justified. That's what I'm doing in
musl.

BTW if glibc ever fixes the cancellation races (bug #12683) handling
close correctly there is important too (you can't act on cancellation
when it interrupts a close syscall because the side effects have
already completed, despite the errno value from the kernel, EINTR,
making it appear that side effects did not occur).

Rich