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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:	Mon, 1 Feb 2016 17:06:21 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Heiko Carstens <heiko.carstens@...ibm.com>
Subject: [GIT PULL] tracing/stacktrace: Show entire trace if passed in
 function not found


Linus,

A cleanup to the stack tracer broke stack tracing on s390.
Here's a simple fix to correct that issue.


Please pull the latest trace-v4.5-rc1-2 tree, which can be found at:


  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
trace-v4.5-rc1-2

Tag SHA1: a452e1d1572d2ea305c8fe7b85365a1c5a1de40d
Head SHA1: 6ccd83714a009ee301b50c15f6c3a5dc1f30164c


Steven Rostedt (1):
      tracing/stacktrace: Show entire trace if passed in function not found

----
 kernel/trace/trace_stack.c | 7 +++++++
 1 file changed, 7 insertions(+)
---------------------------
commit 6ccd83714a009ee301b50c15f6c3a5dc1f30164c
Author: Steven Rostedt <rostedt@...dmis.org>
Date:   Fri Jan 29 10:22:41 2016 -0500

    tracing/stacktrace: Show entire trace if passed in function not found
    
    When a max stack trace is discovered, the stack dump is saved. In order to
    not record the overhead of the stack tracer, the ip of the traced function
    is looked for within the dump. The trace is started from the location of
    that function. But if for some reason the ip is not found, the entire stack
    trace is then truncated. That's not very useful. Instead, print everything
    if the ip of the traced function is not found within the trace.
    
    This issue showed up on s390.
    
    Link: http://lkml.kernel.org/r/20160129102241.1b3c9c04@gandalf.local.home
    
    Fixes: 72ac426a5bb0 ("tracing: Clean up stack tracing and fix fentry updates")
    Cc: stable@...r.kernel.org # v4.3+
    Reported-by: Heiko Carstens <heiko.carstens@...ibm.com>
    Tested-by: Heiko Carstens <heiko.carstens@...ibm.com>
    Signed-off-by: Steven Rostedt <rostedt@...dmis.org>

diff --git a/kernel/trace/trace_stack.c b/kernel/trace/trace_stack.c
index dda9e6742950..202df6cffcca 100644
--- a/kernel/trace/trace_stack.c
+++ b/kernel/trace/trace_stack.c
@@ -126,6 +126,13 @@ check_stack(unsigned long ip, unsigned long *stack)
 	}
 
 	/*
+	 * Some archs may not have the passed in ip in the dump.
+	 * If that happens, we need to show everything.
+	 */
+	if (i == stack_trace_max.nr_entries)
+		i = 0;
+
+	/*
 	 * Now find where in the stack these are.
 	 */
 	x = 0;

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