From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
Eiichi Tsukata <devel@etsukata.com>,
edwintorok@gmail.com, mingo@redhat.com, bp@alien8.de,
hpa@zytor.com, x86@kernel.org, linux-kernel@vger.kernel.org,
Josh Poimboeuf <jpoimboe@redhat.com>,
Joel Fernandes <joel@joelfernandes.org>
Subject: Re: [PATCH] x86/stacktrace: Do not access user space memory unnecessarily
Date: Fri, 19 Jul 2019 13:28:36 -0700 [thread overview]
Message-ID: <20190719202836.GB13680@linux.intel.com> (raw)
In-Reply-To: <20190702133905.1482b87e@gandalf.local.home>
On Tue, Jul 02, 2019 at 01:39:05PM -0400, Steven Rostedt wrote:
> On Tue, 2 Jul 2019 11:33:55 -0400
> Steven Rostedt <rostedt@goodmis.org> wrote:
>
> > On Tue, 2 Jul 2019 16:14:05 +0200 (CEST)
> > Thomas Gleixner <tglx@linutronix.de> wrote:
> >
> > > On Tue, 2 Jul 2019, Peter Zijlstra wrote:
> > >
> > > > On Tue, Jul 02, 2019 at 02:31:51PM +0900, Eiichi Tsukata wrote:
> > > > > Put the boundary check before it accesses user space to prevent unnecessary
> > > > > access which might crash the machine.
> > > > >
> > > > > Especially, ftrace preemptirq/irq_disable event with user stack trace
> > > > > option can trigger SEGV in pid 1 which leads to panic.
> >
> > Note, I'm only able to trigger this crash with the irq_disable event.
> > The irq_enable and preempt_disable/enable events work just fine. This
> > leads me to believe that the TRACE_IRQS_OFF macro (which uses a thunk
> > trampoline) may have some issues and is probably the place to look at.
>
> I figured it out.
>
> It's another "corruption of the cr2" register issue. The following
> patch makes the issue go away. I'm not suggesting that we use this
> patch, but it shows where the bug lies.
>
> IIRC, there was patches posted before that fixed this issue. I'll go
> look to see if I can dig them up. Was it Joel that sent them?
>
> -- Steve
>
> diff --git a/arch/x86/entry/thunk_64.S b/arch/x86/entry/thunk_64.S
> index be36bf4e0957..dd79256badb2 100644
> --- a/arch/x86/entry/thunk_64.S
> +++ b/arch/x86/entry/thunk_64.S
> @@ -40,7 +40,7 @@
>
> #ifdef CONFIG_TRACE_IRQFLAGS
> THUNK trace_hardirqs_on_thunk,trace_hardirqs_on_caller,1
> - THUNK trace_hardirqs_off_thunk,trace_hardirqs_off_caller,1
> + THUNK trace_hardirqs_off_thunk,trace_hardirqs_off_caller_cr2,1
> #endif
>
> #ifdef CONFIG_DEBUG_LOCK_ALLOC
> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> index 46df4c6aae46..b42ca3fc569d 100644
> --- a/arch/x86/mm/fault.c
> +++ b/arch/x86/mm/fault.c
> @@ -1555,3 +1555,13 @@ do_page_fault(struct pt_regs *regs, unsigned long error_code)
> exception_exit(prev_state);
> }
> NOKPROBE_SYMBOL(do_page_fault);
> +
> +void trace_hardirqs_off_caller(unsigned long addr);
> +
> +void notrace trace_hardirqs_off_caller_cr2(unsigned long addr)
> +{
> + unsigned long address = read_cr2(); /* Get the faulting address */
> +
> + trace_hardirqs_off_caller(addr);
> + write_cr2(address);
> +}
I'm hitting a similar panic that bisects to commit
a0d14b8909de ("x86/mm, tracing: Fix CR2 corruption")
except I'm experiencing death immediately after starting init.
Through sheer dumb luck, I tracked (pun intended) this down to forcing
context tracking:
CONFIG_CONTEXT_TRACKING=y
CONFIG_CONTEXT_TRACKING_FORCE=y
CONFIG_VIRT_CPU_ACCOUNTING_GEN=y
I haven't attempted to debug further and I'll be offline for most of the
next few days. Hopefully this is enough to root cause the badness.
[ 0.680477] Run /sbin/init as init process
[ 0.682116] init[1]: segfault at 2926a7ef ip 00007f98a49d9c30 sp 00007fffd83e6af0 error 14 in ld-2.23.so[7f98a49d9000+26000]
[ 0.683427] Code: Bad RIP value.
[ 0.683844] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 0.684710] CPU: 0 PID: 1 Comm: init Not tainted 5.2.0+ #18
[ 0.685352] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
[ 0.686239] Call Trace:
[ 0.686542] dump_stack+0x46/0x5b
[ 0.686915] panic+0xf8/0x2d2
[ 0.687252] do_exit+0xb68/0xb70
[ 0.687616] do_group_exit+0x3a/0xa0
[ 0.688088] get_signal+0x184/0x880
[ 0.688483] do_signal+0x30/0x690
[ 0.688857] ? signal_wake_up_state+0x15/0x30
[ 0.689433] ? __send_signal+0x139/0x380
[ 0.689908] exit_to_usermode_loop+0x6a/0xc0
[ 0.690397] ? async_page_fault+0x8/0x40
[ 0.690850] prepare_exit_to_usermode+0x78/0xb0
[ 0.691355] retint_user+0x8/0x8
[ 0.691722] RIP: 0033:0x7f98a49d9c30
[ 0.692122] Code: Bad RIP value.
[ 0.692484] RSP: 002b:00007fffd83e6af0 EFLAGS: 00010202
[ 0.693060] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[ 0.693907] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[ 0.694739] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
[ 0.695538] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
[ 0.696322] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 0.697195] Kernel Offset: disabled
[ 0.697600] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
next prev parent reply other threads:[~2019-07-19 20:28 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-02 5:31 [PATCH] x86/stacktrace: Do not access user space memory unnecessarily Eiichi Tsukata
2019-07-02 7:28 ` Peter Zijlstra
2019-07-02 14:14 ` Thomas Gleixner
2019-07-02 15:33 ` Steven Rostedt
2019-07-02 17:39 ` Steven Rostedt
2019-07-02 17:47 ` Steven Rostedt
2019-07-02 20:18 ` Peter Zijlstra
2019-07-02 20:33 ` Steven Rostedt
2019-07-02 22:02 ` Peter Zijlstra
2019-07-19 20:28 ` Sean Christopherson [this message]
2019-07-19 22:23 ` Thomas Gleixner
2019-07-19 23:01 ` Thomas Gleixner
2019-07-20 8:44 ` Thomas Gleixner
2019-07-20 8:56 ` [PATCH] x86/entry/64: Prevent clobbering of saved CR2 value Thomas Gleixner
2019-07-20 11:20 ` Peter Zijlstra
2019-07-20 12:34 ` [tip:x86/urgent] " tip-bot for Thomas Gleixner
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=20190719202836.GB13680@linux.intel.com \
--to=sean.j.christopherson@intel.com \
--cc=bp@alien8.de \
--cc=devel@etsukata.com \
--cc=edwintorok@gmail.com \
--cc=hpa@zytor.com \
--cc=joel@joelfernandes.org \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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.