linux-kernel - Re: [RFC PATCH 28/30 v3] Generic command line storage

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:	Tue, 15 Jan 2008 17:15:02 -0500 (EST)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
cc:	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Christoph Hellwig <hch@...radead.org>,
	Gregory Haskins <ghaskins@...ell.com>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	Tim Bird <tim.bird@...sony.com>,
	Sam Ravnborg <sam@...nborg.org>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	Jan Kiszka <jan.kiszka@...mens.com>,
	Steven Rostedt <srostedt@...hat.com>
Subject: Re: [RFC PATCH 28/30 v3] Generic command line storage


On Tue, 15 Jan 2008, Mathieu Desnoyers wrote:

> * Steven Rostedt (rostedt@...dmis.org) wrote:
> > Saving the comm of tasks for each trace is very expensive.
> > This patch includes in the context switch hook, a way to
> > store the last 100 command lines of tasks. This table is
> > examined when a trace is to be printed.
> >
>
> Instead of saving the comm at context switch, could we save them when a
> process exits ? (actually, if we want to do this right, we would also
> have to trace the changes of "comm" upon exec(), so we deal correctly
> with processes that do multiple execs).
>
> This way, we would not duplicate the comm of processes still active in
> the system, and would trigger on a much lower event-rate trace point.
>
> And the idea would be to save only the comm of processes present in your
> summary (top X processes); why do you save the last 100 ? (if the system
> has more than 100 active tasks, this code will always be executed, which
> seems bad)

100 was just an arbitrary number that seems to be fine in my current
tests. But yes, a function trace over a thousand tasks will clean them
out. But the recording is only done when a trace is active.

>
> Also, if we do as I propose, we would have to keep process exit/exec
> tracing active until the summary is cleared, even though the rest of
> "high event rate" tracing could be stopped sooner.

One thing I planned on doing was at a low path point (hit max latency to
record, etc) we could copy the array into the trace buffer, so the info
stays with the trace.

Going with your approach (marker at exit), I could flush the traces that
were saved, as well as the comms of the current tasks that are still
running. The thing is, this all starts to get a bit intrusive into the
rest of the kernel.  What is suppose to be a compact latency tracer,
starts to become larger, problematic, entity. Now changes in exit could
require updates to the tracer. Which is something I want to avoid.

-- Steve

--
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/