Some changes in SKAS0

I tried to adapt fix-stub_segv-stack.patch to my s390. Unfortunately sigreturn on s390 needs to have the address of the entire signal-stackframe in r15. What is given to the handler as a param is a pointer to the sigcontext only. stackframe contains some space for handler's register saving _before_ sigcontext.
So I thought about avoiding the sigreturn at all. Working on this I found out some small points:

- there is a bug (typo) in wait_stub_done()

- stopping stub_segv_handler with a "breakpoint" without calling sigreturn, lets SIGSEGV being blocked after that. At the next SIGSEGV, I see stub_wait_done() calling panic just as with Rob's problem. And I see the child being gone! I understand, that the host unblocks SIGSEGV and sets the handler to SIG_DFL. But I don't understand, why the child already is gone after the waitpid(), without resuming it. I guess, this is the reason for Rob not being able to debug the problem.
Thus I added SA_NOMASK to the flags for the handler.

- I changed the additional mask for the handler to be empty. The only exception is x86_64, that currently must use sigreturn and therefore still masks SIGUSR1 while the handler runs. In skas, userspace shouldn't receive SIGIO or SIGWINCH (I hope I'm right here?), SIGVTALRM already is handled by wait_stub_done. Then I changed i386's stub_segv_handler to stop using "int3" immediately after saving faultinfo.
This new method saves some syscalls on i386 and s390 and simplifies s390.

All three patches are attached. They are tested in i386 and s390, for me they work fine. I hope, the patches don't break x86_64. Unfortunately I can't test that.
If there would be a solution for the RCX problem on x86_64, I would prefer to use the "int3" this subarch also, making the nasty ARCH_STUB_SEGV_MASK_SIGNAL macro obsolete.

Bodo

From: Bodo Stroesser <[email protected]>

Fix a typo in wait_stub_done.

---

diff -puN arch/um/os-Linux/skas/process.c~fix-wait_stub_done arch/um/os-Linux/skas/process.c
@@ -64,7 +64,7 @@ void wait_stub_done(int pid, int sig, ch
 	        (WSTOPSIG(status) == SIGVTALRM));
 
 	if((n < 0) || !WIFSTOPPED(status) ||
-	   (WSTOPSIG(status) != SIGUSR1 && WSTOPSIG(status != SIGTRAP))){
+	   (WSTOPSIG(status) != SIGUSR1 && WSTOPSIG(status) != SIGTRAP)){
 		panic("%s : failed to wait for SIGUSR1/SIGTRAP, "
 		      "pid = %d, n = %d, errno = %d, status = 0x%x\n",
 		      fname, pid, n, errno, status);

_

From: Bodo Stroesser <[email protected]>

Masking SIGSEGV in stub_segv_handler is bad. If a SIGSEGV happens while stub_segv_handler is running, the host will force the signal, so the child is killed. This makes stub_segv_handler hard to debug.
So, we add SA_NOMASK to the flags in sigaction, to have SIGSEGV unblocked, ebven while the handler runs.

---

diff -puN arch/um/os-Linux/skas/process.c~fix-SEGV-masking arch/um/os-Linux/skas/process.c
@@ -182,7 +182,7 @@ static int userspace_tramp(void *stack)
 				  (unsigned long) &__syscall_stub_start;
 
 		set_sigstack((void *) UML_CONFIG_STUB_DATA, page_size());
-		set_handler(SIGSEGV, (void *) v, SA_ONSTACK,
+		set_handler(SIGSEGV, (void *) v, SA_ONSTACK | SA_NOMASK,
 			    SIGIO, SIGWINCH, SIGALRM, SIGVTALRM,
 			    SIGUSR1, -1);
 	}

_

From: Bodo Stroesser <[email protected]>

This patch changes stub_segv_handler for i386 (and s390 later) to simplify it and save some syscalls.
My previous patch already left SIGSEGV unmasked while stub_segv_handler is running.
Now, we do no longer mask *any* signals if stub_segv_handler runs. SIG(RT)ALRM already is handled by wait_stub_done(), the other signals (SIGIO, SIGWINCH) must not happen.
stub_segv_handler for i386 (and s390) now stop *inside* stub_segv_handler using "int3" and do no longer call sigreturn.

For this, SIGUSR1 no longer should be blocked. So i386 (and s390) set:
#define ARCH_STUB_SEGV_MASK_SIGNAL -1
while x86_64 sets
#define ARCH_STUB_SEGV_MASK_SIGNAL SIGUSR1
Thus, x86_64 further uses sigreturn at the end of its stub_segv_handler to avoid the RCX problem. As soon as that problem is solved, x86_64 also might stop using "int3".

Using the change, we no longer need to care about correct stack pointer for sigreturn, which would cause some nasty code on s390.

---

diff -puN arch/um/os-Linux/skas/process.c~tune-stub_segv_handler arch/um/os-Linux/skas/process.c
@@ -183,8 +183,7 @@ static int userspace_tramp(void *stack)
 
 		set_sigstack((void *) UML_CONFIG_STUB_DATA, page_size());
 		set_handler(SIGSEGV, (void *) v, SA_ONSTACK | SA_NOMASK,
-			    SIGIO, SIGWINCH, SIGALRM, SIGVTALRM,
-			    SIGUSR1, -1);
+			    ARCH_STUB_SEGV_MASK_SIGNAL, -1);
 	}
 
 	os_stop_process(os_getpid());

diff -puN arch/um/sys-i386/stub_segv.c~tune-stub_segv_handler arch/um/sys-i386/stub_segv.c
@@ -19,13 +19,8 @@ stub_segv_handler(int sig)
 	GET_FAULTINFO_FROM_SC(*((struct faultinfo *) UML_CONFIG_STUB_DATA), 
 			      sc);
 
-	__asm__("movl %0, %%eax ; int $0x80": : "g" (__NR_getpid));
-	__asm__("movl %%eax, %%ebx ; movl %0, %%eax ; movl %1, %%ecx ;"
-		"int $0x80": : "g" (__NR_kill), "g" (SIGUSR1));
-	/* Load pointer to sigcontext into esp, since we need to leave
-	 * the stack in its original form when we do the sigreturn here, by
-	 * hand.
+	/* Our work is done, just stop the handler.
+	 * Registers will be restored later, if userspace() restarts us.
 	 */
-	__asm__("mov %0,%%esp ; movl %1, %%eax ; "
-		"int $0x80" : : "a" (sc), "g" (__NR_sigreturn));
+	__asm__("int3");
 }

diff -puN arch/um/include/sysdep-i386/faultinfo.h~tune-stub_segv_handler arch/um/include/sysdep-i386/faultinfo.h
@@ -26,4 +26,6 @@ struct faultinfo {
 
 #define PTRACE_FULL_FAULTINFO 0
 
+#define ARCH_STUB_SEGV_MASK_SIGNAL -1
+
 #endif

diff -puN arch/um/include/sysdep-x86_64/faultinfo.h~tune-stub_segv_handler arch/um/include/sysdep-x86_64/faultinfo.h
@@ -26,4 +26,6 @@ struct faultinfo {
 
 #define PTRACE_FULL_FAULTINFO 1
 
+#define ARCH_STUB_SEGV_MASK_SIGNAL SIGUSR1
+
 #endif

_

Thanks, I've got these saved away. I might not get to merge them until after KS/OLS though.

Jeff

-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

This patch causes sleep to hang sometimes for me. A sleep during shutdown reproducably hangs, as does the sleep before a reboot after a fsck found errors.

I had to track it down by bisection. I'm somewhat mystified by this. The only situation where this could cause a change in behavior is one that shouldn't happen, as far as I can see.

But it's definitely the cause. Pop the patch, the hangs go away, push it, they come back. I did this a couple times to be sure.

I'll debug this and figure out what's happening.

Jeff

-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Could you already find out what happens? On what subarch did you see the problem? If I understand correctly, a sleep() done by a UML userspace-task hangs?

Bodo

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

From our discussion yesterday, ...

I kept this patch

but dropped these two, plus my dont-save-fpregs patch. Correct?

Jeff

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Sorry, late reply: you are right.

Bodo

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel