linux-um archives
 help / color / mirror / Atom feed
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

  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