public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@suse.de>
To: linux-kernel@vger.kernel.org, stable@kernel.org
Cc: Justin Forbes <jmforbes@linuxtx.org>,
	Zwane Mwaikambo <zwane@arm.linux.org.uk>,
	"Theodore Ts'o" <tytso@mit.edu>,
	Randy Dunlap <rdunlap@xenotime.net>,
	Dave Jones <davej@redhat.com>,
	Chuck Wolber <chuckw@quantumlinux.com>,
	Chris Wedgwood <reviews@ml.cw.f00f.org>,
	Michael Krufky <mkrufky@linuxtv.org>,
	Chuck Ebbert <cebbert@redhat.com>,
	Domenico Andreoli <cavokz@gmail.com>,
	torvalds@linux-foundation.org, akpm@linux-foundation.org,
	alan@lxorguk.ukuu.org.uk,
	uml-devel <user-mode-linux-devel@lists.sourceforge.net>,
	Lepton Wu <ytht.net@gmail.com>, Jeff Dike <jdike@linux.intel.com>
Subject: [patch 10/19] UML - kill subprocesses on exit
Date: Wed, 14 Nov 2007 22:14:54 -0800	[thread overview]
Message-ID: <20071115061454.GK7980@kroah.com> (raw)
In-Reply-To: <20071115061415.GA7980@kroah.com>

