All of lore.kernel.org
 help / color / mirror / Atom feed
From: Waiman Long <waiman.long@hp.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Andy Lutomirski <luto@amacapital.net>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Aswin Chandramouleeswaran <aswin@hp.com>,
	Scott J Norton <scott.norton@hp.com>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: SIGSEGV when using "perf record -g" with 3.13-rc* kernel
Date: Wed, 15 Jan 2014 10:33:12 -0500	[thread overview]
Message-ID: <52D6AA38.2040606@hp.com> (raw)
In-Reply-To: <20140110200603.GJ7572@laptop.programming.kicks-ass.net>

On 01/10/2014 03:06 PM, Peter Zijlstra wrote:
>
> :-)
>
> Something like this perhaps?
>
> ---
> Subject: x86, mm: Allow double faults from interrupts
>
> Waiman managed to trigger a PMI while in a emulate_vsyscall() fault, the
> PMI in turn managed to trigger a fault while obtaining a stack trace.
> This triggered the double fault logic and killed the process dead.
>
> Fix this by explicitly excluding interrupts from the double fault logic.
>
> Reported-by: Waiman Long<waiman.long@hp.com>
> Signed-off-by: Peter Zijlstra<peterz@infradead.org>
> ---
>   arch/x86/mm/fault.c | 18 ++++++++++++++++++
>   1 file changed, 18 insertions(+)
>
> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> index 9ff85bb8dd69..4c8e32986aad 100644
> --- a/arch/x86/mm/fault.c
> +++ b/arch/x86/mm/fault.c
> @@ -641,6 +641,20 @@ no_context(struct pt_regs *regs, unsigned long error_code,
>
>   	/* Are we prepared to handle this kernel fault? */
>   	if (fixup_exception(regs)) {
> +		/*
> +		 * Any interrupt that takes a fault gets the fixup. This
> +		 * makes the below double fault logic only apply to a
> +		 * task double faulting from task context.
> +		 */
> +		if (in_interrupt())
> +			return;
> +
> +		/*
> +		 * Per the above we're !in_interrupt(), aka. task context.
> +		 *
> +		 * In this case we need to make sure we're not double faulting
> +		 * through the emulate_vsyscall() logic.
> +		 */
>   		if (current_thread_info()->sig_on_uaccess_error&&  signal) {
>   			tsk->thread.trap_nr = X86_TRAP_PF;
>   			tsk->thread.error_code = error_code | PF_USER;
> @@ -649,6 +663,10 @@ no_context(struct pt_regs *regs, unsigned long error_code,
>   			/* XXX: hwpoison faults will set the wrong code. */
>   			force_sig_info_fault(signal, si_code, address, tsk, 0);
>   		}
> +
> +		/*
> +		 * Barring that, we can do the fixup and be happy.
> +		 */
>   		return;
>   	}
>

Are you going to send out an official patch to fix this problem? I 
really like to see it merged into 3.13 before it is released.

-Longman

  parent reply	other threads:[~2014-01-15 15:33 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-10 15:29 SIGSEGV when using "perf record -g" with 3.13-rc* kernel Waiman Long
2014-01-10 16:58 ` Peter Zijlstra
2014-01-10 17:02   ` Peter Zijlstra
2014-01-10 17:41     ` Peter Zijlstra
2014-01-10 18:54       ` Andy Lutomirski
2014-01-10 19:43         ` Waiman Long
2014-01-10 19:56           ` Andy Lutomirski
2014-01-10 20:12             ` Peter Zijlstra
2014-01-10 20:06         ` Peter Zijlstra
2014-01-10 20:28           ` Andy Lutomirski
2014-01-15 15:33           ` Waiman Long [this message]
2014-01-16 13:39           ` [tip:perf/core] x86, mm, perf: Allow recursive faults from interrupts tip-bot for Peter Zijlstra
2014-01-17 18:10             ` Waiman Long
2014-01-17 19:17               ` Andy Lutomirski
2014-01-17 20:08                 ` Waiman Long
2014-01-17 21:07                   ` Andy Lutomirski
2014-01-10 19:37     ` SIGSEGV when using "perf record -g" with 3.13-rc* kernel Waiman Long
2014-01-10 20:10       ` Peter Zijlstra

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=52D6AA38.2040606@hp.com \
    --to=waiman.long@hp.com \
    --cc=acme@ghostprotocols.net \
    --cc=aswin@hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=scott.norton@hp.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.