linux-kernel - Re: Tracing/ftrace: trouble with trace_entries and trace

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: <c62985530809160157n5ca5cfa0m1a4865aeb710a74a@mail.gmail.com>
Date:	Tue, 16 Sep 2008 10:57:51 +0200
From:	"Frédéric Weisbecker" <fweisbec@...il.com>
To:	"Pekka Paalanen" <pq@....fi>
Cc:	"Steven Rostedt" <rostedt@...dmis.org>,
	"Ingo Molnar" <mingo@...e.hu>,
	"Linux Kernel" <linux-kernel@...r.kernel.org>
Subject: Re: Tracing/ftrace: trouble with trace_entries and trace_pipe

2008/9/15 Pekka Paalanen <pq@....fi>:
> My other problem is with trace_pipe. It is again making 'cat' quit too
> early. The condition triggered is
>        if (!tracer_enabled && iter->pos) {
> in tracing_read_pipe(), and it is followed by triggering
>        /* stop when tracing is finished */
>        if (trace_empty(iter)) {
> and then sret=0, so read returns 0 and 'cat' exits.
>
> Now, I am trying my mmiotrace marker patches, but as far as I can tell,
> nothing I modified is the reason for this. I didn't yet explicitly test
> for it, though. I'll send these patches after I hear from Frederic.
>
> The cat-quit problem is not a constant state. After boot, I could play
> with my markers and testmmiotrace without cat quitting. Then something
> happens, and cat starts the quitting behaviour, and won't get to normal
> by disabling and enabling mmiotrace.
>
> I have a couple of wild guesses of what might be related:
> - ring buffer wrap-around
> - ring buffer overflow (at first try I hit these, the second try
> after putting debug-pr_info's in place I don't hit this)
> - ring buffer resize (after playing with trace_entries, cat-quit
> problem was present, though it might have been present before)
>
> After viewing the git history, I have some more guesses, mainly
> related to setting tracer_enabled to 0.
> - commit 2b1bce1787700768cbc87c8509851c6f49d252dc
> I don't see where tracer_enabled would be set to 1, when
> mmiotrace is enabled. It used to default to 1 and mmiotrace was happy.
> - __tracing_open() sets it to 0 (not called for the pipe)
> - tracing_release() sets it to 1
> - tracing_ctrl_write() toggles it
> - tracing_read_pipe() tests it
> - tracer_alloc_buffers() uses it
> And other tracers seem to use it a lot.
>
> Mmiotrace does use the tracer::ctrl_update hook, and allow/disallow
> calls to __trace_mmiotrace_{rw,map}() via enabling/disabling the whole
> mmiotrace core. Is this not enough, or is it inappropriate?
>
> It seems tracer_enabled is used by the trace framework itself to
> enable/disable... what? Hmm, maybe nothing I care about.
>
> Should mmiotrace simply do
>        tracer_enabled = 1;
> in mmio_trace_init()?
>
> Should mmiotrace test tracer_enabled, and if so, when?


As I said to you, I met the same bug of this early quit of the pipe.
But I should give here more details.
This bug occurs with -tip (a version pulled 2 days ago so trace.c
didn't change).
I never saw it with other tracers than mmiotrace. I had no problem
with sched_switch or function tracer.

It happened when I was writing the tracer marker. So I'm not sure if
the origin is here. If I'm not wrong it happened whithout adding mark
messages too.
Can you tell me if your pipe quits when you add a mark or if this bug
occurs on other cases too?

I will try to reproduce the bug this evening.
--
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/