linux-kernel - Re: [PATCH 2/3] ftrace: add trace pipe header pluggin

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]

Message-ID: <Pine.LNX.4.58.0804280903210.813@gandalf.stny.rr.com>
Date:	Mon, 28 Apr 2008 09:05:20 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Pekka Paalanen <pq@....fi>
cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	akpm@...l.org, Peter Zijlstra <peterz@...radead.org>,
	Soeren Sandmann Pedersen <sandmann@...hat.com>,
	Steven Rostedt <srostedt@...hat.com>
Subject: Re: [PATCH 2/3] ftrace: add trace pipe header pluggin


On Sat, 26 Apr 2008, Pekka Paalanen wrote:

> On Mon, 21 Apr 2008 17:09:37 -0400
> Steven Rostedt <rostedt@...dmis.org> wrote:
>
> > This patch adds a method for open_pipe and open_read to the pluggins
> > so that they can add a header to the trace pipe call.
> >
> > Signed-off-by: Steven Rostedt <srostedt@...hat.com>
>
> In addition to this, I think I need tracer::close method called on
> tracing_release_pipe(). Use case: the reader closes the pipe before
> I have printed all of my header, i.e. walked through all PCI devices,
> so I need to properly destroy trace_iterator::private.

Good idea, I'll add that.

>
> I also intend to use trace_iterator::seq for printing my header, so I
> am looking if I can reuse code from tracing_read_pipe(). Looks like I'll
> extract the "return any leftover data" part into a separate function.
>
> To check trace_iterator::overrun, I'd like to be able to use
> for_each_tracing_cpu(), but that is local to trace.c.

I'll look into that.

>
> What happens when the tracing cpu mask changes? Mmiotrace does not take
> that into account and will continue to record with all CPUs, will this
> lead to problems, when mmiotrace starts to support SMP properly?

Good question. The tracing_cpu_mask isn't mine. So I'll need to know that
answer too.

>
> Now that I think of it, I probably want to use for_each_online_cpu()
> in checking for overruns... but that's not good either, if someone
> enables/disables a cpu during tracing. I guess you will have to / had to
> deal with this case in tracing core, too.

Good point.


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