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

[LANGLOIS Olivier PIS -EXT]

>
> On Wed, Jul 3, 2013 at 4:38 PM, Simon Gomizelj <simongmzlj at gmail.com>
> wrote:
> > 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/check
> > foreintrwheninvokingclosethinkagain
> >  - http://linux.derkeiler.com/Mailing-Lists/Kernel/2005-09/3000.html
>
> Given that we are single-threaded, I don't see how this is possible.
>
> -Dan

Correct, there is no risk that to have a race condition with another thread that would reuse a fd between 2 successive close() calls.

However, in the case close() returns EINTR, calling close() a second will invariably fail so, IMO, there is no point doing it.

sys_close does the following:

release the process fd table entry atomically (cannot be interrupted, cannot fail for valid fd)
flush to disk remaining data still in write buffer. (This part can be interrupted)

For those interested, it is pretty simple code in the kernel:

fs/open.c close() calls __close_fd
fs/file.c __close_fd(): 1. release fdt entry, 2. calls filp_close()
fs/open.c filp_close(): Calls filp->f_op->flush and this the only operation that can be interrupted.

I do not think that it is a big deal but if you really want to address correctly in regards to EINTR, just call fsync(fd) successfully and loop on it if it returns EINTR before closing the fd. That way, you pretty much guaranty that close() will not return EINTR.



________________________________
CONFIDENTIALITY : This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium.