linux-kernel - Re: [Patch -tip 1/3] Tracing/ftrace: Relay unhandled entry output

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: <20080925184919.016d8957@daedalus.pq.iki.fi>
Date:	Thu, 25 Sep 2008 18:49:19 +0300
From:	Pekka Paalanen <pq@....fi>
To:	"Frédéric Weisbecker" <fweisbec@...il.com>,
	"Steven Rostedt" <rostedt@...dmis.org>
Cc:	"Ingo Molnar" <mingo@...e.hu>, linux-kernel@...r.kernel.org
Subject: Re: [Patch -tip 1/3] Tracing/ftrace: Relay unhandled entry output

On Thu, 25 Sep 2008 17:33:02 +0200
"Frédéric Weisbecker" <fweisbec@...il.com> wrote:

> 2008/9/25 Pekka Paalanen <pq@....fi>:
> > IMHO this breaks the trace_seq handling. trace_seq may contain
> > the output of several entries, as far as they fit in it as a whole.
> > E.g. trace_seq_printf() does not print partial lines but returns 0,
> > so that the entry is not consumed right now. The user space reader
> > must consume trace_seq content, before trace_seq_printf()
> > is attempted again, hopefully with enough space in trace_seq to
> > succeed. See tracing_read_pipe().
> > print_line() callback works the same way. Returning 0 means "could
> > not print it this time, call me back later". You can't use that to
> > say "use the default output function instead". Note, that possibly
> > the default output function will fail, too, so it could actually
> > try many of the default output functions and still fail, eventually
> > leading by luck to the correct behaviour in most cases.
> > Note, that mmiotrace follows this convention: it deliberatly
> > returns 1 without processing when it wants the entry discarded, and
> > it returns 0 when there was not enough space to process the entry.
> > This is explained in my other email.
> 
> Hmm you're right. I didn't thought about the partial line which must
> not be printed.
> The problem is that with this convention, 0 means two things: "I will
> handle this entry
> later" or "I can't handle it".
> But if you return 0 because you can't handle it, and if the current
> len of the seq is 0, the
> pipe will be broken.

My understanding is that the pipe will be broken only, if the trace
framework believes tracing is disabled. Recall the discussion about
tracer_enabled = 0. Which is a bug, and I hoped Steven would have
commented on how to fix that properly.

Or was it fixed already, and this is a different issue?
I didn't notice.

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