2007-09-23 12:28:01

by lepton

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

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 <[email protected]>

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)


2007-09-24 16:49:30

by Jeff Dike

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

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

2007-09-24 16:52:43

by Jeff Dike

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

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