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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.