Bug 789393

Description of problem:
The next version of POSIX will require that if close(fd) returns -1 with errno set to EINTR, because the close operation was interrupted by a signal and can be resumed, then fd must be kept open.  For all other errno values (such as EIO), the current kernel behavior of closing fd in addition to reporting the error is appropriate.  I have not audited the kernel to find out if any of the file system drivers can ever return EINTR back to the kernel, but if they can, then the kernel has a bug for blindly closing fd during close().

Version-Release number of selected component (if applicable):
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=fs/open.c;h=77becc04114908fae2a45f655ed22996264723ad;hb=HEAD#l1063

How reproducible:


Steps to Reproduce:
1. determine if any file system can fail with EINTR (perhaps a long-running NFS situation, where a signal can return control to the user prior to the close completing)
2.
3.
  
Actual results:
if the kernel blindly closes fd and then returns EINTR failure, the application will assume according to POSIX that it can re-attempt close(fd), but the kernel may have opened another unrelated file to fd in the meantime, and the second close will do the wrong thing

Expected results:
Either the kernel must never fail close() with EINTR, or on EINTR failure (and just EINTR), the kernel must guarantee that fd stays open to the same file.

Additional info:
http://austingroupbugs.net/view.php?id=529#c1107