linux-kernel - Re: [PATCH] tracing: Export key trace event symbols

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

Date:	Wed, 22 Apr 2015 08:53:14 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Ron Rechenmacher <ron@...l.gov>
Cc:	Christoph Hellwig <hch@...radead.org>,
	<linux-kernel@...r.kernel.org>,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Namhyung Kim <namhyung@...nel.org>
Subject: Re: [PATCH] tracing: Export key trace event symbols

On Tue, 21 Apr 2015 21:24:51 -0500
Ron Rechenmacher <ron@...l.gov> wrote:

> I've looked at the above reference briefly and it appears that user-space
> would be mmapping the buffer read-only. Is that correct?

Correct, but I'm sure we could still add something (if it doesn't
already exist) to have userspace write into the buffer. Ftrace has that
with the trace_marker file.

> I've also looked at lttng and I've said before, the "start-up cost" is too high.

I'm not sure what you mean by "start-up cost". Note, I'm not actually
talking about using userspace perf. I'm talking about using the perf
interface directly with your program like powertop does.

> My TRACE module creates the virtual file and allows the user-space program(s) to
> mmap a portion of it read-only (to protect the kernel) and then the buffer portion
> read-write - so, yes, any user-space program _could_ simply scribble over the
> buffer-portion, but what they usually end up doing it _writing_ their traces into
> the appropriate "slot" memory along side of slots that the kernel could be writing the
> key event TRACEs to.
> I'm not trying to promote the use of my TRACE, I'm just trying to show
> that there is a set of valid reasons (current and potential future) for accepting my patch.
> 

> 
> I'd rather not get into the "you should stop doing your thing and just/only do
> something else" mode, if you don't mind. As I've said before, I believe my TRACEing
> is just the right level of complexity for the total system analysis that I do and
> I have been periodically checking/searching what's out there.

Understand. This was my feeling with logdev. I ported it year after
year (from '98 all the way to 2007 - when ftrace made it obsolete, I
even ported it to the xen hypervisor!).

What I learned was that something that was so useful to me could also
be very useful for others. You got my attention. I want to understand
why this works for you so well, and perhaps we can modify the existing
tools to make them handle all the requirements that your TRACE tool
does or at the minimum, have something your TRACE tool can hook into.

ftrace is the result of logdev being merged with the latency-tracer
that was in the -rt patch. I'm not saying stop doing your thing, I'm
asking what is different about your thing that we can make our tools
better to do it too. Your thing is obviously beneficial to you. I'm
guessing it can be beneficial to others outside the fermilab.

> 
> A college of mine and I actually used perf, just today, to gain an understanding
> of what is going on in our "Nova data acquistion" system at fermilab. While it was
> useful, it is not a replacement for TRACE.

Again, I did not mean to use the perf user space tool. I was wondering
if it would be possible to have TRACE use the perf kernel interface.

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