| Date | Wed, 10 Apr 2019 21:34:25 -0500 | From | Josh Poimboeuf <> | Subject | Re: [RFC patch 16/41] tracing: Remove the ULONG_MAX stack trace hackery |
| |
On Wed, Apr 10, 2019 at 12:28:10PM +0200, Thomas Gleixner wrote: > No architecture terminates the stack trace with ULONG_MAX anymore. As the > code checks the number of entries stored anyway there is no point in > keeping all that ULONG_MAX magic around. > > The histogram 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. > > Signed-off-by: Thomas Gleixner <tglx@linutronix.de> > Cc: Steven Rostedt <rostedt@goodmis.org> > --- > kernel/trace/trace_events_hist.c | 2 +- > kernel/trace/trace_stack.c | 20 +++++--------------- > 2 files changed, 6 insertions(+), 16 deletions(-) > > --- a/kernel/trace/trace_events_hist.c > +++ b/kernel/trace/trace_events_hist.c > @@ -5246,7 +5246,7 @@ static void hist_trigger_stacktrace_prin > unsigned int i; > > for (i = 0; i < max_entries; i++) { > - if (stacktrace_entries[i] == ULONG_MAX) > + if (!stacktrace_entries[i]) > return; > > seq_printf(m, "%*c", 1 + spaces, ' '); > --- a/kernel/trace/trace_stack.c > +++ b/kernel/trace/trace_stack.c > @@ -18,8 +18,7 @@ > > #include "trace.h" > > -static unsigned long stack_dump_trace[STACK_TRACE_ENTRIES+1] = > - { [0 ... (STACK_TRACE_ENTRIES)] = ULONG_MAX }; > +static unsigned long stack_dump_trace[STACK_TRACE_ENTRIES + 1];
Is the "+ 1" still needed? AFAICT, accesses to this array never go past nr_entries.
Also I've been staring at the code but I can't figure out why max_entries is "- 1".
struct stack_trace stack_trace_max = { .max_entries = STACK_TRACE_ENTRIES - 1, .entries = &stack_dump_trace[0], };
-- Josh
|