[-- Attachment #1: uml-kill-subprocesses-on-exit.patch --]
[-- Type: text/plain, Size: 3056 bytes --]

-stable review patch.  If anyone has any objections, please let us know.

------------------
From: Lepton Wu <ytht.net@gmail.com>

commit a24864a1d52a97e345a6bd4862a057f98364d098

uml: definitively kill subprocesses on panic

In a stock 2.6.22.6 kernel, poweroff a user mode linux guest (2.6.22.6 running
in skas0 mode) will halt the host linux.  I think the reason is the kernel
thread abort because of a bug.  Then the sys_reboot in process of user mode
linux guest is not trapped by the user mode linux kernel and is executed by
host.  I think it is better to make sure all of our children process to quit
when user mode linux kernel abort.

[ jdike - the kernel process needs to ignore SIGTERM, plus the waitpid/kill
loop is needed to make sure that all of our children are dead before the
kernel exits ]

Signed-off-by: Lepton Wu <ytht.net@gmail.com>
Signed-off-by: Jeff Dike <jdike@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/um/os-Linux/skas/process.c |    2 +-
 arch/um/os-Linux/util.c         |   38 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 39 insertions(+), 1 deletion(-)

--- a/arch/um/os-Linux/skas/process.c
+++ b/arch/um/os-Linux/skas/process.c
@@ -182,7 +182,7 @@ static int userspace_tramp(void *stack)
 
 	ptrace(PTRACE_TRACEME, 0, 0, 0);
 
-	init_new_thread_signals();
+	signal(SIGTERM, SIG_DFL);
 	err = set_interval(1);
 	if(err)
 		panic("userspace_tramp - setting timer failed, errno = %d\n",
--- a/arch/um/os-Linux/util.c
+++ b/arch/um/os-Linux/util.c
@@ -105,6 +105,44 @@ int setjmp_wrapper(void (*proc)(void *, 
 
 void os_dump_core(void)
 {
+	int pid;
+
 	signal(SIGSEGV, SIG_DFL);
+
+	/*
+	 * We are about to SIGTERM this entire process group to ensure that
+	 * nothing is around to run after the kernel exits.  The
+	 * kernel wants to abort, not die through SIGTERM, so we
+	 * ignore it here.
+	 */
+
+	signal(SIGTERM, SIG_IGN);
+	kill(0, SIGTERM);
+	/*
+	 * Most of the other processes associated with this UML are
+	 * likely sTopped, so give them a SIGCONT so they see the
+	 * SIGTERM.
+	 */
+	kill(0, SIGCONT);
+
+	/*
+	 * Now, having sent signals to everyone but us, make sure they
+	 * die by ptrace.  Processes can survive what's been done to
+	 * them so far - the mechanism I understand is receiving a
+	 * SIGSEGV and segfaulting immediately upon return.  There is
+	 * always a SIGSEGV pending, and (I'm guessing) signals are
+	 * processed in numeric order so the SIGTERM (signal 15 vs
+	 * SIGSEGV being signal 11) is never handled.
+	 *
+	 * Run a waitpid loop until we get some kind of error.
+	 * Hopefully, it's ECHILD, but there's not a lot we can do if
+	 * it's something else.  Tell os_kill_ptraced_process not to
+	 * wait for the child to report its death because there's
+	 * nothing reasonable to do if that fails.
+	 */
+
+	while ((pid = waitpid(-1, NULL, WNOHANG)) > 0)
+		os_kill_ptraced_process(pid, 0);
+
 	abort();
 }

-- 

  parent reply	other threads:[~2007-11-15  6:20 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20071115054813.977066477@mini.kroah.org>
2007-11-15  6:14 ` [patch 00/19] 2.6.23-stable review, arch specific stuff Greg KH
2007-11-15  6:14   ` [patch 01/19] Fix sparc64 niagara optimized RAID xor asm Greg KH
2007-11-15  6:14   ` [patch 02/19] Fix sparc64 MAP_FIXED handling of framebuffer mmaps Greg KH
2007-11-15  6:14   ` [patch 03/19] MIPS: MT: Fix bug in multithreaded kernels Greg KH
2007-11-15  6:14   ` [patch 04/19] MIPS: R1: Fix hazard barriers to make kernels work on R2 also Greg KH
2007-11-15  6:14   ` [patch 05/19] POWERPC: Fix handling of stfiwx math emulation Greg KH
2007-11-15  6:14   ` [patch 06/19] POWERPC: Make sure to of_node_get() the result of pci_device_to_OF_node() Greg KH
2007-11-15  6:14   ` [patch 07/19] UML - Stop using libc asm/page.h Greg KH
2007-11-15  6:14   ` [patch 08/19] UML - Fix kernel vs libc symbols clash Greg KH
2007-11-15  6:14   ` [patch 09/19] UML - stop using libc asm/user.h Greg KH
2007-11-15  6:14   ` Greg KH [this message]
2007-11-15  6:14   ` [patch 11/19] xen: add batch completion callbacks Greg KH
2007-11-15  6:15   ` [patch 12/19] xen: deal with stale cr3 values when unpinning pagetables Greg KH
2007-11-15  6:15   ` [patch 13/19] xen: fix incorrect vcpu_register_vcpu_info hypercall argument Greg KH
2007-11-15  6:15   ` [patch 14/19] xfs: eagerly remove vmap mappings to avoid upsetting Xen Greg KH
2007-11-15  6:15   ` [patch 15/19] x86: fix global_flush_tlb() bug Greg KH
2007-11-15  6:15   ` [patch 16/19] x86 setup: handle boot loaders which set up the stack incorrectly Greg KH
2007-11-15  7:27     ` H. Peter Anvin
2007-11-15 16:42       ` Greg KH
2007-11-15  6:15   ` [patch 17/19] x86 setup: sizeof() is unsigned, unbreak comparisons Greg KH
2007-11-15  6:15   ` [patch 18/19] x86: fix TSC clock source calibration error Greg KH
2007-11-15  6:15   ` [patch 19/19] revert "x86_64: allocate sparsemem memmap above 4G" Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071115061454.GK7980@kroah.com \
    --to=gregkh@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=cavokz@gmail.com \
    --cc=cebbert@redhat.com \
    --cc=chuckw@quantumlinux.com \
    --cc=davej@redhat.com \
    --cc=jdike@linux.intel.com \
    --cc=jmforbes@linuxtx.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mkrufky@linuxtv.org \
    --cc=rdunlap@xenotime.net \
    --cc=reviews@ml.cw.f00f.org \
    --cc=stable@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=tytso@mit.edu \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    --cc=ytht.net@gmail.com \
    --cc=zwane@arm.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox