All of lore.kernel.org
 help / color / mirror / Atom feed
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(&current->sighand->siglock);
	+	siginitsetinv(&current->blocked, sigmask(si_signo) |
	+			sigmask(SIGKILL) | sigmask(SIGSTOP));
	+	spin_unlock_irq(&current->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.


  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.