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]
Date:	Tue, 27 Mar 2012 13:25:21 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	LKML <linux-kernel@...r.kernel.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	stable@...r.kernel.org
Subject: [PATCH][GIT PULL][v3.4] tracing: Fix ent_size in trace output


Ingo,

Please pull the latest tip/perf/urgent tree, which can be found at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
tip/perf/urgent

Head SHA1: 12b5da349a8b94c9dbc3430a6bc42eabd9eaf50b


Steven Rostedt (1):
      tracing: Fix ent_size in trace output

----
 kernel/trace/trace.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)
---------------------------
commit 12b5da349a8b94c9dbc3430a6bc42eabd9eaf50b
Author: Steven Rostedt <srostedt@...hat.com>
Date:   Tue Mar 27 10:43:28 2012 -0400

    tracing: Fix ent_size in trace output
    
    When reading the trace file, the records of each of the per_cpu buffers
    are examined to find the next event to print out. At the point of looking
    at the event, the size of the event is recorded. But if the first event is
    chosen, the other events in the other CPU buffers will reset the event size
    that is stored in the iterator descriptor, causing the event size passed to
    the output functions to be incorrect.
    
    In most cases this is not a problem, but for the case of stack traces, it
    is. With the change to the stack tracing to record a dynamic number of
    back traces, the output depends on the size of the entry instead of the
    fixed 8 back traces. When the entry size is not correct, the back traces
    would not be fully printed.
    
    Note, reading from the per-cpu trace files were not affected.
    
    Reported-by: Thomas Gleixner <tglx@...utronix.de>
    Tested-by: Thomas Gleixner <tglx@...utronix.de>
    Cc: stable@...r.kernel.org
    Signed-off-by: Steven Rostedt <rostedt@...dmis.org>

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 3a19c35..ed7b5d1 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -1698,6 +1698,7 @@ __find_next_entry(struct trace_iterator *iter, int *ent_cpu,
 	int cpu_file = iter->cpu_file;
 	u64 next_ts = 0, ts;
 	int next_cpu = -1;
+	int next_size = 0;
 	int cpu;
 
 	/*
@@ -1729,9 +1730,12 @@ __find_next_entry(struct trace_iterator *iter, int *ent_cpu,
 			next_cpu = cpu;
 			next_ts = ts;
 			next_lost = lost_events;
+			next_size = iter->ent_size;
 		}
 	}
 
+	iter->ent_size = next_size;
+
 	if (ent_cpu)
 		*ent_cpu = next_cpu;
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