linux-um archives
 help / color / mirror / Atom feed
From: Bodo Stroesser <bstroesser@fujitsu-siemens.com>
To: Blaisorblade <blaisorblade_spam@yahoo.it>
Cc: user-mode-linux-devel@lists.sourceforge.net,
	Jeff Dike <jdike@addtoit.com>
Subject: Re: [uml-devel] Patchset to implement PTRACE_SYSEMU_SINGLESTEP
Date: Mon, 15 Nov 2004 18:11:37 +0100	[thread overview]
Message-ID: <4198E349.5070809@fujitsu-siemens.com> (raw)
In-Reply-To: <200411130043.25888.blaisorblade_spam@yahoo.it>

[-- Attachment #1: Type: text/plain, Size: 2696 bytes --]

Blaisorblade wrote:
> On Friday 12 November 2004 21:05, Bodo Stroesser wrote:
> 
>>Attached are several patches. Four of them (patch-2.6.*-skas-v7-*)
>>implement PTRACE_SYSEMU_SINGLESTEP in the host. They are based on
>>linux-2.6.7-vanilla + host-skas3-2.6.7-v7.patch (resp. the 2.6.9 versions).
>>The "-reorganize" patches are a rework of the current patch without
>>changing the functionality. The "add-SYSEMU_SINGLESTEP" then implement the
>>new features. Please note: the differences between 2.6.7 and 2.6.9 are
>>dependent on the different handling of syscall singlestepping in the two
>>versions.
>>
>>To have UML using the new feature, there are two further patches named
>>patch-SYSEMU_SINGLESTEP-*. They are based on linux-2.6.9-vanilla +
>>all bb2-patches + patch-sysemu-tt + patch-fix-uml-hang-on-2.6.9-host.
>>To have all the patches complete, the latter two are attached also.
>>
>>I tested on host 2.6.7 and host 2.6.9 with SKAS and TT mode. Currently I
>>don't know any problem with it.
> 
> 
>>Bodo
> 
> 
>>BTW: Today I tried the first time since weeks to do a reboot in SKAS. It
>>simply exits UML, as it did weeks ago. Is there anybody involved with that
>>problem?
> 
> 
> It seems a bit randomical: on my system, it segfaults some times, after 
> checking for /proc/mm and SKAS mode.
> 
> When applying my use-va_end patch, (it's also in Jeff incrementals), instead, 
> it always gets this segfault.
> 
> If you look at the comment about exec(), it says that UML risks to get some 
> signals after the exec(). It workarounds this for some signals, but this 
> cannot be done anyway for SIGSEGV... actually SIGSEGV delivery happens to 
> always be synchronous, since the process gets trapped before the signal is 
> queued.
> 
> By comparison, all signals are normally asynchronous, i.e. they get queued and 
> later delivered, so that deliverying a signal is slower than doing a context 
> switch.
> 
> Quoting from signal(7) man page:
> 
> Multiple instances of real-time signals can be queued.  By contrast,  if  
> multiple instances of  a standard  signal  are  delivered  while  that signal 
> is currently blocked, then only one instance is queued.

What happens on my system shows some other symptoms. After "Restarting system."
UML exits without further message. I could track this down to a SIGIO being
unblocked immediately before the execvp(). It is handled by sig_handler()
that calls sig_handler_common_skas(). Why this exits, I don't know.
Maybe, SKAS misses an reset of the handlers to empty handlers.
Since I didn't want to dig very deep here, I choosed a simple solution.
I attached the patch. For me it works fine.
Feel free to find a better solution!

Bodo

[-- Attachment #2: patch-fix-reboot-skas --]
[-- Type: text/plain, Size: 2466 bytes --]

From: Bodo Stroesser <bstroesser@fujitsu-siemens.com>

In most cases reboot failed on my system. After
"Restarting system.", UML exited without further messages.
I found an SIGIO being processed by sig_handler() resp.
sig_handler_common_skas(). Don't know, why this exits,
maybe the context is no longer valid at this time.
So, I changed the sequence in the reboot part of main()
to stop the timers and disable the fds before unblocking
the signals. Since this wasn't enough, I also added
set_handler(SIGXXX, SIG_IGN) calls to disable_timer() and
deactivate_all_fds().
Now reboot works fine in SKAS and it still works in TT.

Signed-off-by: Bodo Stroesser <bstroesser@fujitsu-siemens.com>
---

--- a/arch/um/kernel/main.c	2004-11-15 17:19:42.437975368 +0100
+++ b/arch/um/kernel/main.c	2004-11-15 17:35:34.901178952 +0100
@@ -157,18 +157,20 @@ int main(int argc, char **argv, char **e
 		int err;
 
 		printf("\n");
-
-		/* Let any pending signals fire, then disable them.  This
-		 * ensures that they won't be delivered after the exec, when
-		 * they are definitely not expected.
-		 */
-		unblock_signals();
+		/* stop timers and set SIG*ALRM to be ignored */
 		disable_timer();
+		/* disable SIGIO for the fds and set SIGIO to be ignored */
 		err = deactivate_all_fds();
 		if(err)
 			printf("deactivate_all_fds failed, errno = %d\n",
 			       -err);
 
+		/* Let any pending signals fire now.  This ensures
+		 * that they won't be delivered after the exec, when
+		 * they are definitely not expected.
+		 */
+		unblock_signals();
+
 		execvp(new_argv[0], new_argv);
 		perror("Failed to exec kernel");
 		ret = 1;
--- a/arch/um/kernel/time.c	2004-10-18 23:53:43.000000000 +0200
+++ b/arch/um/kernel/time.c	2004-11-15 17:32:41.057607192 +0100
@@ -60,6 +60,9 @@ void disable_timer(void)
 	   (setitimer(ITIMER_REAL, &disable, NULL) < 0))
 		printk("disnable_timer - setitimer failed, errno = %d\n",
 		       errno);
+	/* If there are signals already queued, after unblocking ignore them */
+	set_handler(SIGALRM, SIG_IGN, 0, -1);
+	set_handler(SIGVTALRM, SIG_IGN, 0, -1);
 }
 
 void switch_timers(int to_real)
--- a/arch/um/kernel/irq_user.c	2004-10-18 23:53:51.000000000 +0200
+++ b/arch/um/kernel/irq_user.c	2004-11-15 17:33:40.893510752 +0100
@@ -374,6 +374,8 @@ int deactivate_all_fds(void)
 		if(err)
 			return(err);
 	}
+	/* If there is a signal already queued, after unblocking ignore it */
+	set_handler(SIGIO, SIG_IGN, 0, -1);
 
 	return(0);
 }

  reply	other threads:[~2004-11-15 17:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-12 20:05 [uml-devel] Patchset to implement PTRACE_SYSEMU_SINGLESTEP Bodo Stroesser
2004-11-12 23:43 ` Blaisorblade
2004-11-15 17:11   ` Bodo Stroesser [this message]
2004-11-18  6:47     ` Jeff Dike
2004-11-18 14:19       ` Bodo Stroesser
2004-11-18 14:41         ` Blaisorblade
2004-11-18 16:01           ` Bodo Stroesser
2004-12-06 20:33 ` Blaisorblade
2004-12-07 14:21   ` Bodo Stroesser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4198E349.5070809@fujitsu-siemens.com \
    --to=bstroesser@fujitsu-siemens.com \
    --cc=blaisorblade_spam@yahoo.it \
    --cc=jdike@addtoit.com \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox