From: Jeff Dike <jdike@addtoit.com>
To: "Stroesser, Bodo" <Bodo.Stroesser@fujitsu-siemens.com>
Cc: user-mode-linux-devel@lists.sourceforge.net,
BlaisorBlade <blaisorblade_spam@yahoo.it>
Subject: Re: [uml-devel] Signal handling: signal mask incorrect after segfault
Date: Thu, 30 Sep 2004 22:30:12 -0400 [thread overview]
Message-ID: <200410010230.i912UCqR004674@ccure.user-mode-linux.org> (raw)
In-Reply-To: Your message of "Thu, 30 Sep 2004 16:31:37 +0200." <8B6FF516CBA0194AB0996705076B02520F7C3E@ABGEX01E.abg.fsc.net>
Bodo.Stroesser@fujitsu-siemens.com said:
> If the user stack limit is reached or the signal stack assigned with
> sigaltstack() is invalid when a user signal handler with SA_ONSTACK
> has to be started, the signal mask of the interrupted user program is
> modified. This happens because the mask, that should be used with the
> handler only, is written to "current->blocked" even if the handler
> could not be started. But without a handler, no rewrite of the
> original mask at sys_sigreturn will be done.
I don't see where current->blocked is modified up to that point. It looks
like this could be fixed by checking err in the !SA_DEFER case:
if (!err && !(ka->sa.sa_flags & SA_NODEFER)) {
> A slightly different case
> is sys_sigsuspend(), where the mask is already modified when
> kern_do_signal() is started. "*oldset" and "current->blocked" are not
> equal here and thus current->blocked has to be set to *oldset, if an
> error occurs in handle_signal(). For both cases I've written small
> tests, and with the patch the result is OK.
The existing code looks OK to me. If there's an error writing the signal
frame, then it will get a SIGSEGV. If that is caught (and somehow succeeds,
like it's going to a good stack), and it returns, then that's where your
sigreturn and mask restoration is going to happen.
If none of the above happen, then the process is dead meat, of course.
Jeff
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
next prev parent reply other threads:[~2004-10-01 1:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-30 14:31 [uml-devel] Signal handling: signal mask incorrect after segfault Stroesser, Bodo
2004-10-01 2:30 ` Jeff Dike [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-10-01 9:53 Stroesser, Bodo
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=200410010230.i912UCqR004674@ccure.user-mode-linux.org \
--to=jdike@addtoit.com \
--cc=Bodo.Stroesser@fujitsu-siemens.com \
--cc=blaisorblade_spam@yahoo.it \
--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