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

[BlaisorBlade <blaisorblade_spam@yahoo.it>]

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