linux-kernel - Re: perf/tracepoints access to interpreted strings

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]

Message-ID: <20150421143501.GA11111@kernel.org>
Date:	Tue, 21 Apr 2015 11:35:01 -0300
From:	Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	David Ahern <dsahern@...il.com>,
	Namhyung Kim <namhyung@...nel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: perf/tracepoints access to interpreted strings

Em Tue, Apr 21, 2015 at 09:07:33AM -0400, Steven Rostedt escreveu:
> On Mon, 20 Apr 2015 15:26:56 -0600 David Ahern <dsahern@...il.com> wrote:
> > On 4/20/15 3:25 PM, Arnaldo Carvalho de Melo wrote:
> > > Em Mon, Apr 20, 2015 at 04:46:16PM -0400, Steven Rostedt escreveu:
> > >> On Wed, 15 Apr 2015 15:09:27 -0300 Arnaldo Carvalho de Melo <acme@...nel.org> wrote:
> > >> Note, with the new TRACE_DEFINE_ENUM() that was already added to
> > >> Linus's tree, that print_fmt now looks like:

> > >> print fmt: "vec=%u [action=%s]", REC->vec, __print_symbolic(REC->vec,
> > >>   { 0, "HI" }, { 1, "TIMER" }, { 2, "NET_TX" }, { 3, "NET_RX" }, { 4, "BLOCK" },
> > >>   { 5, "BLOCK_IOPOLL" }, { 6, "TASKLET" }, { 7, "SCHED" }, { 8, "HRTIMER" },
> > >>   { 9, "RCU" })

> > > That is better, indeed, covers holes :-)

> > Seems to me that means 2 different implementations are needed ... old 
> > and new.

> Why? The above is the way most trace points use __print_symbolic().

I think he is talking about any user space implementation handling those
enum->STR mappings, __print_symbolic() included.

> It's just when a tracepoint uses enums instead of defines or hard coded
> numbers do the useless enum name pops up.

> Any parse should be expecting numbers, not enum names.

Humm, I found that the point was that on field 'vec' we receive a
number, and we want to format it to something less cryptic, so we need
to map a number to a string.

The original implementation, that doesn't have that { number, string }
will fail to handle sparse enums, because we can't map number -> "string".

So it has to handle both:

1)    { string, "string" } 
2)    { number, "string" }

And for 1) keep some blacklist of { tracepoint, field-list } that can't
be safely mapped number -> "string", i.e. a blacklist of sparse enums,
no?

David, we could as well just blacklist all kernels where 1) is used and
do no mapping, supporting only 2) kernels. We can do that by parsing
the first element, and if it is not a number, blacklist it.

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