Skip to contentSkip to conversation

Host processes never terminate on 2.6.9rc3 host (stuck in ptrace_stop)

uml-devel BlaisorBlade 5 participants 14 messages Oct 18, 2004 – Oct 21, 2004 2 messages not in the archive

Subsystems (9)
lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): [email protected]

#2 lore raw
Quoted 10 lines · Gerd Knorr
Quoted 8 lines · Lorenzo Colitti

Using a 2.6.8.1 UML kernel on a 2.6.9-rc3 host in tt mode, my "linux" processes on the host hang around forever, even if I shut the virtual machine down with halt.

P.S. Might this be due to a change to ptrace committed in 2.6.9rc1? There's something about ptrace_stop in this changelog:
http://www.kernel.org/pub/linux/kernel/v2.6/snapshots/old/patch-2.6.9-rc1
-bk16.log

Quoted 5 lines

Yes, I see that as well, it actually *is* that ptrace change added in patch-2.6.9-rc1-bk16.

IMHO it is a bug, I've reported it to lkml a
few days ago, no response yet.

Oh well, did I lost it or you did not CC the UML mailing list? And in the 2nd case, why? I'm downloading the patches from BitKeeper. This are the links (not guaranted to work, I should have used "bookmarkable link" but I may have missed some ones):

http://linux.bkbits.net:8080/linux-2.5/cset@413f1c0bviEp6fHuuZpUWED2M7lWWA?nav=index.html|
tags|[email protected]
http://linux.bkbits.net:8080/linux-2.5/cset@413f1c00MHeKsQfqBGA5McsDQ71Rmg?nav=index.html|
tags|[email protected]
http://linux.bkbits.net:8080/linux-2.5/cset@413f1bdabfaQNzIZpU6bPxNlSxdriQ?nav=index.html|
tags|[email protected]
http://linux.bkbits.net:8080/linux-2.5/cset@413f1be9vIHHLGwHUvcNtaZDwKSuig?nav=index.html|
tags|[email protected]

There is one patch in particular mentioning ptrace_stop, but the other ones are related to it, too (except the one about strace catching even invalid syscalls).

Quoted 2 lines

Problem is that you can't kill -9 processes any more which are ptraced _and_ stopped at the same time.

Sorry, tried kill -CONT? I'm almost sure it works (tried by both Henrik Normstrod and me, not in this case).

Quoted 2 lines

skas mode isn't hit that badly by the bug, it "only" hangs on shutdown/reboot.

Signature · 13 lines
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
#3 lore raw
Quoted 8 lines
Quoted 5 lines

Yes, I see that as well, it actually *is* that ptrace change added in patch-2.6.9-rc1-bk16.

IMHO it is a bug, I've reported it to lkml a
few days ago, no response yet.

Oh well, did I lost it or you did not CC the UML mailing list? And in the 2nd case, why?

I didn't cc the uml list as it isn't a uml bug, its just that uml triggeres it.

Quoted 1 line

I'm downloading the patches from BitKeeper.

I'll attach the offending one for reference, also a short test app showing the buggy behavior.

Quoted 4 lines
Quoted 2 lines

Problem is that you can't kill -9 processes any more which are ptraced _and_ stopped at the same time.

Sorry, tried kill -CONT? I'm almost sure it works (tried by both Henrik Normstrod and me, not in this case).

IMHO it is a clear bug in the (host) kernel, so I didn't attempt yet to workaround that by playing tricks in the UML kernel. I can't see the bug when reading the patch through, probably the separation of stopped and traced process states triggeres some odd corner case somewhere else in the kernel ...

If you send a SIGKILL to the process being stopped & ptraced *nothing* happens. Neither the process is killed nor the ptracing parent is notified. That can't be correct.

Gerd

Signature · 1 line
return -ENOSIG;

# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher. # This patch includes the following deltas:
# ChangeSet 1.1832.54.191 -> 1.1832.54.192
# kernel/power/process.c 1.9 -> 1.10
# include/linux/sched.h 1.252 -> 1.253
# arch/arm/kernel/ptrace.c 1.24 -> 1.25
# arch/parisc/kernel/ptrace.c 1.11 -> 1.12
# arch/m68k/kernel/ptrace.c 1.11 -> 1.12
# arch/h8300/kernel/ptrace.c 1.5 -> 1.6
# kernel/signal.c 1.132 -> 1.133
# arch/v850/kernel/ptrace.c 1.3 -> 1.4
# arch/arm26/kernel/ptrace.c 1.1 -> 1.2
# arch/m68knommu/kernel/ptrace.c 1.1 -> 1.2
# fs/proc/array.c 1.67 -> 1.68
# fs/proc/base.c 1.78 -> 1.79
# arch/sh64/kernel/ptrace.c 1.1 -> 1.2
# kernel/sched.c 1.346 -> 1.347
# kernel/exit.c 1.152 -> 1.153
# arch/cris/arch-v10/kernel/ptrace.c 1.2 -> 1.3
# arch/sparc64/kernel/ptrace.c 1.21 -> 1.22
# arch/sparc/kernel/ptrace.c 1.17 -> 1.18
# kernel/ptrace.c 1.34 -> 1.35
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 04/09/08 [email protected] 1.1832.54.192
# [PATCH] cleanup ptrace stops and remove notify_parent
#
# This adds a new state TASK_TRACED that is used in place of TASK_STOPPED

# when a thread stops because it is ptraced.  Now ptrace operations are only
# permitted when the target is in TASK_TRACED state, not in TASK_STOPPED. 
# This means that if a process is stopped normally by a job control signal
# and then you PTRACE_ATTACH to it, you will have to send it a SIGCONT before
# you can do any ptrace operations on it.  (The SIGCONT will be reported to
# ptrace and then you can discard it instead of passing it through when you
# call PTRACE_CONT et al.)
# 
# If a traced child gets orphaned while in TASK_TRACED state, it morphs into
# TASK_STOPPED state.  This makes it again possible to resume or destroy the
# process with SIGCONT or SIGKILL.
# 
# All non-signal tracing stops should now be done via ptrace_notify.  I've
# updated the syscall tracing code in several architectures to do this
# instead of replicating the work by hand.  I also fixed several that were
# unnecessarily repeating some of the checks in ptrace_check_attach.  Calling
# ptrace_check_attach alone is sufficient, and the old checks repeated before
# are now incorrect, not just superfluous.
# 
# I've closed a race in ptrace_check_attach.  With this, we should have a
# robust guarantee that when ptrace starts operating, the task will be in
# TASK_TRACED state and won't come out of it.  This is because the only way
# to resume from TASK_TRACED is via ptrace operations, and only the one
# parent thread attached as the tracer can do those.
# 
# This patch also cleans up the do_notify_parent and do_notify_parent_cldstop
# code so that the dead and stopped cases are completely disjoint.  The
# notify_parent function is gone.
# 
# Signed-off-by: Roland McGrath <[email protected]>
# Signed-off-by: Andrew Morton <[email protected]>
# Signed-off-by: Linus Torvalds <[email protected]>
# --------------------------------------------
#
diff -Nru a/arch/arm/kernel/ptrace.c b/arch/arm/kernel/ptrace.c
--- a/arch/arm/kernel/ptrace.c	Tue Oct 12 10:30:23 2004
+++ b/arch/arm/kernel/ptrace.c	Tue Oct 12 10:30:23 2004
@@ -792,11 +792,8 @@

/* the 0x80 provides a way for the tracing parent to distinguish
between a syscall stop and SIGTRAP delivery */
- current->exit_code = SIGTRAP | ((current->ptrace & PT_TRACESYSGOOD)
- ? 0x80 : 0);
- current->state = TASK_STOPPED;
- notify_parent(current, SIGCHLD);
- schedule();
+ ptrace_notify(SIGTRAP | ((current->ptrace & PT_TRACESYSGOOD)
+ ? 0x80 : 0));
/*
* this isn't the same as continuing with a signal, but it will do
* for normal use. strace only continues with a signal if the

arch/arm26/kernel/ptrace.c +2 -5
diff -Nru a/arch/arm26/kernel/ptrace.c b/arch/arm26/kernel/ptrace.c
@@ -729,11 +729,8 @@
 
 	/* the 0x80 provides a way for the tracing parent to distinguish
 	   between a syscall stop and SIGTRAP delivery */
-	current->exit_code = SIGTRAP | ((current->ptrace & PT_TRACESYSGOOD)
-					? 0x80 : 0);
-	current->state = TASK_STOPPED;
-	notify_parent(current, SIGCHLD);
-	schedule();
+	ptrace_notify(SIGTRAP | ((current->ptrace & PT_TRACESYSGOOD)
+				 ? 0x80 : 0));
 	/*
 	 * this isn't the same as continuing with a signal, but it will do
 	 * for normal use.  strace only continues with a signal if the
arch/cris/arch-v10/kernel/ptrace.c +2 -11
diff -Nru a/arch/cris/arch-v10/kernel/ptrace.c b/arch/cris/arch-v10/kernel/ptrace.c
@@ -85,17 +85,8 @@
 		goto out_tsk;
 	}
 	
-	ret = -ESRCH;
-	
-	if (!(child->ptrace & PT_PTRACED))
-		goto out_tsk;
-	
-	if (child->state != TASK_STOPPED) {
-		if (request != PTRACE_KILL)
-			goto out_tsk;
-	}
-	
-	if (child->parent != current)
+	ret = ptrace_check_attach(child, request == PTRACE_KILL);
+	if (ret < 0)
 		goto out_tsk;
 
 	switch (request) {
arch/h8300/kernel/ptrace.c +2 -11
diff -Nru a/arch/h8300/kernel/ptrace.c b/arch/h8300/kernel/ptrace.c
@@ -89,13 +89,6 @@
 		ret = ptrace_attach(child);
 		goto out_tsk;
 	}
-	ret = -ESRCH;
-	if (!(child->ptrace & PT_PTRACED))
-		goto out_tsk;
-	if (child->state != TASK_STOPPED) {
-		if (request != PTRACE_KILL)
-			goto out_tsk;
-	}
 	ret = ptrace_check_attach(child, request == PTRACE_KILL);
 	if (ret < 0)
 		goto out_tsk;
@@ -270,10 +263,8 @@
 		return;
 	if (!(current->ptrace & PT_PTRACED))
 		return;
-	current->exit_code = SIGTRAP;
-	current->state = TASK_STOPPED;
-	notify_parent(current, SIGCHLD);
-	schedule();
+	ptrace_notify(SIGTRAP | ((current->ptrace & PT_TRACESYSGOOD)
+				 ? 0x80 : 0));
 	/*
 	 * this isn't the same as continuing with a signal, but it will do
 	 * for normal use.  strace only continues with a signal if the
arch/m68k/kernel/ptrace.c +2 -5
diff -Nru a/arch/m68k/kernel/ptrace.c b/arch/m68k/kernel/ptrace.c
@@ -379,11 +379,8 @@
 	if (!current->thread.work.delayed_trace &&
 	    !current->thread.work.syscall_trace)
 		return;
-	current->exit_code = SIGTRAP | ((current->ptrace & PT_TRACESYSGOOD)
-					? 0x80 : 0);
-	current->state = TASK_STOPPED;
-	notify_parent(current, SIGCHLD);
-	schedule();
+	ptrace_notify(SIGTRAP | ((current->ptrace & PT_TRACESYSGOOD)
+				 ? 0x80 : 0));
 	/*
 	 * this isn't the same as continuing with a signal, but it will do
 	 * for normal use.  strace only continues with a signal if the
arch/m68knommu/kernel/ptrace.c +2 -11
diff -Nru a/arch/m68knommu/kernel/ptrace.c b/arch/m68knommu/kernel/ptrace.c
@@ -133,13 +133,6 @@
 		ret = ptrace_attach(child);
 		goto out_tsk;
 	}
-	ret = -ESRCH;
-	if (!(child->ptrace & PT_PTRACED))
-		goto out_tsk;
-	if (child->state != TASK_STOPPED) {
-		if (request != PTRACE_KILL)
-			goto out_tsk;
-	}
 	ret = ptrace_check_attach(child, request == PTRACE_KILL);
 	if (ret < 0)
 		goto out_tsk;
@@ -376,10 +369,8 @@
 		return;
 	if (!(current->ptrace & PT_PTRACED))
 		return;
-	current->exit_code = SIGTRAP;
-	current->state = TASK_STOPPED;
-	notify_parent(current, SIGCHLD);
-	schedule();
+	ptrace_notify(SIGTRAP | ((current->ptrace & PT_TRACESYSGOOD)
+				 ? 0x80 : 0));
 	/*
 	 * this isn't the same as continuing with a signal, but it will do
 	 * for normal use.  strace only continues with a signal if the
arch/parisc/kernel/ptrace.c +2 -5
diff -Nru a/arch/parisc/kernel/ptrace.c b/arch/parisc/kernel/ptrace.c
@@ -404,11 +404,8 @@
 		return;
 	if (!(current->ptrace & PT_PTRACED))
 		return;
-	current->exit_code = SIGTRAP | ((current->ptrace & PT_TRACESYSGOOD)
-					? 0x80 : 0);
-	current->state = TASK_STOPPED;
-	notify_parent(current, SIGCHLD);
-	schedule();
+	ptrace_notify(SIGTRAP | ((current->ptrace & PT_TRACESYSGOOD)
+				 ? 0x80 : 0));
 	/*
 	 * this isn't the same as continuing with a signal, but it will do
 	 * for normal use.  strace only continues with a signal if the
arch/sh64/kernel/ptrace.c +2 -5
diff -Nru a/arch/sh64/kernel/ptrace.c b/arch/sh64/kernel/ptrace.c
@@ -311,11 +311,8 @@
 	if (!(tsk->ptrace & PT_PTRACED))
 		return;
 
-	tsk->exit_code = SIGTRAP | ((current->ptrace & PT_TRACESYSGOOD)
-				    ? 0x80 : 0);
-	tsk->state = TASK_STOPPED;
-	notify_parent(tsk, SIGCHLD);
-	schedule();
+	ptrace_notify(SIGTRAP | ((current->ptrace & PT_TRACESYSGOOD)
+				 ? 0x80 : 0));
 	/*
 	 * this isn't the same as continuing with a signal, but it will do
 	 * for normal use.  strace only continues with a signal if the
arch/sparc/kernel/ptrace.c +2 -5
diff -Nru a/arch/sparc/kernel/ptrace.c b/arch/sparc/kernel/ptrace.c
@@ -614,12 +614,9 @@
 		return;
 	if (!(current->ptrace & PT_PTRACED))
 		return;
-	current->exit_code = SIGTRAP | ((current->ptrace & PT_TRACESYSGOOD)
-					? 0x80 : 0);
-	current->state = TASK_STOPPED;
 	current->thread.flags ^= MAGIC_CONSTANT;
-	notify_parent(current, SIGCHLD);
-	schedule();
+	ptrace_notify(SIGTRAP | ((current->ptrace & PT_TRACESYSGOOD)
+				 ? 0x80 : 0));
 	/*
 	 * this isn't the same as continuing with a signal, but it will do
 	 * for normal use.  strace only continues with a signal if the
arch/sparc64/kernel/ptrace.c +2 -5
diff -Nru a/arch/sparc64/kernel/ptrace.c b/arch/sparc64/kernel/ptrace.c
@@ -627,11 +627,8 @@
 		return;
 	if (!(current->ptrace & PT_PTRACED))
 		return;
-	current->exit_code = SIGTRAP | ((current->ptrace & PT_TRACESYSGOOD)
-					? 0x80 : 0);
-	current->state = TASK_STOPPED;
-	notify_parent(current, SIGCHLD);
-	schedule();
+	ptrace_notify(SIGTRAP | ((current->ptrace & PT_TRACESYSGOOD)
+				 ? 0x80 : 0));
 
 	/*
 	 * this isn't the same as continuing with a signal, but it will do
arch/v850/kernel/ptrace.c +4 -13
diff -Nru a/arch/v850/kernel/ptrace.c b/arch/v850/kernel/ptrace.c
@@ -147,14 +147,8 @@
 		rval = ptrace_attach(child);
 		goto out_tsk;
 	}
-	rval = -ESRCH;
-	if (!(child->ptrace & PT_PTRACED))
-		goto out_tsk;
-	if (child->state != TASK_STOPPED) {
-		if (request != PTRACE_KILL)
-			goto out_tsk;
-	}
-	if (child->parent != current)
+	ret = ptrace_check_attach(child, request == PTRACE_KILL);
+	if (ret < 0)
 		goto out_tsk;
 
 	switch (request) {
@@ -269,11 +263,8 @@
 		return;
 	/* The 0x80 provides a way for the tracing parent to distinguish
 	   between a syscall stop and SIGTRAP delivery */
-	current->exit_code = SIGTRAP | ((current->ptrace & PT_TRACESYSGOOD)
-					? 0x80 : 0);
-	current->state = TASK_STOPPED;
-	notify_parent(current, SIGCHLD);
-	schedule();
+	ptrace_notify(SIGTRAP | ((current->ptrace & PT_TRACESYSGOOD)
+				 ? 0x80 : 0));
 	/*
 	 * this isn't the same as continuing with a signal, but it will do
 	 * for normal use.  strace only continues with a signal if the
fs/proc/array.c +5 -3
diff -Nru a/fs/proc/array.c b/fs/proc/array.c
@@ -130,8 +130,9 @@
 	"S (sleeping)",		/*  1 */
 	"D (disk sleep)",	/*  2 */
 	"T (stopped)",		/*  4 */
-	"Z (zombie)",		/*  8 */
-	"X (dead)"		/* 16 */
+	"T (tracing stop)",	/*  8 */
+	"Z (zombie)",		/* 16 */
+	"X (dead)"		/* 32 */
 };
 
 static inline const char * get_task_state(struct task_struct *tsk)
@@ -141,7 +142,8 @@
 					   TASK_UNINTERRUPTIBLE |
 					   TASK_ZOMBIE |
 					   TASK_DEAD |
-					   TASK_STOPPED);
+					   TASK_STOPPED |
+					   TASK_TRACED);
 	const char **p = &task_state_array[0];
 
 	while (state) {
fs/proc/base.c +2 -1
diff -Nru a/fs/proc/base.c b/fs/proc/base.c
@@ -287,7 +287,8 @@
 #define MAY_PTRACE(task) \
 	(task == current || \
 	(task->parent == current && \
-	(task->ptrace & PT_PTRACED) &&  task->state == TASK_STOPPED && \
+	(task->ptrace & PT_PTRACED) && \
+	 (task->state == TASK_STOPPED || task->state == TASK_TRACED) && \
 	 security_ptrace(current,task) == 0))
 
 static int may_ptrace_attach(struct task_struct *task)
include/linux/sched.h +3 -3
diff -Nru a/include/linux/sched.h b/include/linux/sched.h
@@ -106,8 +106,9 @@
 #define TASK_INTERRUPTIBLE	1
 #define TASK_UNINTERRUPTIBLE	2
 #define TASK_STOPPED		4
-#define TASK_ZOMBIE		8
-#define TASK_DEAD		16
+#define TASK_TRACED		8
+#define TASK_ZOMBIE		16
+#define TASK_DEAD		32
 
 #define __set_task_state(tsk, state_value)		\
 	do { (tsk)->state = (state_value); } while (0)
@@ -738,7 +739,6 @@
 extern int kill_pg_info(int, struct siginfo *, pid_t);
 extern int kill_sl_info(int, struct siginfo *, pid_t);
 extern int kill_proc_info(int, struct siginfo *, pid_t);
-extern void notify_parent(struct task_struct *, int);
 extern void do_notify_parent(struct task_struct *, int);
 extern void force_sig(int, struct task_struct *);
 extern void force_sig_specific(int, struct task_struct *);
kernel/exit.c +13 -1
diff -Nru a/kernel/exit.c b/kernel/exit.c
@@ -555,6 +555,14 @@
 		if (p->state == TASK_ZOMBIE && p->exit_signal != -1 &&
 		    thread_group_empty(p))
 			do_notify_parent(p, p->exit_signal);
+		else if (p->state == TASK_TRACED) {
+			/*
+			 * If it was at a trace stop, turn it into
+			 * a normal stop since it's no longer being
+			 * traced.
+			 */
+			p->state = TASK_STOPPED;
+		}
 	}
 
 	/*
@@ -1164,7 +1172,7 @@
 	 * race with the TASK_ZOMBIE case.
 	 */
 	exit_code = xchg(&p->exit_code, 0);
-	if (unlikely(p->state > TASK_STOPPED)) {
+	if (unlikely(p->state >= TASK_ZOMBIE)) {
 		/*
 		 * The task resumed and then died.  Let the next iteration
 		 * catch it in TASK_ZOMBIE.  Note that exit_code might
@@ -1245,6 +1253,10 @@
 			flag = 1;
 
 			switch (p->state) {
+			case TASK_TRACED:
+				if (!(p->ptrace & PT_PTRACED))
+					continue;
+				/*FALLTHROUGH*/
 			case TASK_STOPPED:
 				if (!(options & WUNTRACED) &&
 				    !(p->ptrace & PT_PTRACED))
kernel/power/process.c +3 -1
diff -Nru a/kernel/power/process.c b/kernel/power/process.c
@@ -25,7 +25,8 @@
 	    (p->flags & PF_NOFREEZE) ||
 	    (p->state == TASK_ZOMBIE) ||
 	    (p->state == TASK_DEAD) ||
-	    (p->state == TASK_STOPPED))
+	    (p->state == TASK_STOPPED) ||
+	    (p->state == TASK_TRACED))
 		return 0;
 	return 1;
 }
@@ -70,6 +71,7 @@
 			if (!freezeable(p))
 				continue;
 			if ((p->flags & PF_FROZEN) ||
+			    (p->state == TASK_TRACED) ||
 			    (p->state == TASK_STOPPED))
 				continue;
 
kernel/ptrace.c +26 -32

91 lines not on this page · raw message

