[pacman-dev] [PATCH] Looping for EINTR on close() is wrong on Linux

[Simon Gomizelj]

On Sun, Jun 30, 2013 at 11:46:59AM +1000, Allan McRae wrote:
> On 30/06/13 11:13, Sergio Correia wrote:
>> From: Sergio Correia <sergio at correia.cc>
>> 
>> Linux closes the descriptor unconditionally even if the close() call is
>> interrupted.
> 
> Is this also the case for other ELF using systems we support (BSD,
> HURD)?  I believe it is but I am being too lazy to check.
> 

>From https://news.ycombinator.com/item?id=3363819

Some quotes:

> FreeBSD: It seems pretty clear in FreeBSD that you should not retry
> the call to close(); sys_close() calls kern_close() which locks the
> file, frees the file descriptor (!), and /then/ calls closef() (which,
> if capable of returning EINTR, is already too late).

> Mac OS X: Here you should not retry, but you should also be careful;
> depending on whether you are UNIX2003 you will get different behavior
> from the close() function from libSystem, directing you to either the
> syscall close() or close_nocancel().

AIX also closes the fd immediately, while HPUX requires the loop. Idk if
we explicitly support either of those two, but it looks like we're safe
in killing the close loop.

That said, the loop is possibly a source of bugs for another reason,
apparently its possible for the fd to have been closed and reused by the
time EINTR fires, causing an unrelated fd to be closed.

> As discussed in this thread, many POSIX implementations, including
> Linux, will release the file descriptor immediately, and so if close()
> fails with EINTR, it is possible that the file descriptor has already
> been reclaimed and in use by some other component. Retrying the close
> call, therefore, might close some other component's descriptor.

 - https://sites.google.com/site/michaelsafyan/software-engineering/checkforeintrwheninvokingclosethinkagain
 - http://linux.derkeiler.com/Mailing-Lists/Kernel/2005-09/3000.html