aboutsummaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorErnie Petrides <petrides@redhat.com>2006-09-29 02:00:13 -0700
committerLinus Torvalds <torvalds@g5.osdl.org>2006-09-29 09:18:13 -0700
commitee731f4f7880b09ca147008ab46ad4e5f72cb8bf (patch)
treea61545ec0a04c7699727dc9e5c5c9a30b1d75ab0 /include
parent7bbab9166a82d15442357cfd63ec530b5b5fb62e (diff)
[PATCH] fix wrong error code on interrupted close syscalls
The problem is that close() syscalls can call a file system's flush handler, which in turn might sleep interruptibly and ultimately pass back an -ERESTARTSYS return value. This happens for files backed by an interruptible NFS mount under nfs_file_flush() when a large file has just been written and nfs_wait_bit_interruptible() detects that there is a signal pending. I have a test case where the "strace" command is used to attach to a process sleeping in such a close(). Since the SIGSTOP is forced onto the victim process (removing it from the thread's "blocked" mask in force_sig_info()), the RPC wait is interrupted and the close() is terminated early. But the file table entry has already been cleared before the flush handler was called. Thus, when the syscall is restarted, the file descriptor appears closed and an EBADF error is returned (which is wrong). What's worse, there is the hypothetical case where another thread of a multi-threaded application might have reused the file descriptor, in which case that file would be mistakenly closed. The bottom line is that close() syscalls are not restartable, and thus -ERESTARTSYS return values should be mapped to -EINTR. This is consistent with the close(2) manual page. The fix is below. Signed-off-by: Ernie Petrides <petrides@redhat.com> Cc: Roland McGrath <roland@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions