Re: [uml-devel] Kernel panic: check_ptrace : child exited with status 0x100

Re: [uml-devel] Kernel panic: check_ptrace : child exited with status 0x100

[bodo.stroesser]

caker@theshore.net said:
> Ok, so a new combination.  This is 2.4.27 + 2.4.26-um + all the incremental + Bodo's
> sysemu-panic patch.  It works fine on non-sysemu hosts, and on a host with the
> original version of sysemu.
> 
> I think the key here is that this host has the latest (v5) SKAS patch, whereas the
> 2.6.7 host kernel used the standard sysemu patch.

Please note, my knowledge about this only comes from reading the source code only.
Thus, if I'm wrong, tell me.

AFAICS, the behavior of the latest skas patches for 2.4 and 2.6 regarding sysemu
is *very* different. And I believe, the 2.6 is wrong!

Problem:
On both host versions a process will stop, if it is started with PTRACE_SYSEMU and
if it tries to execute a systemcall. But what happens with the traced systemcall
when it is resumed differs between the two host versions.
On host 2.4 the syscall will immediately return to user presenting the result that
had been written to the stack via ptrace(). This is done no matter if the process
is resumed with PTRACE_SYSEMU, PTRACE_SYSCALL, PTRACE_SINGLESTEP or PTRACE_CONT.
On host 2.6 the syscall will immediately return to user only if the process is
restarted with PTREACE_SYSEMU! In the other cases the syscall will be executed on
the host, the result from this will overwrite the result written via ptrace().
The check for host's sysemu-support done in UML differs between the sysemu-patches
for UML-2.4 and UML-2.6:
- In UML-2.4 "getpid()" is written as result (eax) of the systemcall, which fakes
  the syscall-result on a 2.4-host, but does nothing on a 2.6, where it again is
  overwritten by running the syscall on the host! Thus, a UML-2.4 will run on
  hosts with sysemu-support only, if it is a 2.4 host!
- In UML-2.6 "getpid()" is written to the number of the systemcall! But the result
  in eax is not written, it still contains the original syscall number. On a
  2.4-host this number is returned. In most cases this will let the further checks
  in UML succeed, but no guarantee...
  On a 2.6-host the systemcall with the faked number now will be processed on the
  host. In most cases the number should be invalid, thus the result is -ENOSYS,
  the checks in UML will succeed. But what happens, if the faked syscall number is
  a number known on the host ...
  Thus a UML-2.6 will run on all host versions (in most cases ...)

Solution:
- the host-patch for 2.6 should be modified. Before calling ptrace_notify()
  do_syscall_trace() should save the state of the PTRACE_SYSEMU (true/false) and
  should use that saved state as return value.
- check_sysemu() in UML-2.6 should be modified to write the result, not the sycall
  number. And it should do it in a portable way.

By the way: it is not enough to change the checks only. The 2.6-host's behavior
will cause problems as well, if a process in UML is singlestepped. And there will
be problems, if someone switches off sysemu while UML is running.

Bodo

> 
> ----
> Checking for the skas3 patch in the host...found
> Checking for /proc/mm...found
> Checking PROT_EXEC mmap in /tmp...OK
> Checking for /dev/anon on the host...Not available (open failed with errno 6)
> Linux version 2.4.27-linode35-3um (caker@host4.linode.com) (gcc version 3.2.2
> 20030222 (Red Hat Linux 3.2.2-5)) #1 Wed Oct 6 11:31:28 EDT 2004
> On node 0 totalpages: 16384
> zone(0): 16384 pages.
> zone(1): 0 pages.
> zone(2): 0 pages.
> Kernel command line: mem=64M fake_ide fakehd con=null con0=fd:0,fd:1 devfs=nomount
> root=/dev/ubda ubda=/linodes/luctourangeau/13588.fs
> ubdb=/linodes/luctourangeau/13586.fs eth0=tuntap,luctourangeau_0,fe:fd:46:55:10:64
> token_max=400000 token_refill=512
> fakehd : Changing ubd_gendisk.major_name to "hd".
> Calibrating delay loop... 3787.98 BogoMIPS
> Memory: 59436k available
> Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
> Inode cache hash table entries: 4096 (order: 3, 32768 bytes)
> Mount cache hash table entries: 512 (order: 0, 4096 bytes)
> Buffer cache hash table entries: 1024 (order: 0, 4096 bytes)
> Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
> Checking for host processor cmov support...Yes
> Checking for host processor xmm support...No
> Checking that ptrace can change system call numbers...OK
> Checking syscall emulation patch for ptrace...<0>Kernel panic: check_ptrace : child
> exited with status 0x100
> In idle task - not syncing
>  <6>SysRq : Show Regs
> 
> EIP: 0000:[<00000000>] CPU: 0 Not tainted EFLAGS: 00000000
>     Not tainted
> EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000
> ESI: 00000000 EDI: 00000000 EBP: 00000000 DS: 0000 ES: 0000
> Call Trace: [<80315778>] [<80317cb6>] [<800115f3>] [<801adc3a>] [<801992f5>]
>    [<8001e3fa>] [<80013cb4>] [<80193f0d>] [<8033efe0>] [<800075c5>] [<803178fa>]
>    [<8019d8a0>] [<80007b65>] [<800024b2>] [<8019d8a0>] [<80002459>] [<8019d8c5>]
>    [<8019d8a0>] [<80193fad>] [<8019d8a0>] [<80193f88>] [<8019d8a0>] [<8019d609>]
>    [<8019d8a0>] [<8019d07d>] [<802b0108>] [<802b0371>]
> 
> -Chris


-------------------------------------------------------
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Kernel panic: check_ptrace : child exited with status 0x100

[BlaisorBlade]

On Friday 08 October 2004 13:59, bodo.stroesser@fujitsu-siemens.com wrote:
> caker@theshore.net said:
> > Ok, so a new combination.  This is 2.4.27 + 2.4.26-um + all the
> > incremental + Bodo's sysemu-panic patch.  It works fine on non-sysemu
> > hosts, and on a host with the original version of sysemu.
> >
> > I think the key here is that this host has the latest (v5) SKAS patch,
> > whereas the 2.6.7 host kernel used the standard sysemu patch.

> Please note, my knowledge about this only comes from reading the source
> code only. Thus, if I'm wrong, tell me.
>
> AFAICS, the behavior of the latest skas patches for 2.4 and 2.6 regarding
> sysemu is *very* different. And I believe, the 2.6 is wrong!
I have some problems on 2.6 hosts with SYSEMU, too. So I've been trying to 
find what's the difference between 2.4 and 2.6 hosts.

> Problem:

> On both host versions a process will stop, if it is started with
> PTRACE_SYSEMU and if it tries to execute a systemcall. But what happens
> with the traced systemcall when it is resumed differs between the two host
> versions.

> On host 2.4 the syscall will immediately return to user presenting the
> result that had been written to the stack via ptrace(). This is done no
> matter if the process is resumed with PTRACE_SYSEMU, PTRACE_SYSCALL,
> PTRACE_SINGLESTEP or PTRACE_CONT.

> On host 2.6 the syscall will immediately 
> return to user only if the process is restarted with PTREACE_SYSEMU! In the
> other cases the syscall will be executed on the host, the result from this
> will overwrite the result written via ptrace().

In fact, my problem is that UML crashes only on 2.6 hosts when I disable the 
use of SYSEMU at runtime (possible IIRC on 2.6.9-rc2, by "echo 0 
> /proc/sysemu).

This happened even with the original SYSEMU patch, however, but I think 
LaurentVivier+roland host sysemu was correct for the problem you describe; so 
I'm not able to understand which is the problem.

That patch, actually, suffers from this bug:

-               clear_tsk_thread_flag(child, TIF_SYSCALL_TRACE);
+               clear_tsk_thread_flag(child, TIF_SYSCALL_TRACE|
TIF_SYSCALL_EMU);

Actually, clear_tsk_thread_flag does not take a bitmask, so this code is 
wrong. But this is invoked only on PTRACE_SINGLESTEP.

> The check for host's 
> sysemu-support done in UML differs between the sysemu-patches for UML-2.4
> and UML-2.6:

Which trees are you using? The 2.6.8.1-1um + incremental tree and 2.4 tree 
contain the guest SYSEMU implementation from Jeff Dike, which has some 
differences from the original one included in 2.6.9-rc2. For instance, the 
original one has not got the 1st bug you identified when running on a 
SYSEMUless host. From what you describe

> - In UML-2.4 "getpid()" is written as result (eax) of the systemcall, which
> fakes the syscall-result on a 2.4-host,
I.e., the 2.4 behaviour is correct.
> but does nothing on a 2.6, where it 
> again is overwritten by running the syscall on the host!
So the patch below for SKAS is needed.
> Thus, a UML-2.4 
> will run on hosts with sysemu-support only, if it is a 2.4 host!
If the host != 2.4 it won't use sysemu, correct?

> - In UML-2.6 "getpid()" is written to the number of the systemcall! But the
> result in eax is not written, it still contains the original syscall
> number. On a 2.4-host this number is returned. In most cases this will let
> the further checks in UML succeed, but no guarantee...

I.e. you mean that this code (which is only in the 2.6/2.4 Jeff Dike tree)

+               n = ptrace(PTRACE_POKEUSER, pid, PT_SYSCALL_RET_OFFSET,
+                          os_getpid());
(which writes the return code value) is not the same as this code (which is in 
the 2.6.9-rc2 and following kernels):

               if (ptrace(PTRACE_GETREGS, pid, 0, &regs) < 0)
                        panic("check_ptrace : failed to read child "
                              "registers, errno = %d", errno);
                regs.orig_eax = pid;
                if (ptrace(PTRACE_SETREGS, pid, 0, &regs) < 0)
                        panic("check_ptrace : failed to modify child "
                              "registers, errno = %d", errno);
(which writes to orig_eax, i.e. the syscall number)? I guess that they are 
actually different, but in this case I think that the correct code is the one 
found in the first case, i.e. in the jdike kernel tree. But I thought you 
used the jdike 2.6.8.1-1um kernel tree.

So using the jdike code in both kernels (for the guest problem) and the patch 
below for the host should solve all the issues, right?

>   On a 2.6-host the systemcall with the faked number now will be processed
> on the host. In most cases the number should be invalid, thus the result is
> -ENOSYS, the checks in UML will succeed. But what happens, if the faked
> syscall number is a number known on the host ...

>   Thus a UML-2.6 will run on all host versions (in most cases ...)

Please clarify what you mean by "a certain UML will run only on certain 
hosts". You mean a SYSEMU patched UML will use SYSEMU only on certain hosts, 
right?

> Solution:

> - the host-patch for 2.6 should be modified. Before calling ptrace_notify()
>   do_syscall_trace() should save the state of the PTRACE_SYSEMU
> (true/false) and should use that saved state as return value.

Yes! Oh what fucking error! Is this patch correct (it's cut and paste, so you 
may apply it by hand)?

--- 
vanilla-linux-2.6.7-SKAS/arch/i386/kernel/ptrace.c~fix-sysemu-when-changing-state   
2004-10-08 17:08:03.992893504 +0200
+++ vanilla-linux-2.6.7-SKAS-paolo/arch/i386/kernel/ptrace.c    2004-10-08 
17:08:59.626435920 +0200
@@ -585,6 +585,7 @@ out:
 __attribute__((regparm(3)))
 int do_syscall_trace(struct pt_regs *regs, int entryexit)
 {
+       int is_sysemu;
        if (unlikely(current->audit_context)) {
                if (!entryexit)
                        audit_syscall_entry(current, regs->orig_eax,
@@ -593,8 +594,9 @@ int do_syscall_trace(struct pt_regs *reg
                else
                        audit_syscall_exit(current, regs->eax);
        }
+       is_sysemu = test_thread_flag(TIF_SYSCALL_EMU);

-       if (!test_thread_flag(TIF_SYSCALL_TRACE) 
&& !test_thread_flag(TIF_SYSCALL_EMU))
+       if (!test_thread_flag(TIF_SYSCALL_TRACE) && !is_sysemu)
                return 0;
        if (!(current->ptrace & PT_PTRACED))
                return 0;
@@ -613,5 +615,5 @@ int do_syscall_trace(struct pt_regs *reg
                current->exit_code = 0;
        }
        /* != 0 if nullifying the syscall, 0 if running it normally */
-       return test_thread_flag(TIF_SYSCALL_EMU);
+       return is_sysemu;
 }



> - check_sysemu() in UML-2.6 should be modified to write the result, not the
> sycall number. And it should do it in a portable way.

> By the way: it is not enough to change the checks only. The 2.6-host's
> behavior will cause problems as well, if a process in UML is singlestepped.
> And there will be problems, if someone switches off sysemu while UML is
> running.
In fact, as I said above.
> Bodo

-- 
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Kernel panic: check_ptrace : child exited with status 0x100

[BlaisorBlade]

[-- Attachment #1: Type: text/plain, Size: 5098 bytes --]

On Friday 08 October 2004 13:59, bodo.stroesser@fujitsu-siemens.com wrote:
> caker@theshore.net said:
> > Ok, so a new combination.  This is 2.4.27 + 2.4.26-um + all the
> > incremental + Bodo's sysemu-panic patch.  It works fine on non-sysemu
> > hosts, and on a host with the original version of sysemu.

> > I think the key here is that this host has the latest (v5) SKAS patch,
> > whereas the 2.6.7 host kernel used the standard sysemu patch.
Yes, and I'm sorry for that.
> Please note, my knowledge about this only comes from reading the source
> code only. Thus, if I'm wrong, tell me.

> AFAICS, the behavior of the latest skas patches for 2.4 and 2.6 regarding
> sysemu is *very* different. And I believe, the 2.6 is wrong!

Yes, I have now finished studying well all the code acting here. And I now 
understand by myself almost every single word you said, and agree on all.

> Problem:
> On both host versions a process will stop, if it is started with
> PTRACE_SYSEMU and if it tries to execute a systemcall. But what happens
> with the traced systemcall when it is resumed differs between the two host
> versions.

> On host 2.4 the syscall will immediately return to user presenting the
> result that had been written to the stack via ptrace(). This is done no
> matter if the process is resumed with PTRACE_SYSEMU, PTRACE_SYSCALL,
> PTRACE_SINGLESTEP or PTRACE_CONT. On host 2.6 the syscall will immediately
> return to user only if the process is restarted with PTREACE_SYSEMU! In the
> other cases the syscall will be executed on the host, the result from this
> will overwrite the result written via ptrace().
Yes, I confirm the patch I sent in my previous email for the host. I still 
need to test that, but I'll do this soon. It's reattached as 
"fix-sysemu-when-changing-state.patch".

> The check for host's 
> sysemu-support done in UML differs between the sysemu-patches for UML-2.4
> and UML-2.6:
> - In UML-2.4 "getpid()" is written as result (eax) of the systemcall, which
> fakes the syscall-result on a 2.4-host, but does nothing on a 2.6, where it
> again is overwritten by running the syscall on the host! Thus, a UML-2.4
> will run on hosts with sysemu-support only, if it is a 2.4 host!

I.e. UML-2.4 will run on everything but a 2.6 sysemu-supporting host, unless 
the host has the patch I sent in the last mail (supposing it does what it 
should do). I.e. the 2.4 UML check is written the right way. Compliments to 
Jeff for this. However, you did not realize he was fixing it, or I'll flame 
you Jeff, for fixing it without notice in the description.

And the test will fail because it _exit(os_getpid() == pid); will become 
_exit(1);. Btw, with Jeff Dike I don't feel really the danger of comment 
bloat!

> - In UML-2.6 "getpid()" is written to the number of the systemcall! But the
> result in eax is not written, it still contains the original syscall
> number. On a 2.4-host this number is returned. In most cases this will let
> the further checks in UML succeed, but no guarantee...

Well, instead of checking simply that getpid() != truePid, we should also 
check that it either returns either the real getpid() value or the real 
getppid() value (the parent thread makes sure that it gets either one, 
doesn't it?), and have a special failure case when this is false. However, 
this is a separate patch, named uml-more-careful-test-startup.patch.

Instead, the fix for this (against the 2.6.9-rc2 tree; the version Jeff Dike 
included in his tree was correct in this regard) is attached as 
"uml-fix-sysemu-test-startup".

Also, the same difference applies also for 2.4: the original um-sysemu patch 
from Laurent Vivier has the same bug you see on 2.6 - Jeff Dike fixed both 
versions in his trees (I guess he didn't notice the difference, and was 
probably just making it portable; he didn't think that the code used 
orig_eax, he just read Laurent Vivier's mind :-@ ).

>   On a 2.6-host the systemcall with the faked number now will be processed
> on the host. In most cases the number should be invalid, thus the result is
> -ENOSYS, the checks in UML will succeed. But what happens, if the faked
> syscall number is a number known on the host ...
>   Thus a UML-2.6 will run on all host versions (in most cases ...)

> Solution:
> - the host-patch for 2.6 should be modified. Before calling ptrace_notify()
>   do_syscall_trace() should save the state of the PTRACE_SYSEMU
> (true/false) and should use that saved state as return value.
> - check_sysemu() in UML-2.6 should be modified to write the result, not the
> sycall number. And it should do it in a portable way.
You refer to the usage of regs.orig_eax, instead of the portable 
PT_SYSCALL_RET_OFFSET used elsewhere (or in general PT_SYSCALL_*_OFFSET)

> By the way: it is not enough to change the checks only. The 2.6-host's
> behavior will cause problems as well, if a process in UML is singlestepped.

> And there will be problems, if someone switches off sysemu while UML is
> running.
Experienced them, as I said.
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729

[-- Attachment #2: fix-sysemu-when-changing-state.patch --]
[-- Type: text/x-diff, Size: 1674 bytes --]


In do_syscall_trace, we check the status of the TIF_SYSCALL_EMU flag only
after doing the debugger notification; but the debugger might have changed the
status of this flag because he continued execution with PTRACE_SYSCALL, so
this is buggy. This patch fixes it by saving the flag status before calling
ptrace_notify.

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade_spam@yahoo.it>
---

 linux-2.6.9-current-paolo/arch/i386/kernel/ptrace.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff -puN arch/i386/kernel/ptrace.c~fix-sysemu-when-changing-state arch/i386/kernel/ptrace.c
--- linux-2.6.9-current/arch/i386/kernel/ptrace.c~fix-sysemu-when-changing-state	2004-10-14 18:35:47.798088672 +0200
+++ linux-2.6.9-current-paolo/arch/i386/kernel/ptrace.c	2004-10-14 18:35:47.885075448 +0200
@@ -589,6 +589,7 @@ out:
 __attribute__((regparm(3)))
 int do_syscall_trace(struct pt_regs *regs, int entryexit)
 {
+	int is_sysemu;
 	if (unlikely(current->audit_context)) {
 		if (!entryexit)
 			audit_syscall_entry(current, regs->orig_eax,
@@ -597,10 +598,11 @@ int do_syscall_trace(struct pt_regs *reg
 		else
 			audit_syscall_exit(current, regs->eax);
 	}
+	is_sysemu = test_thread_flag(TIF_SYSCALL_EMU);
 
 	if (!test_thread_flag(TIF_SYSCALL_TRACE) &&
 	    !test_thread_flag(TIF_SINGLESTEP) &&
-	    !test_thread_flag(TIF_SYSCALL_EMU))
+	    !is_sysemu)
 		return 0;
 	if (!(current->ptrace & PT_PTRACED))
 		return 0;
@@ -619,5 +621,5 @@ int do_syscall_trace(struct pt_regs *reg
 		current->exit_code = 0;
 	}
 	/* != 0 if nullifying the syscall, 0 if running it normally */
-	return test_thread_flag(TIF_SYSCALL_EMU);
+	return is_sysemu;
 }
_

[-- Attachment #3: uml-fix-sysemu-test-startup.patch --]
[-- Type: text/x-diff, Size: 2345 bytes --]


From: Paolo 'Blaisorblade' Giarrusso <blaisorblade_spam@yahoo.it>, Bodo Stroesser <bodo.stroesser@fujitsu-siemens.com>, Jeff Dike <jdike@addtoit.com>

Currently, the test for the SYSEMU support on the host is completely wrong, as
Bodo noticed. We should change the syscall result (inserting the host pid) and
check if it is received correctly by the guest. What we actually do, without
this patch, is to overwrite the syscall number.

This went unnoticed because we only check that the getpid() syscall from the
child does not return its pid. We don't check that it returns the correct
value.

Also, override the result portably, using the PT_SYSCALL_RET_OFFSET macro
which abstract away the host stack frame layout (took from Jeff Dike code).

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade_spam@yahoo.it>
---

 linux-2.6.9-current-paolo/arch/um/kernel/process.c |   16 ++++++----------
 1 files changed, 6 insertions(+), 10 deletions(-)

diff -puN arch/um/kernel/process.c~uml-fix-sysemu-test-startup arch/um/kernel/process.c
--- linux-2.6.9-current/arch/um/kernel/process.c~uml-fix-sysemu-test-startup	2004-10-14 18:57:30.224089824 +0200
+++ linux-2.6.9-current-paolo/arch/um/kernel/process.c	2004-10-14 19:31:19.840541224 +0200
@@ -214,8 +214,6 @@ static void __init check_sysemu(void)
 	sysemu_supported = 0;
 	pid = start_ptraced_child(&stack);
 	if(ptrace(PTRACE_SYSEMU, pid, 0, 0) >= 0) {
-		struct user_regs_struct regs;
-
 		CATCH_EINTR(n = waitpid(pid, &status, WUNTRACED));
 		if (n < 0)
 			panic("check_ptrace : wait failed, errno = %d", errno);
@@ -223,18 +221,16 @@ static void __init check_sysemu(void)
 			panic("check_ptrace : expected SIGTRAP, "
 			      "got status = %d", status);
 
-		if (ptrace(PTRACE_GETREGS, pid, 0, &regs) < 0)
-			panic("check_ptrace : failed to read child "
-			      "registers, errno = %d", errno);
-		regs.orig_eax = pid;
-		if (ptrace(PTRACE_SETREGS, pid, 0, &regs) < 0)
-			panic("check_ptrace : failed to modify child "
-			      "registers, errno = %d", errno);
+		n = ptrace(PTRACE_POKEUSER, pid, PT_SYSCALL_RET_OFFSET,
+			   os_getpid());
+		if(n < 0)
+			panic("check_ptrace : failed to modify system "
+			      "call return, errno = %d", errno);
 
 		stop_ptraced_child(pid, stack, 0);
 
 		sysemu_supported = 1;
-		printk("found\n");
+		printk("OK\n");
 	}
 	else
 	{
_

[-- Attachment #4: uml-more-careful-test-startup.patch --]
[-- Type: text/x-diff, Size: 3816 bytes --]


From: Paolo 'Blaisorblade' Giarrusso <blaisorblade_spam@yahoo.it>, Bodo Stroesser <bodo.stroesser@fujitsu-siemens.com>

While testing the host ptrace(2) features, we modify the stack frame of a test
child which is doing a syscall (namely getpid). Either we override the syscall
number or the return value, which become the parent's pid, or we don't, and
the return value is the child's pid.

Actually, we only compared the return value with the child's pid, so we did
not notice a bug where the return value happened to be different from both. So
I added a stricter test here.

Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade_spam@yahoo.it>
---

 linux-2.6.9-current-paolo/arch/um/kernel/process.c |   41 +++++++++++++++------
 1 files changed, 31 insertions(+), 10 deletions(-)

diff -puN arch/um/kernel/process.c~uml-more-careful-test-startup arch/um/kernel/process.c
--- linux-2.6.9-current/arch/um/kernel/process.c~uml-more-careful-test-startup	2004-10-14 20:05:22.894949744 +0200
+++ linux-2.6.9-current-paolo/arch/um/kernel/process.c	2004-10-14 20:25:05.601151072 +0200
@@ -137,14 +137,30 @@ int start_fork_tramp(void *thread_arg, u
 
 static int ptrace_child(void *arg)
 {
-	int pid = os_getpid();
+	int ret;
+	int pid = os_getpid(), ppid = getppid();
+	int sc_result;
 
 	if(ptrace(PTRACE_TRACEME, 0, 0, 0) < 0){
 		perror("ptrace");
 		os_kill_process(pid, 0);
 	}
 	os_stop_process(pid);
-	_exit(os_getpid() == pid);
+
+	/*This syscall will be intercepted by the parent. Don't call more than
+	 * once, please.*/
+	sc_result = os_getpid();
+
+	if (sc_result == pid)
+		ret = 1; /*Nothing modified by the parent, we are running
+			   normally.*/
+	else if (sc_result == ppid)
+		ret = 0; /*Expected in check_ptrace and check_sysemu when they
+			   succeed in modifying the stack frame*/
+	else
+		ret = 2; /*Serious trouble! This can be caused by a bug in
+			   host 2.6 SKAS3/2.6 patch before release -V6.*/
+	_exit(ret);
 }
 
 static int start_ptraced_child(void **stack_out)
@@ -179,8 +195,16 @@ static void stop_ptraced_child(int pid, 
 	if(ptrace(PTRACE_CONT, pid, 0, 0) < 0)
 		panic("check_ptrace : ptrace failed, errno = %d", errno);
 	CATCH_EINTR(n = waitpid(pid, &status, 0));
-	if(!WIFEXITED(status) || (WEXITSTATUS(status) != exitcode))
-		panic("check_ptrace : child exited with status 0x%x", status);
+	if(!WIFEXITED(status) || (WEXITSTATUS(status) != exitcode)) {
+		int exit_with = WEXITSTATUS(status);
+		if (exit_with == 2)
+			printk("check_ptrace : child exited with status 2. "
+			       "Serious trouble happening! Try updating your "
+			       "host skas patch!");
+		panic("check_ptrace : child exited with exitcode %d, while "
+		      "expecting %d; status 0x%x", exit_with,
+		      exitcode, status);
+	}
 
 	if(munmap(stack, PAGE_SIZE) < 0)
 		panic("check_ptrace : munmap failed, errno = %d", errno);
@@ -207,24 +231,21 @@ static void __init check_sysemu(void)
 	void *stack;
 	int pid, n, status;
 
-	if (mode_tt)
-		return;
-
 	printk("Checking syscall emulation patch for ptrace...");
 	sysemu_supported = 0;
 	pid = start_ptraced_child(&stack);
 	if(ptrace(PTRACE_SYSEMU, pid, 0, 0) >= 0) {
 		CATCH_EINTR(n = waitpid(pid, &status, WUNTRACED));
 		if (n < 0)
-			panic("check_ptrace : wait failed, errno = %d", errno);
+			panic("check_sysemu : wait failed, errno = %d", errno);
 		if(!WIFSTOPPED(status) || (WSTOPSIG(status) != SIGTRAP))
-			panic("check_ptrace : expected SIGTRAP, "
+			panic("check_sysemu : expected SIGTRAP, "
 			      "got status = %d", status);
 
 		n = ptrace(PTRACE_POKEUSER, pid, PT_SYSCALL_RET_OFFSET,
 			   os_getpid());
 		if(n < 0)
-			panic("check_ptrace : failed to modify system "
+			panic("check_sysemu : failed to modify system "
 			      "call return, errno = %d", errno);
 
 		stop_ptraced_child(pid, stack, 0);
_

Re: [uml-devel] Kernel panic: check_ptrace : child exited with status 0x100

[Bodo Stroesser]

BlaisorBlade wrote:
> 
> Yes, I confirm the patch I sent in my previous email for the host. I still 
> need to test that, but I'll do this soon. It's reattached as 
> "fix-sysemu-when-changing-state.patch".
> 
OK. Now I've had time to test with sysemu. But unfortunately the patch for the
2.6 host isn't enough! It still crashes if sysemu is switched off dynamically
via /proc/sysemu.
The problem is in arch/i386/kernel/entry.S. The latest host-patch v6 inhibits
the syscall-handler to be called, but does not prevent do_syscall_trace to be
called after this for syscall completion interception. The appended patch
fixes this. It reuses the TIF_SINGLESTEP flag to remember "we come from
PTRACE_SYSEMU and now are in PTRACE_SYSCALL", since the flag is unused in the
depicted situation.
Feel free to change it, if you see the need to use  an other or a new defined
flag for this.

The patch is tested, AFAICS, it works fine, i.e. sysemu can be switched on and
off dynamically without crash.

For the 2.4 host, this seems to be not relevant. But I could read the source
only. Does anyone know, whether sysemu on/off works on host 2.4?

Bodo

---

--- linux-2.6.7-old/arch/i386/kernel/ptrace.c	2004-10-20 16:57:25.148861788 +0200
+++ linux-2.6.7/arch/i386/kernel/ptrace.c	2004-10-20 17:08:47.722062593 +0200
@@ -598,6 +598,16 @@

  	if (!test_thread_flag(TIF_SYSCALL_TRACE) && !is_sysemu)
  		return 0;
+	/* We can detect the case of coming from PTRACE_SYSEMU and now
+	 * running with PTRACE_SYSCALL, by TIF_SINGLESTEP being set
+	 * additionally.
+	 * If so let's reset the flag and return without action.
+	 */
+	if (test_thread_flag(TIF_SINGLESTEP) &&
+	    test_thread_flag(TIF_SYSCALL_TRACE)) {
+		clear_thread_flag(TIF_SINGLESTEP);
+		return 0;
+	}
  	if (!(current->ptrace & PT_PTRACED))
  		return 0;
  	/* the 0x80 provides a way for the tracing parent to distinguish
@@ -605,6 +615,15 @@
  	ptrace_notify(SIGTRAP | ((current->ptrace & PT_TRACESYSGOOD)
  				 ? 0x80 : 0));

+	/* If we came here with PTRACE_SYSEMU and now continue with
+	 * PTRACE_SYSCALL, entry.S used to intercept the syscall return. But it
+	 * shouldn't!
+	 * So we additionally use TIF_SINGLESTEP, which is always unused in this
+	 * special case, to remember, we came from SYSEMU.
+	 */
+	if (is_sysemu && test_thread_flag(TIF_SYSCALL_TRACE))
+		set_thread_flag(TIF_SINGLESTEP);
+
  	/*
  	 * 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


-------------------------------------------------------
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Kernel panic: check_ptrace : child exited with status 0x100

[Bodo Stroesser]

Bodo Stroesser wrote:
> The patch is tested, AFAICS, it works fine, i.e. sysemu can be switched on and
> off dynamically without crash.
> 
Here is a new version of the patch. I changed it to use TIF_SYSCALL_EMU
instead of TIF_SINGLETSTEP. This is more intuitive, I think.


Bodo

---

--- a/arch/i386/kernel/ptrace.c	2004-10-20 16:57:25.000000000 +0200
+++ b/arch/i386/kernel/ptrace.c	2004-10-21 09:55:00.000000000 +0200
@@ -585,7 +585,7 @@
  __attribute__((regparm(3)))
  int do_syscall_trace(struct pt_regs *regs, int entryexit)
  {
-	int is_sysemu;
+	int is_sysemu, is_systrace;
  	if (unlikely(current->audit_context)) {
  		if (!entryexit)
  			audit_syscall_entry(current, regs->orig_eax,
@@ -595,9 +595,19 @@
  			audit_syscall_exit(current, regs->eax);
  	}
  	is_sysemu = test_thread_flag(TIF_SYSCALL_EMU);
+	is_systrace = test_thread_flag(TIF_SYSCALL_TRACE);

-	if (!test_thread_flag(TIF_SYSCALL_TRACE) && !is_sysemu)
+	if (!is_systrace && !is_sysemu)
  		return 0;
+	/* We can detect the case of coming from PTRACE_SYSEMU and now
+	 * running with PTRACE_SYSCALL, by TIF_SYSCALL_EMU being set
+	 * additionally.
+	 * If so let's reset the flag and return without action.
+	 */
+	if (is_sysemu && is_systrace) {
+		clear_thread_flag(TIF_SYSCALL_EMU);
+		return 0;
+	}
  	if (!(current->ptrace & PT_PTRACED))
  		return 0;
  	/* the 0x80 provides a way for the tracing parent to distinguish
@@ -605,6 +615,15 @@
  	ptrace_notify(SIGTRAP | ((current->ptrace & PT_TRACESYSGOOD)
  				 ? 0x80 : 0));

+	/* If we came here with PTRACE_SYSEMU and now continue with
+	 * PTRACE_SYSCALL, entry.S used to intercept the syscall return. But it
+	 * shouldn't!
+	 * So we additionally use TIF_SYSCALL_EMU, which is always unused in this
+	 * special case, to remember, we came from SYSEMU.
+	 */
+	if (is_sysemu && test_thread_flag(TIF_SYSCALL_TRACE))
+		set_thread_flag(TIF_SYSCALL_EMU);
+
  	/*
  	 * 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


-------------------------------------------------------
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Kernel panic: check_ptrace : child exited with status 0x100

[BlaisorBlade]

On Wednesday 20 October 2004 19:00, Bodo Stroesser wrote:
> BlaisorBlade wrote:
> > Yes, I confirm the patch I sent in my previous email for the host. I
> > still need to test that, but I'll do this soon. It's reattached as
> > "fix-sysemu-when-changing-state.patch".

> OK. Now I've had time to test with sysemu. But unfortunately the patch for
> the 2.6 host isn't enough! It still crashes if sysemu is switched off
> dynamically via /proc/sysemu.
Yes, I had seen this, but had not found a clue, even if I came across the 
problematic code. THANKS FOR FIXING THIS!!!!! YU-UH!

> The problem is in arch/i386/kernel/entry.S. The latest host-patch v6
> inhibits the syscall-handler to be called, but does not prevent
> do_syscall_trace to be called after this for syscall completion
> interception. The appended patch fixes this. It reuses the TIF_SINGLESTEP
> flag to remember "we come from PTRACE_SYSEMU and now are in
> PTRACE_SYSCALL", since the flag is unused in the depicted situation.

> Feel free to change it, if you see the need to use  an other or a new
> defined flag for this.

To use a new one you must be careful - there is interest in this using a 
little flag number. When you get more than 7 flags, you must test for them 
with "testw" instead of "testb". And if this happens in the syscall fast 
path, people on LKML start benchmarking the performance loss (I've actually 
read something such on kerneltrap.org). Well, at least on the syscall fast 
path. If the test is done only under ptrace, then it's not a problem.

Btw, the problem IMHO is not actually reading one more byte. The first SYSEMU 
patch, instead, added one more conditional jump to the fast-path. Which is 
bad, as noted by Jeff - one conditional jump can cost tens of cycles IIRC 
(I'm not completely sure, but if branch predition fails, the processor must 
empty its pipelines - even more costly on Pentium4).

So, I'll maybe add another flag.

> The patch is tested, AFAICS, it works fine, i.e. sysemu can be switched on
> and off dynamically without crash.

> For the 2.4 host, this seems to be not relevant. But I could read the
> source only. Does anyone know, whether sysemu on/off works on host 2.4?

Yes, it works. In fact, I developed that with 2.4 hosts. I understand the 
difference.

I'm going to take a look at this and integrate it - at least a comment near 
the TIF_* definition for this trick is warranted, if not something cleaner. 
I'd prefer to make it like 2.4 hosts, where the SYSCALL flag is not tested at 
all in the SYSEMU case. I'll try to do this.

> --- linux-2.6.7-old/arch/i386/kernel/ptrace.c	2004-10-20 16:57:25.148861788
> +0200 +++ linux-2.6.7/arch/i386/kernel/ptrace.c	2004-10-20
> 17:08:47.722062593 +0200 @@ -598,6 +598,16 @@
>
>   	if (!test_thread_flag(TIF_SYSCALL_TRACE) && !is_sysemu)
>   		return 0;
> +	/* We can detect the case of coming from PTRACE_SYSEMU and now
> +	 * running with PTRACE_SYSCALL, by TIF_SINGLESTEP being set
> +	 * additionally.
> +	 * If so let's reset the flag and return without action.
> +	 */
> +	if (test_thread_flag(TIF_SINGLESTEP) &&
> +	    test_thread_flag(TIF_SYSCALL_TRACE)) {
> +		clear_thread_flag(TIF_SINGLESTEP);
> +		return 0;
> +	}
>   	if (!(current->ptrace & PT_PTRACED))
>   		return 0;
>   	/* the 0x80 provides a way for the tracing parent to distinguish

> @@ -605,6 +615,15 @@
>   	ptrace_notify(SIGTRAP | ((current->ptrace & PT_TRACESYSGOOD)
>   				 ? 0x80 : 0));
This may be the raw 2.6.9 source - but currently (2.6.9-bk4) the source is 
this
       ptrace_notify(SIGTRAP | ((current->ptrace & PT_TRACESYSGOOD) &&
                                 !test_thread_flag(TIF_SINGLESTEP) ? 0x80 : 
0));

I think that the second version of your patch is safe against this, but I'm 
not looking at this in detail for now (no time, sorry).

> +	/* If we came here with PTRACE_SYSEMU and now continue with
> +	 * PTRACE_SYSCALL, entry.S used to intercept the syscall return. But it
> +	 * shouldn't!
> +	 * So we additionally use TIF_SINGLESTEP, which is always unused in this
> +	 * special case, to remember, we came from SYSEMU.
> +	 */
> +	if (is_sysemu && test_thread_flag(TIF_SYSCALL_TRACE))
> +		set_thread_flag(TIF_SINGLESTEP);

Ok, this is run when issuing the first tracing just after switching off 
SYSEMU.
>   	/*
>   	 * 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

-- 
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

RE: [uml-devel] Kernel panic: check_ptrace : child exited with status 0x100

[Stroesser, Bodo]

On Friday 08 October 2004 13:59, BlaisorBlade wrote:
> I.e. you mean that this code (which is only in the 2.6/2.4 Jeff Dike
tree)
> 
> +               n = ptrace(PTRACE_POKEUSER, pid,
PT_SYSCALL_RET_OFFSET,
> +                          os_getpid());
> (which writes the return code value) is not the same as this code
(which is in 
> the 2.6.9-rc2 and following kernels):
> 
>                if (ptrace(PTRACE_GETREGS, pid, 0, &regs) < 0)
>                         panic("check_ptrace : failed to read child "
>                              "registers, errno = %d", errno);
>                 regs.orig_eax = pid;
>                 if (ptrace(PTRACE_SETREGS, pid, 0, &regs) < 0)
>                         panic("check_ptrace : failed to modify child "
>                               "registers, errno = %d", errno);
> (which writes to orig_eax, i.e. the syscall number)? I guess that they
are 
> actually different, but in this case I think that the correct code is
the one 
> found in the first case, i.e. in the jdike kernel tree. But I thought
you 
> used the jdike 2.6.8.1-1um kernel tree.
> 
> So using the jdike code in both kernels (for the guest problem) and
the patch 
> below for the host should solve all the issues, right?
Yes. I agree. But the only thing, that I can say, is, "it should solve".
Currently, I have no 2.6.7 host running, thus I can't test, even if I
would like to.

> Please clarify what you mean by "a certain UML will run only on
certain 
> hosts". You mean a SYSEMU patched UML will use SYSEMU only on certain
hosts, 
> right?
No. The problem is, if UML gets an error calling ptrace(PTRACE_SYSEMU,
...), it will
run without using sysemu. But if the ptrace-call returns "OK", it will
panic, if the
further checks fail!
I thought about host and UML with sysemu-support only. There you have
four possible
combinations, from which only one always panics! The other will work
mostly,
depending on the host-pids the processes have.

> > Solution:
> 
> > - the host-patch for 2.6 should be modified. Before calling
ptrace_notify()
> >   do_syscall_trace() should save the state of the PTRACE_SYSEMU
> > (true/false) and should use that saved state as return value.
> 
> Yes! Oh what fucking error! Is this patch correct (it's cut and paste,
so you 
> may apply it by hand)?
Sorry, I can't do that at the moment. But maybe Christopher can do that?

Bodo

For Christopher:
Sorry, I accidentally missed to CC you on my last mail. So, if you
are not on the list, you didn't missed this plus the mail from
BlaisorBlade.
Please look to the archive or request for a resend from me.


-------------------------------------------------------
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

RE: [uml-devel] Kernel panic: check_ptrace : child exited with status 0x100

[Stroesser, Bodo]

 

-----Original Message-----
From: user-mode-linux-devel-admin@lists.sourceforge.net
[mailto:user-mode-linux-devel-admin@lists.sourceforge.net] On Behalf Of
Christopher S. Aker
Sent: Thursday, October 07, 2004 11:17 PM
To: uml-devel
Subject: [uml-devel] Kernel panic: check_ptrace : child exited with
status 0x100

Ok, so a new combination.  This is 2.4.27 + 2.4.26-um + all the
incremental + Bodo's
sysemu-panic patch.  It works fine on non-sysemu hosts, and on a host
with the
original version of sysemu.

I think the key here is that this host has the latest (v5) SKAS patch,
whereas the
2.6.7 host kernel used the standard sysemu patch.

----
Checking for the skas3 patch in the host...found
Checking for /proc/mm...found
Checking PROT_EXEC mmap in /tmp...OK
Checking for /dev/anon on the host...Not available (open failed with
errno 6)
Linux version 2.4.27-linode35-3um (caker@host4.linode.com) (gcc version
3.2.2
20030222 (Red Hat Linux 3.2.2-5)) #1 Wed Oct 6 11:31:28 EDT 2004
On node 0 totalpages: 16384
zone(0): 16384 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: mem=64M fake_ide fakehd con=null con0=fd:0,fd:1
devfs=nomount
root=/dev/ubda ubda=/linodes/luctourangeau/13588.fs
ubdb=/linodes/luctourangeau/13586.fs
eth0=tuntap,luctourangeau_0,fe:fd:46:55:10:64
token_max=400000 token_refill=512
fakehd : Changing ubd_gendisk.major_name to "hd".
Calibrating delay loop... 3787.98 BogoMIPS
Memory: 59436k available
Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
Inode cache hash table entries: 4096 (order: 3, 32768 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
Checking for host processor cmov support...Yes
Checking for host processor xmm support...No
Checking that ptrace can change system call numbers...OK
Checking syscall emulation patch for ptrace...<0>Kernel panic:
check_ptrace : child
exited with status 0x100
In idle task - not syncing
 <6>SysRq : Show Regs

EIP: 0000:[<00000000>] CPU: 0 Not tainted EFLAGS: 00000000
    Not tainted
EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000
ESI: 00000000 EDI: 00000000 EBP: 00000000 DS: 0000 ES: 0000
Call Trace: [<80315778>] [<80317cb6>] [<800115f3>] [<801adc3a>]
[<801992f5>]
   [<8001e3fa>] [<80013cb4>] [<80193f0d>] [<8033efe0>] [<800075c5>]
[<803178fa>]
   [<8019d8a0>] [<80007b65>] [<800024b2>] [<8019d8a0>] [<80002459>]
[<8019d8c5>]
   [<8019d8a0>] [<80193fad>] [<8019d8a0>] [<80193f88>] [<8019d8a0>]
[<8019d609>]
   [<8019d8a0>] [<8019d07d>] [<802b0108>] [<802b0371>]

-Chris



-------------------------------------------------------
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel


-------------------------------------------------------
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Kernel panic: check_ptrace : child exited with status 0x100

[Christopher S. Aker]

Ok, so a new combination.  This is 2.4.27 + 2.4.26-um + all the incremental + Bodo's
sysemu-panic patch.  It works fine on non-sysemu hosts, and on a host with the
original version of sysemu.

I think the key here is that this host has the latest (v5) SKAS patch, whereas the
2.6.7 host kernel used the standard sysemu patch.

----
Checking for the skas3 patch in the host...found
Checking for /proc/mm...found
Checking PROT_EXEC mmap in /tmp...OK
Checking for /dev/anon on the host...Not available (open failed with errno 6)
Linux version 2.4.27-linode35-3um (caker@host4.linode.com) (gcc version 3.2.2
20030222 (Red Hat Linux 3.2.2-5)) #1 Wed Oct 6 11:31:28 EDT 2004
On node 0 totalpages: 16384
zone(0): 16384 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: mem=64M fake_ide fakehd con=null con0=fd:0,fd:1 devfs=nomount
root=/dev/ubda ubda=/linodes/luctourangeau/13588.fs
ubdb=/linodes/luctourangeau/13586.fs eth0=tuntap,luctourangeau_0,fe:fd:46:55:10:64
token_max=400000 token_refill=512
fakehd : Changing ubd_gendisk.major_name to "hd".
Calibrating delay loop... 3787.98 BogoMIPS
Memory: 59436k available
Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
Inode cache hash table entries: 4096 (order: 3, 32768 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
Checking for host processor cmov support...Yes
Checking for host processor xmm support...No
Checking that ptrace can change system call numbers...OK
Checking syscall emulation patch for ptrace...<0>Kernel panic: check_ptrace : child
exited with status 0x100
In idle task - not syncing
 <6>SysRq : Show Regs

EIP: 0000:[<00000000>] CPU: 0 Not tainted EFLAGS: 00000000
    Not tainted
EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000
ESI: 00000000 EDI: 00000000 EBP: 00000000 DS: 0000 ES: 0000
Call Trace: [<80315778>] [<80317cb6>] [<800115f3>] [<801adc3a>] [<801992f5>]
   [<8001e3fa>] [<80013cb4>] [<80193f0d>] [<8033efe0>] [<800075c5>] [<803178fa>]
   [<8019d8a0>] [<80007b65>] [<800024b2>] [<8019d8a0>] [<80002459>] [<8019d8c5>]
   [<8019d8a0>] [<80193fad>] [<8019d8a0>] [<80193f88>] [<8019d8a0>] [<8019d609>]
   [<8019d8a0>] [<8019d07d>] [<802b0108>] [<802b0371>]

-Chris



-------------------------------------------------------
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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel