* [PATCH, RFC] endless loop when processing signals for kernel-space tasks
@ 2012-03-22 20:39 dimm
2012-03-22 21:27 ` [tip:x86/urgent] x86-32: Fix endless loop when processing signals for kernel tasks tip-bot for Dmitry Adamushko
0 siblings, 1 reply; 2+ messages in thread
From: dimm @ 2012-03-22 20:39 UTC (permalink / raw)
To: Ingo Molnar, Thomas Gleixner, H. Peter Anvin
Cc: LKML, Oleg Nesterov, Andrew Morton, Roland McGrath
From: Dmitry Adamushko <dmitry.adamushko@gmail.com>
The problem occurs on !CONFIG_VM86 kernels [1] when a kernel-mode task returns from a system call with a pending signal.
A real-life scenario is a child of 'khelper' returning from a failed kernel_execve() in ____call_usermodehelper() [ kernel/kmod.c ].
kernel_execve() fails due to a pending SIGKILL, which is the result of "kill -9 -1" (at least, busybox's init does it upon reboot).
The loop is as follows:
* syscall_exit_work:
- work_pending: // start_of_the_loop
- work_notify_sig:
- do_notify_resume()
- do_signal()
- if (!user_mode(regs)) return;
- resume_userspace // TIF_SIGPENDING is still set
- work_pending // so we call work_pending => goto
// start_of_the_loop
More information can be found in another LKML thread: http://www.serverphorums.com/read.php?12,457826
[1] the problem was also seen on MIPS.
Thanks in advance for any feedback!
Signed-off-by: Dmitry Adamushko <dmitry.adamushko@gmail.com>
CC: Oleg Nesterov <oleg@redhat.com>
CC: Ingo Molnar <mingo@elte.hu>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: "H. Peter Anvin" <hpa@zytor.com>,
CC: Roland McGrath <roland@hack.frob.com>
CC: Andrew Morton <akpm@linux-foundation.org>
diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
index 79d97e6..7b784f4 100644
--- a/arch/x86/kernel/entry_32.S
+++ b/arch/x86/kernel/entry_32.S
@@ -98,12 +98,6 @@
#endif
.endm
-#ifdef CONFIG_VM86
-#define resume_userspace_sig check_userspace
-#else
-#define resume_userspace_sig resume_userspace
-#endif
-
/*
* User gs save/restore
*
@@ -327,10 +321,19 @@ ret_from_exception:
preempt_stop(CLBR_ANY)
ret_from_intr:
GET_THREAD_INFO(%ebp)
-check_userspace:
+resume_userspace_sig:
+#ifdef CONFIG_VM86
movl PT_EFLAGS(%esp), %eax # mix EFLAGS and CS
movb PT_CS(%esp), %al
andl $(X86_EFLAGS_VM | SEGMENT_RPL_MASK), %eax
+#else
+ /*
+ * We can be coming here from a syscall done in the kernel space,
+ * e.g. a failed kernel_execve().
+ */
+ movl PT_CS(%esp), %eax
+ andl $SEGMENT_RPL_MASK, %eax
+#endif
cmpl $USER_RPL, %eax
jb resume_kernel # not returning to v8086 or userspace
^ permalink raw reply related [flat|nested] 2+ messages in thread
* [tip:x86/urgent] x86-32: Fix endless loop when processing signals for kernel tasks
2012-03-22 20:39 [PATCH, RFC] endless loop when processing signals for kernel-space tasks dimm
@ 2012-03-22 21:27 ` tip-bot for Dmitry Adamushko
0 siblings, 0 replies; 2+ messages in thread
From: tip-bot for Dmitry Adamushko @ 2012-03-22 21:27 UTC (permalink / raw)
To: linux-tip-commits
Cc: linux-kernel, hpa, mingo, stable, akpm, dmitry.adamushko, tglx,
oleg, roland
Commit-ID: 29a2e2836ff9ea65a603c89df217f4198973a74f
Gitweb: http://git.kernel.org/tip/29a2e2836ff9ea65a603c89df217f4198973a74f
Author: Dmitry Adamushko <dmitry.adamushko@gmail.com>
AuthorDate: Thu, 22 Mar 2012 21:39:25 +0100
Committer: H. Peter Anvin <hpa@zytor.com>
CommitDate: Thu, 22 Mar 2012 13:50:25 -0700
x86-32: Fix endless loop when processing signals for kernel tasks
The problem occurs on !CONFIG_VM86 kernels [1] when a kernel-mode task
returns from a system call with a pending signal.
A real-life scenario is a child of 'khelper' returning from a failed
kernel_execve() in ____call_usermodehelper() [ kernel/kmod.c ].
kernel_execve() fails due to a pending SIGKILL, which is the result of
"kill -9 -1" (at least, busybox's init does it upon reboot).
The loop is as follows:
* syscall_exit_work:
- work_pending: // start_of_the_loop
- work_notify_sig:
- do_notify_resume()
- do_signal()
- if (!user_mode(regs)) return;
- resume_userspace // TIF_SIGPENDING is still set
- work_pending // so we call work_pending => goto
// start_of_the_loop
More information can be found in another LKML thread:
http://www.serverphorums.com/read.php?12,457826
[1] the problem was also seen on MIPS.
Signed-off-by: Dmitry Adamushko <dmitry.adamushko@gmail.com>
Link: http://lkml.kernel.org/r/1332448765.2299.68.camel@dimm
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Roland McGrath <roland@hack.frob.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
---
arch/x86/kernel/entry_32.S | 17 ++++++++++-------
1 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
index 79d97e6..7b784f4 100644
--- a/arch/x86/kernel/entry_32.S
+++ b/arch/x86/kernel/entry_32.S
@@ -98,12 +98,6 @@
#endif
.endm
-#ifdef CONFIG_VM86
-#define resume_userspace_sig check_userspace
-#else
-#define resume_userspace_sig resume_userspace
-#endif
-
/*
* User gs save/restore
*
@@ -327,10 +321,19 @@ ret_from_exception:
preempt_stop(CLBR_ANY)
ret_from_intr:
GET_THREAD_INFO(%ebp)
-check_userspace:
+resume_userspace_sig:
+#ifdef CONFIG_VM86
movl PT_EFLAGS(%esp), %eax # mix EFLAGS and CS
movb PT_CS(%esp), %al
andl $(X86_EFLAGS_VM | SEGMENT_RPL_MASK), %eax
+#else
+ /*
+ * We can be coming here from a syscall done in the kernel space,
+ * e.g. a failed kernel_execve().
+ */
+ movl PT_CS(%esp), %eax
+ andl $SEGMENT_RPL_MASK, %eax
+#endif
cmpl $USER_RPL, %eax
jb resume_kernel # not returning to v8086 or userspace
^ permalink raw reply related [flat|nested] 2+ messages in thread
end of thread, other threads:[~2012-03-22 21:27 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-03-22 20:39 [PATCH, RFC] endless loop when processing signals for kernel-space tasks dimm
2012-03-22 21:27 ` [tip:x86/urgent] x86-32: Fix endless loop when processing signals for kernel tasks tip-bot for Dmitry Adamushko
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.