linux-kernel - Re: [PATCH v3] tracing: kdb: Allow ftdump to skip all but the last few lines

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

Date:   Fri, 15 Mar 2019 17:33:35 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Doug Anderson <dianders@...omium.org>
Cc:     Ingo Molnar <mingo@...hat.com>,
        Jason Wessel <jason.wessel@...driver.com>,
        Daniel Thompson <daniel.thompson@...aro.org>,
        kgdb-bugreport@...ts.sourceforge.net,
        Brian Norris <briannorris@...omium.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3] tracing: kdb: Allow ftdump to skip all but the last
 few lines

On Fri, 15 Mar 2019 14:28:39 -0700
Doug Anderson <dianders@...omium.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