On Fri, 15 Mar 2019 14:28:39 -0700
Doug Anderson <diand...@chromium.org> wrote:
> I had a little bit of a hard time figuring out if print_trace_line()
> plus trace_printk_seq() always printed one line or always printed one
> entry. I guess the point I was making was that in v1 of my patch it
> wouldn't matter because the pseudo code looked like:
>
> 1. Count how many "things" would be printed, but don't printed them.
>
> 2. Use math to figure out how many "things" to skip given that we want
> to print the last N "things".
>
> 3. Skip the "things" the math told us to and then print the last N "things".
>
> ...but it sounds like it _must_ print one entry because we're looping
> over trace_find_next_entry_inc(). That means that the existing "skip
> lines" that predates my patch should actually be "skip entries". I'd
> be happy adjusting the help text (and local variable name) so that
> "skip_lines" is instead "skip_entries". I think that would avoid
> confusion everywhere. It doesn't change behavior but just documents
> the existing behavior.
Sounds like a plan.
>
>
> With that I can use your optimized path assuming you can confirm that
> "tr->trace_flags &= ~TRACE_ITER_SYM_USEROBJ" doesn't affect how many
> entries will be iterated over by trace_find_next_entry_inc().
Here's the code:
trace_seq_puts(s, "<user stack trace>\n"); <=== already prints a line
regardless of SYM_USEROBJ.
if (tr->trace_flags & TRACE_ITER_SYM_USEROBJ) {
struct task_struct *task;
/*
* we do the lookup on the thread group leader,
* since individual threads might have already quit!
*/
rcu_read_lock();
task = find_task_by_vpid(field->tgid);
if (task)
mm = get_task_mm(task);
rcu_read_unlock();
}
-- Steve
_______________________________________________
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