kernel/sched.c +2 -2
diff -Nru a/kernel/sched.c b/kernel/sched.c
@@ -1258,7 +1258,7 @@
 
 int fastcall wake_up_process(task_t * p)
 {
-	return try_to_wake_up(p, TASK_STOPPED |
+	return try_to_wake_up(p, TASK_STOPPED | TASK_TRACED |
 		       		 TASK_INTERRUPTIBLE | TASK_UNINTERRUPTIBLE, 0);
 }
 
@@ -3679,7 +3679,7 @@
 	task_t *relative;
 	unsigned state;
 	unsigned long free = 0;
-	static const char *stat_nam[] = { "R", "S", "D", "T", "Z", "W" };
+	static const char *stat_nam[] = { "R", "S", "D", "T", "t", "Z", "X" };
 
 	printk("%-13.13s ", p->comm);
 	state = p->state ? __ffs(p->state) + 1 : 0;
kernel/signal.c +120 -97

359 lines not on this page · raw message

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <signal.h>
#include <sys/ptrace.h>
#include <sys/types.h>
#include <sys/wait.h>

int main(int argc, char *argv[])

{
	int child,rc,status;

	child = fork();
	if (0 == child) {
		fprintf(stderr,"[child] ptrace me ...\n");
		ptrace(PTRACE_TRACEME);
		fprintf(stderr,"[child] exec sleep 10 ...\n");
		execlp("sleep", "sleep", "10", NULL);
		perror("execlp");
		exit(1);
	}

	sleep(1);
	fprintf(stderr,"kill %d,STOP ...\n",child);
	kill(child,SIGSTOP);
	fprintf(stderr,"waitpid %d...\n",child);
	rc = waitpid(child,&status,WUNTRACED);
	fprintf(stderr,"%s: rc=%d status=%s%s%s termsig=%d\n",__FUNCTION__,rc,
		WIFEXITED(status)   ? "exit"    : "",
		WIFSIGNALED(status) ? "signal"  : "",
		WIFSTOPPED(status)  ? "stopped" : "",
		WTERMSIG(status));

	sleep(1);
	fprintf(stderr,"kill %d,KILL ...\n",child);
	kill(child,SIGKILL);
	fprintf(stderr,"waitpid %d...\n",child);
	rc = waitpid(child,&status,WUNTRACED);
	fprintf(stderr,"%s: rc=%d status=%s%s%s termsig=%d\n",__FUNCTION__,rc,
		WIFEXITED(status)   ? "exit"    : "",
		WIFSIGNALED(status) ? "signal"  : "",
		WIFSTOPPED(status)  ? "stopped" : "",
		WTERMSIG(status));

	exit(0);
}
#4 lore raw
Quoted 11 lines · Gerd Knorr
Quoted 8 lines
Quoted 5 lines

Yes, I see that as well, it actually *is* that ptrace change added in patch-2.6.9-rc1-bk16.

IMHO it is a bug, I've reported it to lkml a
few days ago, no response yet.

Oh well, did I lost it or you did not CC the UML mailing list? And in the 2nd case, why?

I didn't cc the uml list as it isn't a uml bug, its just that uml triggeres it.

Hmm - trying to fix that or just reverting the patch inside the SKAS patch (or as attached patch) would have been a possible workaround.

Quoted 17 lines
Quoted 1 line

I'm downloading the patches from BitKeeper.

I'll attach the offending one for reference, also a short test app showing the buggy behavior.

Quoted 5 lines
Quoted 2 lines

Problem is that you can't kill -9 processes any more which are ptraced _and_ stopped at the same time.

Sorry, tried kill -CONT? I'm almost sure it works (tried by both Henrik Normstrod and me, not in this case).

IMHO it is a clear bug in the (host) kernel, so I didn't attempt yet to workaround that by playing tricks in the UML kernel. I can't see the bug when reading the patch through, probably the separation of stopped and traced process states triggeres some odd corner case somewhere else in the kernel ...

Quoted 3 lines

If you send a SIGKILL to the process being stopped & ptraced *nothing* happens. Neither the process is killed nor the ptracing parent is notified. That can't be correct.

Can you try using SIGCONT, please? Even the patch changelog clearly says that you must kill -CONT before kill -KILL (actually, a kill -CONT may make the process notice the SIGKILL), and that behaviour can be reproduced, I think, on every kernel version. There has been a thread on this (t-mode processes) on uml-devel. Quite frankly, I do not know the question myself - but people seem to agree that this is a correct behaviour.

That said, I'll give a look to the patch. Have you CC'ed the patch author on your report?

Signature · 13 lines
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
#5 lore raw
Quoted 2 lines · BlaisorBlade

Can you try using SIGCONT, please? Even the patch changelog clearly says that you must kill -CONT before kill -KILL

That looks like a race condition. If the process manages to enter the same state again before you get to KILL it, even this "advanced" kill is lost.

Quoted 1 line

(actually, a kill -CONT may make the process notice the SIGKILL),

That's what works so far, yes. I'm actually no quite certain what this thread is about: it sounds as if this was a new problem, but we've required CONT with KILL in some cases already for a long time.

Quoted 2 lines

Quite frankly, I do not know the question myself - but people seem to agree that this is a correct behaviour.

The odd thing is that a process that was ptraced but whose ptracer is long dead *still* needs the CONT. That doesn't look right to me.

- Werner

Signature · 14 lines
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         [email protected] /
/_http://www.almesberger.net/____________________________________________/


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
#6 lore raw
Quoted 8 lines · Werner Almesberger
Quoted 2 lines · BlaisorBlade

Can you try using SIGCONT, please? Even the patch changelog clearly says that you must kill -CONT before kill -KILL

That looks like a race condition.

If the process manages to enter
the same state again before you get to KILL it,

Why? This does not make sense, IMHO - after a SIGCONT it should keep running until something *requests* it stopping - or not? I'm not finding a clue in the sources... it's quite difficult.

Quoted 10 lines

even this "advanced"
kill is lost.

Quoted 1 line

(actually, a kill -CONT may make the process notice the SIGKILL),

That's what works so far, yes. I'm actually no quite certain what this thread is about: it sounds as if this was a new problem, but we've required CONT with KILL in some cases already for a long time.

Quoted 5 lines
Quoted 2 lines

Quite frankly, I do not know the question myself - but people seem to agree that this is a correct behaviour.

The odd thing is that a process that was ptraced but whose ptracer is long dead *still* needs the CONT. That doesn't look right to me.

I remember that on Slackware, when doing "init 1" it sends even kill -CONT to all processes, so either they think it's correct or they want to workaround an issue existing for lots of kernel releases.

Bye

Signature · 13 lines
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
#7 lore raw
Quoted 2 lines · BlaisorBlade

Why? This does not make sense, IMHO - after a SIGCONT it should keep running until something *requests* it stopping - or not?

Well, depends on what constellation we have: if the ptracer is already dead, this should work. If the ptracer is still alive, we may return to the same state quickly (e.g. if both sides aren't interactive anyway). Of course, one could argue that, in the latter case, allowing the ptracer to override SIGKILL is a feature (in any case, the ptracer should be able to keep the dying process for examination).

Part of the problem is of course that there's no clear and comprehensive definition of what ptrace should do. It would be nice if the POSIX folks would tackle this :)

Quoted 1 line

I'm not finding a clue in the sources... it's quite difficult.

Yeah, when I spotted it in 2.5.44, I didn't have the stomach to actually fix it either, and just reported it, hoping that some other brave soul would step up. That was about 1.5 years ago :-(

Quoted 3 lines

I remember that on Slackware, when doing "init 1" it sends even kill -CONT to all processes, so either they think it's correct or they want to workaround an issue existing for lots of kernel releases.

My bet would be on the workaround :-)

- Werner

Signature · 14 lines
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         [email protected] /
/_http://www.almesberger.net/____________________________________________/


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
#8 lore raw
Quoted 6 lines · Werner Almesberger
Quoted 2 lines · BlaisorBlade

Why? This does not make sense, IMHO - after a SIGCONT it should keep running until something *requests* it stopping - or not?

Well, depends on what constellation we have: if the ptracer is already dead, this should work.

It's alive.

Quoted 2 lines

If the ptracer is still alive, we may return to the same state quickly (e.g. if both sides aren't interactive anyway).

Or if the uml kernel scheduler decides the task should go sleep again and sends a SIGSTOP for that ...

Quoted 3 lines

Of course, one could argue that, in the latter case, allowing the ptracer to override SIGKILL is a feature (in any case, the ptracer should be able to keep the dying process for examination).

Yep, but if you want to allow the ptracer override SIGKILL you should at least notify it about the SIGKILL, which doesn't happen either in 2.6.9-rc2+ ...

Quoted 5 lines
Quoted 3 lines

I remember that on Slackware, when doing "init 1" it sends even kill -CONT to all processes, so either they think it's correct or they want to workaround an issue existing for lots of kernel releases.

My bet would be on the workaround :-)

Oh well. As far I can see there is no simple, race-free workaround. Guess we really have to find that damn bug ...

Gerd

Signature · 12 lines
return -ENOSIG;


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
#9 lore raw
In reply to Werner Almesberger

-----BEGIN PGP SIGNED MESSAGE-----

Quoted 3 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Werner" == Werner Almesberger <[email protected]> writes:

Quite frankly, I do not know the question myself - but people seem to agree that this is a correct behaviour.

Werner> The odd thing is that a process that was ptraced but whose Werner> ptracer is long dead *still* needs the CONT. That doesn't Werner> look right to me.

Definitely is WRONG from my point of view.
If the tracer goes away, then -9 should work. Principle of least surprise.

I tend to believe that -9 should also override being traced as well.
I can sort of understand that someone might think they can trace through a -9, but since that signal is never delivered to the process, nor can it be ignored, I can't understand why it matters.
Sure, let the ptrace'r know that the process got a -9.

- --

]     "Elmo went to the wrong fundraiser" - The Simpson         |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email protected]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[

] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQXb6sYqHRg3pndX9AQEC/AQAujSBVJh0Qel5I6fJkHTS6YWrCWk7XtQf i8tVsxrxmyE6baWvhfCm/QRZMozxxdQhRA9dIdPEa9/DMewnshAkMG+Ltg8n9q9p QJuKz/6XqbK7locR/48pp96X3y1/4+xdlvb5J276jOwG8wKkYdqlmqvuKD10pn8e aRPPq20vmBM=
=/4b6
-----END PGP SIGNATURE-----

