[PATCH] 2.6.22.6 user-mode linux: fix error in check_sysemu

[PATCH] 2.6.22.6 user-mode linux: fix error in check_sysemu

[lepton]

  it is a error do count++ here, it will let the following compare (after 8 lines)   " if (!count)" always be false.

Signed-off-by: Lepton Wu <ytht.net@gmail.com>

diff -X linux-2.6.22.6/Documentation/dontdiff -pr -U 8 linux-2.6.22.6/arch/um/os-Linux/start_up.c linux-2.6.22.6-uml/arch/um/os-Linux/start_up.c
--- linux-2.6.22.6/arch/um/os-Linux/start_up.c	2007-09-14 17:41:10.000000000 +0800
+++ linux-2.6.22.6-uml/arch/um/os-Linux/start_up.c	2007-09-23 20:14:08.000000000 +0800
@@ -250,17 +250,16 @@ static void __init check_sysemu(void)
 	non_fatal("Checking advanced syscall emulation patch for ptrace...");
 	pid = start_ptraced_child(&stack);
 
 	if((ptrace(PTRACE_OLDSETOPTIONS, pid, 0,
 		   (void *) PTRACE_O_TRACESYSGOOD) < 0))
 		fatal_perror("check_ptrace: PTRACE_OLDSETOPTIONS failed");
 
 	while(1){
-		count++;
 		if(ptrace(PTRACE_SYSEMU_SINGLESTEP, pid, 0, 0) < 0)
 			goto fail;
 		CATCH_EINTR(n = waitpid(pid, &status, WUNTRACED));
 		if(n < 0)
 			fatal_perror("check_ptrace : wait failed");
 
 		if(WIFSTOPPED(status) && (WSTOPSIG(status) == (SIGTRAP|0x80))){
 			if (!count)

Re: [PATCH] 2.6.22.6 user-mode linux: fix error in check_sysemu

[Jeff Dike]

On Sun, Sep 23, 2007 at 08:26:53PM +0800, lepton wrote:
>   it is a error do count++ here, it will let the following compare
>(after 8 lines)   " if (!count)" always be false.

> -		count++;

Have you booted a UML with this change?  It looks to me like you'll
just make it crash on boot every time.

Something is wrong here, but ripping out that one line doesn't look
like the fix.

				Jeff

-- 
Work email - jdike at linux dot intel dot com

Re: [PATCH] 2.6.22.6 user-mode linux: fix error in check_sysemu

[Jeff Dike]

On Sun, Sep 23, 2007 at 08:26:53PM +0800, lepton wrote:
>   it is a error do count++ here, it will let the following compare
> (after 8 lines)   " if (!count)" always be false. 

I take back what I said.  It looks like it's checking for some
non-zero number of traps, which would be for the instructions leading
up to the next system call, followed by the system call.

It bails out if the system call is the first thing it sees.

Given this, I think your patch is correct.

				Jeff

-- 
Work email - jdike at linux dot intel dot com