[Dnsmasq-discuss] Is wrapping close() in retry_send() required ?

[Simon Kelley]

On 27/02/2019 15:06, Bogdan Harjoc wrote:
> There are 50 calls to close() in dnsmasq-2.80, and 10 of them are
> wrapped in retry_send().
> 
> "man close" has this paragraph in the section "Dealing with error
> returns from close":
> 
> "Retrying the close() after a failure return is the wrong thing to do,
> since this may cause a reused file descriptor from another thread to
> be closed. This can occur because the Linux kernel always releases the
> file descriptor early in the close operation, freeing it for reuse;
> the steps that may return an error, such as flushing data to the
> filesystem or device, occur only later in the close operation".
> 
> Dnsmasq is single-threaded so the retry_send() call is probably
> harmless. Are there other OSes that may return an error before the fd
> is released, in other words is there an OS where wrapping close in
> retry_send is required ?


Good questions.

Note that retry_send() only deals with EINTR return codes, ie
interrupted system calls. (Ok there are other return codes in there, but
nothing which might be returned by close())

So the use of retry_send(close(...)) is simply to restart the close()
syscall if a signal arrives during the syscall.


HOWEVER, whilst the man page for close() on my Linux machine states that
EINTR is a possible error return, man (7) signal does NOT include
close() in the set of syscalls which can be interrupted.

Clearly I was reading the close() man page when I used the wrapper, and
signal man page when I didn't :)


You're probably right that it doesn't matter, but it would be nice to
make this at least consistent.

Anyone know the answer?


Cheers,

Simon.