From: Bodo Stroesser <bstroesser@fujitsu-siemens.com>
To: Jeff Dike <jdike@addtoit.com>
Cc: Blaisorblade <blaisorblade_spam@yahoo.it>,
user-mode-linux devel
<user-mode-linux-devel@lists.sourceforge.net>
Subject: [uml-devel] Re: The current fix-kill patch
Date: Tue, 23 Nov 2004 16:10:28 +0100 [thread overview]
Message-ID: <41A352E4.5050607@fujitsu-siemens.com> (raw)
In-Reply-To: <200411230550.iAN5o8mY007302@ccure.user-mode-linux.org>
Jeff Dike wrote:
> Here's the latest fix-kill patch in my tree. Please test and report...
Have tested based on 2.6.9-bb3. I removed "rework-uml-hang-on-2.6.9-host",
added BlaisorBlade's "uml-hang-on-2.6.9-host", and adapted iand added this
new patch. The resulting UML kernel for me works fine on host 2.6.7-skas3-v7
and 2.6.9-skas3-v7.
Next, I tested what happens if the "kill(pid, SIGKILL);" and
"ptrace(PTRACE_CONT, pid);" are removed from os_kill_ptraced_process(), and
it also worked fine.
Since PTRACE_KILL wakes up the ptraced process unconditionally, IMHO
"ptrace(PTRACE_CONT, pid);" has no effect here. And "kill(pid, SIGKILL);"
only is needed, if the ptraced process is not stopped on a ptrace-interception.
Since os_kill_ptraced_process() is called only then, when the ptraced process
is known to be on a ptrace-stop, I would like to remove "kill(pid, SIGKILL);",
too.
os_kill_ptraced_process() is called each time, a process in TT exec()s. Thus
avoiding unneeded calls is a little speedup.
Bodo
>
> Jeff
>
> # This patch changes how UML kills ptraced processes in order to be more
> # correct in the presence of the ptrace changes in 2.6.9. It used to be that
> # ptrace stopped processes could simply be killed and they would go away. Now,
> # there's a new run state for ptraced processes which doesn't receive signals
> # until they are PTRACE_KILLed or PTRACE_CONTinued. So, this patch kills the
> # process, as usual, then PTRACE_KILL and PTRACE_CONT. This is done in
> # os_kill_ptrace_process() for use from skas mode, and in tracer() when it
> # sees a child process getting a SIGKILL.
> Index: 2.6.9/arch/um/kernel/tt/exec_user.c
> ===================================================================
> --- 2.6.9.orig/arch/um/kernel/tt/exec_user.c 2004-11-22 12:18:40.000000000 -0500
> +++ 2.6.9/arch/um/kernel/tt/exec_user.c 2004-11-22 13:24:50.000000000 -0500
> @@ -36,7 +36,7 @@
> tracer_panic("do_exec failed to get registers - errno = %d",
> errno);
>
> - kill(old_pid, SIGKILL);
> + os_kill_ptraced_process(old_pid, 0);
>
> if (ptrace(PTRACE_SETOPTIONS, new_pid, 0, (void *)PTRACE_O_TRACESYSGOOD) < 0)
> tracer_panic("do_exec: PTRACE_SETOPTIONS failed, errno = %d", errno);
> Index: 2.6.9/arch/um/kernel/tt/process_kern.c
> ===================================================================
> --- 2.6.9.orig/arch/um/kernel/tt/process_kern.c 2004-11-18 21:24:08.000000000 -0500
> +++ 2.6.9/arch/um/kernel/tt/process_kern.c 2004-11-22 12:18:43.000000000 -0500
> @@ -65,7 +65,8 @@
> panic("write of switch_pipe failed, err = %d", -err);
>
> reading = 1;
> - if((from->exit_state == EXIT_ZOMBIE) || (from->exit_state == EXIT_DEAD))
> + if((from->exit_state == EXIT_ZOMBIE) ||
> + (from->exit_state == EXIT_DEAD))
> os_kill_process(os_getpid(), 0);
>
> err = os_read_file(from->thread.mode.tt.switch_pipe[0], &c, sizeof(c));
> @@ -82,7 +83,7 @@
> prev_sched = current->thread.prev_sched;
> if((prev_sched->exit_state == EXIT_ZOMBIE) ||
> (prev_sched->exit_state == EXIT_DEAD))
> - os_kill_ptraced_process(prev_sched->thread.mode.tt.extern_pid, 1);
> + os_kill_process(prev_sched->thread.mode.tt.extern_pid, 1);
>
> /* This works around a nasty race with 'jail'. If we are switching
> * between two threads of a threaded app and the incoming process
> Index: 2.6.9/arch/um/kernel/tt/tracer.c
> ===================================================================
> --- 2.6.9.orig/arch/um/kernel/tt/tracer.c 2004-11-22 12:18:40.000000000 -0500
> +++ 2.6.9/arch/um/kernel/tt/tracer.c 2004-11-22 13:28:01.000000000 -0500
> @@ -320,7 +320,13 @@
> case OP_HALT:
> unmap_physmem();
> kmalloc_ok = 0;
> - ptrace(PTRACE_KILL, pid, 0, 0);
> + os_kill_ptraced_process(pid, 0);
> + /* Now let's reap remaining zombies */
> + errno = 0;
> + do {
> + waitpid(-1, &status,
> + WUNTRACED);
> + } while (errno != ECHILD);
> return(op == OP_REBOOT);
> case OP_NONE:
> printf("Detaching pid %d\n", pid);
> Index: 2.6.9/arch/um/os-Linux/process.c
> ===================================================================
> --- 2.6.9.orig/arch/um/os-Linux/process.c 2004-11-18 21:24:08.000000000 -0500
> +++ 2.6.9/arch/um/os-Linux/process.c 2004-11-22 12:18:43.000000000 -0500
> @@ -95,9 +95,16 @@
>
> }
>
> +/* Kill off a ptraced child by all means available. kill it normally first,
> + * then PTRACE_KILL it, then PTRACE_CONT it in case it's in a run state from
> + * which it can't exit directly.
> + */
> +
> void os_kill_ptraced_process(int pid, int reap_child)
> {
> + kill(pid, SIGKILL);
> ptrace(PTRACE_KILL, pid);
> + ptrace(PTRACE_CONT, pid);
> if(reap_child)
> CATCH_EINTR(waitpid(pid, NULL, 0));
> }
>
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
next prev parent reply other threads:[~2004-11-23 15:10 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-23 5:50 [uml-devel] The current fix-kill patch Jeff Dike
2004-11-23 15:10 ` Bodo Stroesser [this message]
2004-11-23 20:10 ` [uml-devel] " Blaisorblade
2004-11-24 11:18 ` Bodo Stroesser
2004-11-25 4:09 ` Blaisorblade
2004-11-25 10:13 ` Bodo Stroesser
2004-12-01 18:20 ` Jason Lunz
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=41A352E4.5050607@fujitsu-siemens.com \
--to=bstroesser@fujitsu-siemens.com \
--cc=blaisorblade_spam@yahoo.it \
--cc=jdike@addtoit.com \
--cc=user-mode-linux-devel@lists.sourceforge.net \
/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