diff options
author | Will Deacon <will.deacon@arm.com> | 2012-07-04 17:17:16 (GMT) |
---|---|---|
committer | Russell King <rmk+kernel@arm.linux.org.uk> | 2012-07-05 08:50:56 (GMT) |
commit | 433e2f307beff8adba241646ce9108544e0c5a03 (patch) | |
tree | 8f816b84bae19872ade5db31fe3d6f223dc52675 /arch/x86/kernel/tsc_sync.c | |
parent | 3b0c06226783ffc836217eb34f7eca311b1e63f7 (diff) | |
download | linux-fsl-qoriq-433e2f307beff8adba241646ce9108544e0c5a03.tar.xz |
ARM: 7443/1: Revert "new way of handling ERESTART_RESTARTBLOCK"
This reverts commit 6b5c8045ecc7e726cdaa2a9d9c8e5008050e1252.
Conflicts:
arch/arm/kernel/ptrace.c
The new syscall restarting code can lead to problems if we take an
interrupt in userspace just before restarting the svc instruction. If
a signal is delivered when returning from the interrupt, the
TIF_SYSCALL_RESTARTSYS will remain set and cause any syscalls executed
from the signal handler to be treated as a restart of the previously
interrupted system call. This includes the final sigreturn call, meaning
that we may fail to exit from the signal context. Furthermore, if a
system call made from the signal handler requires a restart via the
restart_block, it is possible to clear the thread flag and fail to
restart the originally interrupted system call.
The right solution to this problem is to perform the restarting in the
kernel, avoiding the possibility of handling a further signal before the
restart is complete. Since we're almost at -rc6, let's revert the new
method for now and aim for in-kernel restarting at a later date.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Diffstat (limited to 'arch/x86/kernel/tsc_sync.c')
0 files changed, 0 insertions, 0 deletions