From: Oleg Nesterov <oleg@redhat.com>
To: Davide Libenzi <davidel@xmailserver.org>,
Ingo Molnar <mingo@elte.hu>,
Linus Torvalds <torvalds@linux-foundation.org>,
Roland McGrath <roland@redhat.com>
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
"Chris Friesen" <cfriesen@nortel.com>,
"Gábor Melis" <mega@retes.hu>,
linux-kernel@vger.kernel.org
Subject: Q: SEGSEGV && uc_mcontext->ip (Was: Signal delivery order)
Date: Tue, 17 Mar 2009 05:13:37 +0100 [thread overview]
Message-ID: <20090317041337.GA29740@redhat.com> (raw)
In-Reply-To: <49BED93B.1090700@nortel.com>
(see http://marc.info/?t=123704955800002)
First of all, perhaps I missed somethings and this is solvable without
kernel changes, but I can't see how.
To simplify, suppose that the application wants to log the faulting
instruction before exit, so it installs the handler for SIGSEGV
void sigsegv_handler(int sig, siginfo_t *info, struct ucontext *context)
{
fprintf(stderr, "bug at %p\n", context->uc_mcontext->ip);
exit(1);
}
But this doesn't work. It is possible that, before the task dequeues SIGSEGV,
another private signal, say, SIGHUP (note that SIGHUP < SIGSEGV) is sent to
this app.
In this case the task dequeues both signals, SIGHUP and then SIGSEGV before
return to user-space. This is correct, but now uc_mcontext->ip points to
sighup_handler, not to the faulted instruction.
Can/should we change force_sig_info_fault() to help?
We can add siginfo_t->_sigfault.ip to solve this problem. This shouldn't
enlarge the size of siginfo_t. With this change sigsegv_handler() always
knows the address of the instruction which caused the fault.
But this doesn't allow to change uc_mcontext->ip to, say, skip the offending
instruction or call another function which does a fixup. Actually, ->si_ip
helps, we can do
void sigsegv_handler(int sig, siginfo_t *info, struct ucontext *context)
{
if (info->si_ip != context->uc_mcontext->ip)
/*
* The offending instruction will be repeated, and
* we will have the "same" SIGSEGV again.
*/
return;
context->uc_mcontext->ip = fixup;
...
}
But this doesn't look very nice. So, perhaps we can do another change?
--- arch/x86/mm/fault.c
+++ arch/x86/mm/fault.c
@@ -177,6 +177,13 @@ static void force_sig_info_fault(int si_
{
siginfo_t info;
+ current->saved_sigmask = current->blocked;
+ spin_lock_irq(¤t->sighand->siglock);
+ siginitsetinv(¤t->blocked, sigmask(si_signo) |
+ sigmask(SIGKILL) | sigmask(SIGSTOP));
+ spin_unlock_irq(¤t->sighand->siglock);
+ set_restore_sigmask();
+
info.si_signo = si_signo;
info.si_errno = 0;
info.si_code = si_code;
But this is a user-visible change, all signals will be blocked until
sigsegv_handler() returns. But with this change sigsegv_handler()
always has the "correct" rt_sigframe.
Comments?
And once again, I have a nasty feeling I missed something and we don't
need to change the kernel.
Oleg.
next prev parent reply other threads:[~2009-03-17 4:18 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-14 16:50 Signal delivery order Gábor Melis
2009-03-15 9:44 ` Oleg Nesterov
2009-03-15 14:40 ` Gábor Melis
2009-03-15 17:29 ` Oleg Nesterov
2009-03-15 22:06 ` Gábor Melis
2009-03-16 0:28 ` Oleg Nesterov
2009-03-16 8:34 ` Gábor Melis
2009-03-16 21:13 ` Oleg Nesterov
2009-03-16 22:56 ` Chris Friesen
2009-03-17 4:13 ` Oleg Nesterov [this message]
2009-03-17 4:25 ` Q: SEGSEGV && uc_mcontext->ip (Was: Signal delivery order) Oleg Nesterov
2009-03-17 8:23 ` Gábor Melis
2009-03-17 9:25 ` Oleg Nesterov
2009-03-17 10:20 ` Gábor Melis
2009-03-17 10:43 ` Oleg Nesterov
2009-03-17 15:56 ` Linus Torvalds
2009-03-17 19:20 ` Q: SEGSEGV && uc_mcontext->ip David Miller
2009-03-18 9:58 ` Q: SEGSEGV && uc_mcontext->ip (Was: Signal delivery order) Gábor Melis
2009-03-18 7:59 ` Roland McGrath
2009-03-18 9:02 ` RT signal queue overflow (Was: Q: SEGSEGV && uc_mcontext->ip (Was: Signal delivery order)) Gábor Melis
2009-03-18 14:52 ` Linus Torvalds
2009-03-18 15:23 ` Gábor Melis
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=20090317041337.GA29740@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=cfriesen@nortel.com \
--cc=davidel@xmailserver.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mega@retes.hu \
--cc=mingo@elte.hu \
--cc=roland@redhat.com \
--cc=torvalds@linux-foundation.org \
/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.