lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 2 Aug 2016 22:30:11 -0400 From: Steven Rostedt <rostedt@...dmis.org> To: Josh Poimboeuf <jpoimboe@...hat.com> Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...nel.org>, "H . Peter Anvin" <hpa@...or.com>, x86@...nel.org, linux-kernel@...r.kernel.org, Andy Lutomirski <luto@...capital.net>, Linus Torvalds <torvalds@...ux-foundation.org>, Brian Gerst <brgerst@...il.com>, Kees Cook <keescook@...omium.org>, Peter Zijlstra <peterz@...radead.org>, Frederic Weisbecker <fweisbec@...il.com>, Byungchul Park <byungchul.park@....com> Subject: Re: [PATCH 05/19] x86/dumpstack: fix function graph tracing stack dump reliability issues On Tue, 2 Aug 2016 20:56:56 -0500 Josh Poimboeuf <jpoimboe@...hat.com> wrote: > It's not specific to NMIs. The problem is that dump_trace() is starting > from the frame pointed to by a pt_regs, rather than the current frame. > Instead of starting with the current frame, the first 10 functions on > the stack are skipped by the unwinder, but they're *not* skipped on the > ret_stack. So it starts out out-of-sync. OK, I see what you mean. If we do a dumpstack from interrupt passing in the pt_regs of the kernel thread that was interrupted, even though functions up to the interrupt was called and traced, which will show up in the dump stack that shouldn't. OK, you convinced me. Add the extra pointer, then we will have 4 longs and 2 long longs in ftrace_ret_stack. That's not that bad. -- Steve
Powered by blists - more mailing lists