-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

#10 lore raw
Quoted 5 lines

I tend to believe that -9 should also override being traced as well.
I can sort of understand that someone might think they can trace through a -9, but since that signal is never delivered to the process, nor can it be ignored, I can't understand why it matters.
Sure, let the ptrace'r know that the process got a -9.

Ok, found a way around that. You can send a SIGKILL, then call PTRACE_CONT, and now the process will see the SIGKILL and die.

The patch below fixes it for me for the skas case, not sure about tt through.

Gerd

arch/um/include/os.h +1 -1
Index: linux-uml-2.6.9/arch/um/include/os.h
===================================================================
@@ -156,7 +156,7 @@ extern int os_lock_file(int fd, int excl
 extern unsigned long os_process_pc(int pid);
 extern int os_process_parent(int pid);
 extern void os_stop_process(int pid);
-extern void os_kill_process(int pid, int reap_child);
+extern void os_kill_process(int pid, int reap_child, int trace_cont);
 extern void os_usr1_process(int pid);
 extern int os_getpid(void);
 
arch/um/os-Linux/process.c +5 -3
Index: linux-uml-2.6.9/arch/um/os-Linux/process.c
===================================================================
@@ -10,6 +10,7 @@
 #include <linux/unistd.h>
 #include <sys/mman.h>
 #include <sys/wait.h>
+#include <sys/ptrace.h>
 #include "os.h"
 #include "user.h"
 #include "user_util.h"
@@ -86,12 +87,13 @@ void os_stop_process(int pid)
 	kill(pid, SIGSTOP);
 }
 
-void os_kill_process(int pid, int reap_child)
+void os_kill_process(int pid, int reap_child, int trace_cont)
 {
 	kill(pid, SIGKILL);
-	if(reap_child)
+	if (trace_cont)
+		ptrace(PTRACE_CONT, pid, NULL, NULL);
+	if (reap_child)
 		CATCH_EINTR(waitpid(pid, NULL, 0));
-		
 }
 
 void os_usr1_process(int pid)
arch/um/drivers/port_kern.c +3 -3
Index: linux-uml-2.6.9/arch/um/drivers/port_kern.c
===================================================================
@@ -112,7 +112,7 @@ static int port_accept(struct port_list 
  out_close:
 	os_close_file(fd);
 	if(pid != -1) 
-		os_kill_process(pid, 1);
+		os_kill_process(pid, 1, 0);
  out:
 	return(ret);
 } 
@@ -262,9 +262,9 @@ void port_remove_dev(void *d)
 	struct port_dev *dev = d;
 
 	if(dev->helper_pid != -1)
-		os_kill_process(dev->helper_pid, 0);
+		os_kill_process(dev->helper_pid, 0, 0);
 	if(dev->telnetd_pid != -1)
-		os_kill_process(dev->telnetd_pid, 1);
+		os_kill_process(dev->telnetd_pid, 1, 0);
 	dev->helper_pid = -1;
 	dev->telnetd_pid = -1;
 }
arch/um/drivers/ubd_kern.c +1 -1
Index: linux-uml-2.6.9/arch/um/drivers/ubd_kern.c
===================================================================
@@ -470,7 +470,7 @@ static int io_pid = -1;
 void kill_io_thread(void)
 {
 	if(io_pid != -1) 
-		os_kill_process(io_pid, 1);
+		os_kill_process(io_pid, 1, 0);
 }
 
 __uml_exitcall(kill_io_thread);
arch/um/drivers/line.c +1 -1
Index: linux-uml-2.6.9/arch/um/drivers/line.c
===================================================================
@@ -638,7 +638,7 @@ static void winch_cleanup(void)
 			os_close_file(winch->fd);
 		}
 		if(winch->pid != -1) 
-			os_kill_process(winch->pid, 1);
+			os_kill_process(winch->pid, 1, 0);
 	}
 }
 __uml_exitcall(winch_cleanup);
arch/um/kernel/skas/process.c +1 -1
Index: linux-uml-2.6.9/arch/um/kernel/skas/process.c
===================================================================
@@ -400,7 +400,7 @@ void switch_mm_skas(int mm_fd)
 void kill_off_processes_skas(void)
 {
 #warning need to loop over userspace_pids in kill_off_processes_skas
-	os_kill_process(userspace_pid[0], 1);
+	os_kill_process(userspace_pid[0], 1, 1);
 }
 
 void init_registers(int pid)
arch/um/kernel/process.c +1 -1
Index: linux-uml-2.6.9/arch/um/kernel/process.c
===================================================================
@@ -141,7 +141,7 @@ static int ptrace_child(void *arg)
 
 	if(ptrace(PTRACE_TRACEME, 0, 0, 0) < 0){
 		perror("ptrace");
-		os_kill_process(pid, 0);
+		os_kill_process(pid, 0, 0);
 	}
 	os_stop_process(pid);
 	_exit(os_getpid() == pid);
arch/um/kernel/helper.c +2 -2
Index: linux-uml-2.6.9/arch/um/kernel/helper.c
===================================================================
@@ -45,7 +45,7 @@ static int helper_child(void *arg)
 	errval = errno;
 	printk("execvp of '%s' failed - errno = %d\n", argv[0], errno);
 	os_write_file(data->fd, &errval, sizeof(errval));
-	os_kill_process(os_getpid(), 0);
+	os_kill_process(os_getpid(), 0, 0);
 	return(0);
 }
 
@@ -106,7 +106,7 @@ int run_helper(void (*pre_exec)(void *),
 	return(pid);
 
  out_kill:
-	os_kill_process(pid, 1);
+	os_kill_process(pid, 1, 0);
  out_close:
 	os_close_file(fds[0]);
 	os_close_file(fds[1]);
arch/um/kernel/tt/process_kern.c +5 -5
Index: linux-uml-2.6.9/arch/um/kernel/tt/process_kern.c
===================================================================
@@ -66,7 +66,7 @@ void *switch_to_tt(void *prev, void *nex
 
 	reading = 1;
 	if((from->state == TASK_ZOMBIE) || (from->state == TASK_DEAD))
-		os_kill_process(os_getpid(), 0);
+		os_kill_process(os_getpid(), 0, 0);
 
 	err = os_read_file(from->thread.mode.tt.switch_pipe[0], &c, sizeof(c));
 	if(err != sizeof(c))
@@ -82,7 +82,7 @@ void *switch_to_tt(void *prev, void *nex
 	prev_sched = current->thread.prev_sched;
 	if((prev_sched->state == TASK_ZOMBIE) ||
 	   (prev_sched->state == TASK_DEAD))
-		os_kill_process(prev_sched->thread.mode.tt.extern_pid, 1);
+		os_kill_process(prev_sched->thread.mode.tt.extern_pid, 1, 1);
 
 	/* This works around a nasty race with 'jail'.  If we are switching
 	 * between two threads of a threaded app and the incoming process 
@@ -119,7 +119,7 @@ void release_thread_tt(struct task_struc
 	int pid = task->thread.mode.tt.extern_pid;
 
 	if(os_getpid() != pid)
-		os_kill_process(pid, 0);
+		os_kill_process(pid, 0, 0);
 }
 
 void exit_thread_tt(void)
@@ -331,10 +331,10 @@ void kill_off_processes_tt(void)
 	me = os_getpid();
         for_each_process(p){
 		if(p->thread.mode.tt.extern_pid != me) 
-			os_kill_process(p->thread.mode.tt.extern_pid, 0);
+			os_kill_process(p->thread.mode.tt.extern_pid, 0, 0);
 	}
 	if(init_task.thread.mode.tt.extern_pid != me) 
-		os_kill_process(init_task.thread.mode.tt.extern_pid, 0);
+		os_kill_process(init_task.thread.mode.tt.extern_pid, 0, 0);
 }
 
 void initial_thread_cb_tt(void (*proc)(void *), void *arg)
arch/um/drivers/xterm.c +2 -2
Index: linux-uml-2.6.9/arch/um/drivers/xterm.c
===================================================================
@@ -168,10 +168,10 @@ void xterm_close(int fd, void *d)
 	struct xterm_chan *data = d;
 	
 	if(data->pid != -1) 
-		os_kill_process(data->pid, 1);
+		os_kill_process(data->pid, 1, 0);
 	data->pid = -1;
 	if(data->helper_pid != -1) 
-		os_kill_process(data->helper_pid, 0);
+		os_kill_process(data->helper_pid, 0, 0);
 	data->helper_pid = -1;
 	os_close_file(fd);
 }
arch/um/kernel/sigio_user.c +3 -3
Index: linux-uml-2.6.9/arch/um/kernel/sigio_user.c
===================================================================
@@ -259,7 +259,7 @@ static void update_thread(void)
  fail:
 	sigio_lock();
 	if(write_sigio_pid != -1) 
-		os_kill_process(write_sigio_pid, 1);
+		os_kill_process(write_sigio_pid, 1, 0);
 	write_sigio_pid = -1;
 	os_close_file(sigio_private[0]);
 	os_close_file(sigio_private[1]);
@@ -386,7 +386,7 @@ void write_sigio_workaround(void)
 	return;
 
  out_kill:
-	os_kill_process(write_sigio_pid, 1);
+	os_kill_process(write_sigio_pid, 1, 0);
 	write_sigio_pid = -1;
  out_close2:
 	os_close_file(sigio_private[0]);
@@ -419,7 +419,7 @@ int read_sigio_fd(int fd)
 static void sigio_cleanup(void)
 {
 	if(write_sigio_pid != -1)
-		os_kill_process(write_sigio_pid, 1);
+		os_kill_process(write_sigio_pid, 1, 0);
 }
 
 __uml_exitcall(sigio_cleanup);

-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

#11 lore raw
In reply to BlaisorBlade
Quoted 6 lines · BlaisorBlade

Can you try using SIGCONT, please? Even the patch changelog clearly says that you must kill -CONT before kill -KILL (actually, a kill -CONT may make the process notice the SIGKILL), and that behaviour can be reproduced, I think, on every kernel version. There has been a thread on this (t-mode processes) on uml-devel. Quite frankly, I do not know the question myself - but people seem to agree that this is a correct behaviour.

The t-mode thread is about stopped traced processes where the tracing parent have gone away (killed or whatever). There it can be argued if it is sane to delay the SIGKILL only because the process is stopped. It would be more natural to KILL the process in this specific case.

If the tracing parent is still alive the natural thing would be to save the signal as pending and notify the parent when the child is restarted. A SIGKILL to a traced process in my opinion should not kill the traced process without allowing the tracing parent to veto on the signal.

Regards
Henrik

-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

#12 lore raw
Quoted 4 lines · Henrik Nordstrom

If the tracing parent is still alive the natural thing would be to save the signal as pending and notify the parent when the child is restarted. A SIGKILL to a traced process in my opinion should not kill the traced process without allowing the tracing parent to veto on the signal.

Well, if you don't ptrace a process you can't catch/veto the SIGKILL as well, so why you should be able to do that while ptracing? Beside that neither the process itself is killed nor the ptracing parent is notified on SIGKILL.

When the process is _not_ ptraced the SIGKILL works just fine (unconditionally, no matter whenever the process is stopped or not). IMHO the behavior should be the same when the process is traced.

Gerd

Signature · 12 lines
return -ENOSIG;


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
#13 lore raw
Quoted 2 lines · Gerd Knorr

Well, if you don't ptrace a process you can't catch/veto the SIGKILL as well, so why you should be able to do that while ptracing?

You can't, but the tracer can.

Quoted 1 line

Beside that neither the process itself is killed nor the ptracing parent is notified on SIGKILL.

The tracing parent should get notified as soon as it tries to continue the child. If not there is a bug in my opinion.

Quoted 2 lines

When the process is _not_ ptraced the SIGKILL works just fine (unconditionally, no matter whenever the process is stopped or not).

Correct. The process is then under the normal UNIX conditions where SIGKILL is unconditional.

Quoted 1 line

IMHO the behavior should be the same when the process is traced.

Here I do not agree, but it is my opinion.

Regards
Henrik

-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

#14 lore raw
Quoted 5 lines
Quoted 2 lines

Beside that neither the process itself is killed nor the ptracing parent is notified on SIGKILL.

The tracing parent should get notified as soon as it tries to continue the child. If not there is a bug in my opinion.

Doesn't work as well. Send SIGKILL first, then SIGCONT, nothing happens.

Gerd

Signature · 12 lines
return -ENOSIG;


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
#15 lore raw
In reply to BlaisorBlade
Quoted 4 lines

Can you try using SIGCONT, please? Even the patch changelog clearly says that you must kill -CONT before kill -KILL (actually, a kill -CONT may make the process notice the SIGKILL), and that behaviour can be reproduced, I think, on every kernel version.

Sending the -CONT after -KILL doesn't work.
Other way around would be racy ...

Quoted 2 lines

That said, I'll give a look to the patch. Have you CC'ed the patch author on your report?

Yes.

Gerd

Signature · 12 lines
return -ENOSIG;


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel