Is PTRACE_SINGLEBLOCK buggy?
Hi Roland, hi everybody,
I have finished teaching my spring term so I am back working on utrace.
I am porting my stuff about virtualquare kmview on the new version of
kernels.
I ran into something that seems to be a bug on PTRACE_SINGLEBLOCK.
The source code here enclosed says OKAY on a standard 2.6.25.4,
while it generates a kernel panic on a 2.6.25.4 +
http://people.redhat.com/roland/utrace/2.6-current/linux-2.6-utrace.patch.
Is this a bug? (I think so, no combination of syscall parms should
ever generate kernel panics ;)
Is this a known bug? (e.g. because PTRACE_SINGLEBLOCK is already a WIP
with utrace and you are already working on it...)
ciao
renzo
---
#include stdio.h
#include signal.h
#include sys/wait.h
#include sys/ptrace.h
#include errno.h
static int child(void *arg)
{
if(ptrace(PTRACE_TRACEME, 0, 0, 0) 0){
perror(ptrace traceme);
}
kill(getpid(), SIGSTOP);
return 0;
}
int main()
{
int pid, status, rv;
static char stack[1024];
if((pid = clone(child, stack[1020], SIGCHLD, NULL)) 0){
perror(clone);
return 0;
}
if((pid = waitpid(pid, status, WUNTRACED)) 0){
perror(Waiting for stop);
return 0;
}
ptrace(33, pid, 0, 0); /* PTRACE_SINGLEBLOCK */
printf(OKAY\n);
return 0;
}
Re: Is PTRACE_SINGLEBLOCK buggy?
On Mon, 02 Jun 2008 11:09:56 +0200, Renzo Davoli wrote: Jan Kratochvil has just sent me an E-mail saying that it seems to be a kvm bug (or a bug caused by kvm). KVM bug details at https://bugzilla.redhat.com/show_bug.cgi?id=437028 . He is right: using qemu/kqemu instead of kvm it does not panic. Anyway I am puzzled. Using kvm the PTRACE_SINGLEBLOCK should have the same effect on 2.6.25.4 and 2.6.25.4+utrace. 2.6.25.4: ptrace_resume(kernel/ptrace.c)-user_enable_block_step 2.6.25.4+utrace: ptrace_common(kernel/ptrace.c) sets UTRACE_ACTION_BLOCKSTEP -utrace_quiescent(kernel/utrace.c) tests UTRACE_ACTION_BLOCKSTEP -user_enable_block_step I wonder where is the difference... Just FYI on 2.6.25 I still get the crash, host: kernel: kvm: 19661: cpu0 unhandled wrmsr: 0x1d9 data 2 kernel-2.6.25.3-18.fc9.x86_64 kvm-65-7.fc9.x86_64 guest: vanilla 2.6.25 x86_64 Pid: 1945, comm: block-step Not tainted 2.6.25-0.101.rc4.git3.fc8 #1 RIP: 0010:[8100ab79] [8100ab79] __switch_to+0x218/0x2bc (the version number is for a RPM-built vanilla kernel) (I did not find any ptrace patches in between 2.6.25 and 2.6.25.4.) Regards, Jan
ptrace testsuite: reparent-zombie* race
Hi Roland,
I get randomly a race
reparent-zombie: reparent-zombie.c:88: create_zombie: Assertion `fd !=
-1' failed.
Aborted
on kernel-2.6.25.3-18.fc9.x86_64.
I hope the attached patch is right (tested only for reparent-zombie.c as
reparent-zombie-clone.c is crashing the kernel).
Best Regards,
Jan
--- tests/reparent-zombie.c 2 May 2008 01:27:20 - 1.1
+++ tests/reparent-zombie.c 2 Jun 2008 12:40:01 -
@@ -78,15 +78,19 @@ create_zombie (void)
assert (WIFSTOPPED (status));
assert (WSTOPSIG (status) == SIGUSR1);
+ /* We must open the status file first as if CHILD would finish in between
+ TRACE_CONT and this OPEN we would fail with ENOSRCH as no zombie is left
+ as we have set the SIGCHLD handler to SIG_IGN (kernel reaps the died
+ children without creating any zombies. */
+ snprintf (buf, sizeof buf, /proc/%d/status, (int) child);
+ fd = open (buf, O_RDONLY);
+ assert (fd != -1);
+
errno = 0;
l = ptrace (PTRACE_CONT, child, 0l, 0l);
assert_perror (errno);
assert (l == 0);
- snprintf (buf, sizeof buf, /proc/%d/status, (int) child);
- fd = open (buf, O_RDONLY);
- assert (fd != -1);
-
do
{
sched_yield ();
@@ -173,6 +177,8 @@ main (void)
signal (SIGABRT, handler_fail);
signal (SIGALRM, handler_fail);
+ /* SIG_IGN as we want no zombies left - kernel reaps the died children
+ without creating any zombies. */
signal (SIGCHLD, SIG_IGN);
fd = create_zombie ();
--- tests/reparent-zombie-clone.c 2 May 2008 01:27:20 - 1.1
+++ tests/reparent-zombie-clone.c 2 Jun 2008 12:44:15 -
@@ -123,6 +123,14 @@ create_zombie (void)
assert (WIFSTOPPED (status));
assert (WSTOPSIG (status) == SIGSTOP);
+ /* We must open the status file first as if MSG would finish in between
+ TRACE_CONT and this OPEN we would fail with ENOSRCH as no zombie is left
+ as we have set the SIGCHLD handler to SIG_IGN (kernel reaps the died
+ children without creating any zombies. */
+ snprintf (buf, sizeof buf, /proc/%d/status, (int) msg);
+ fd = open (buf, O_RDONLY);
+ assert (fd != -1);
+
errno = 0;
l = ptrace (PTRACE_CONT, msg, 0l, 0l);
assert_perror (errno);
@@ -135,10 +143,6 @@ create_zombie (void)
child = msg;
- snprintf (buf, sizeof buf, /proc/%d/status, (int) child);
- fd = open (buf, O_RDONLY);
- assert (fd != -1);
-
do
{
sched_yield ();
@@ -225,6 +229,8 @@ main (void)
signal (SIGABRT, handler_fail);
signal (SIGALRM, handler_fail);
+ /* SIG_IGN as we want no zombies left - kernel reaps the died children
+ without creating any zombies. */
signal (SIGCHLD, SIG_IGN);
fd = create_zombie ();
