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

Date:	Wed, 17 Sep 2008 20:36:09 +0300
From:	Pekka Paalanen <pq@....fi>
To:	"Steven Rostedt" <rostedt@...dmis.org>
Cc:	"Frédéric Weisbecker" <fweisbec@...il.com>,
	"Ingo Molnar" <mingo@...e.hu>,
	"Linux Kernel" <linux-kernel@...r.kernel.org>
Subject: Re: Tracing/ftrace: trouble with trace_entries and trace_pipe

On Wed, 17 Sep 2008 14:41:29 +0200
"Frédéric Weisbecker" <fweisbec@...il.com> wrote:

> 2008/9/16 Pekka Paalanen <pq@....fi>:
> > Ok, so the problem is probably the commit I mentioned. It makes the
> > no_tracer tracer to set tracer_enabled to 0, and I can't find where
> > it would be set to 1 for mmiotrace. And this interferes with
> > tracing_read_pipe(), making it quit when iter->pos is non-zero.
> > See no_trace_init() in trace.c. According to this, the cat-quit
> > occurs when the buffer gets empty after first data, but this isn't
> > totally in agreement with what I recall from my experiments. And it
> > does happen also on other times than injecting markers.
> >
> > So either it is wrong to check tracer_enabled in tracing_read_pipe(),
> > or no_trace_init() should not touch it.
> 
> Indeed that could be the problem.
> None_tracer is chosen as the default tracer when the tracer engine
> loads. But actually no_trace_init is not called at this time.
> 
> But if you set another tracer and reset current_tracer to none, you
> will call no_trace_init. Since tracer_enabled is not reset to 1 with
> other tracer's init functions, the problem occurs when you choose one
> more time another tracer.

Ah, this would explain the "non-deterministic" behaviour I saw.

> I think that mmiotrace receives a smaller flow of entries (depends on
> the debugged module) whereas sched_switch or function's tracer, as an
> example, are continuously fed and never enter the "while
> (trace_empty(iter))" block. That's why I only see this bug in
> mmiotrace.

Mmiotrace does see times, when there are a small number of events
coming, even when tracing a graphics driver. Sounds plausible.

> Perhaps it would be a good idea to reenable tracer_enabled on
> tracing_set_trace_write() just before calling the init callback of the
> tracer chosen.

That's a third option, yes.

Steven, what is the correct fix?

Frederic, thank you very much for testing this!

-- 
Pekka Paalanen
http://www.iki.fi/pq/
--
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/