Jeff Dike wrote:

From our discussion yesterday, ...

On Fri, Jul 15, 2005 at 05:36:34PM +0200, Bodo Stroesser wrote:

quoted

So I thought about avoiding the sigreturn at all. Working on
this I found out some small points:

I kept this patch

quoted

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

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

quoted

- 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.

				Jeff

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