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);
}
next prev parent 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