linux-kernel - [GIT PULL] tracing: Fix user stack trace "??" output

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>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190719121813.4b113efd@gandalf.local.home>
Date:   Fri, 19 Jul 2019 12:18:13 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Eiichi Tsukata <devel@...ukata.com>
Subject: [GIT PULL] tracing: Fix user stack trace "??" output


Linus,

Eiichi Tsukata found a small bug from the fixup of the stack code

Removing ULONG_MAX as the marker for the user stack trace end
made the tracing code not know where the end is. The end is now
marked with a zero (NULL) pointer. Eiichi fixed this in the tracing
code.


Please pull the latest trace-v5.3-2 tree, which can be found at:


  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
trace-v5.3-2

Tag SHA1: f46c69b1df70d80025590e7780ce0d7572698ad6
Head SHA1: 6d54ceb539aacc3df65c89500e8b045924f3ef81


Eiichi Tsukata (1):
      tracing: Fix user stack trace "??" output

----
 kernel/trace/trace_output.c | 9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)
---------------------------
commit 6d54ceb539aacc3df65c89500e8b045924f3ef81
Author: Eiichi Tsukata <devel@...ukata.com>
Date:   Sun Jun 30 17:54:38 2019 +0900

    tracing: Fix user stack trace "??" output
    
    Commit c5c27a0a5838 ("x86/stacktrace: Remove the pointless ULONG_MAX
    marker") removes ULONG_MAX marker from user stack trace entries but
    trace_user_stack_print() still uses the marker and it outputs unnecessary
    "??".
    
    For example:
    
                less-1911  [001] d..2    34.758944: <user stack trace>
       =>  <00007f16f2295910>
       => ??
       => ??
       => ??
       => ??
       => ??
       => ??
       => ??
    
    The user stack trace code zeroes the storage before saving the stack, so if
    the trace is shorter than the maximum number of entries it can terminate
    the print loop if a zero entry is detected.
    
    Link: http://lkml.kernel.org/r/20190630085438.25545-1-devel@etsukata.com
    
    Cc: stable@...r.kernel.org
    Fixes: 4285f2fcef80 ("tracing: Remove the ULONG_MAX stack trace hackery")
    Signed-off-by: Eiichi Tsukata <devel@...ukata.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@...dmis.org>

diff --git a/kernel/trace/trace_output.c b/kernel/trace/trace_output.c
index 54373d93e251..1d6178a188f4 100644
--- a/kernel/trace/trace_output.c
+++ b/kernel/trace/trace_output.c
@@ -1109,17 +1109,10 @@ static enum print_line_t trace_user_stack_print(struct trace_iterator *iter,
 	for (i = 0; i < FTRACE_STACK_ENTRIES; i++) {
 		unsigned long ip = field->caller[i];
 
-		if (ip == ULONG_MAX || trace_seq_has_overflowed(s))
+		if (!ip || trace_seq_has_overflowed(s))
 			break;
 
 		trace_seq_puts(s, " => ");
-
-		if (!ip) {
-			trace_seq_puts(s, "??");
-			trace_seq_putc(s, '\n');
-			continue;
-		}
-
 		seq_print_user_ip(s, mm, ip, flags);
 		trace_seq_putc(s, '\n');
 	}