linux-kernel - Re: [PATCH] ftrace: kill global_start

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]

Date:	Wed, 23 Jul 2014 14:53:19 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Namhyung Kim <namhyung@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ftrace: kill global_start_up

On Wed, 23 Jul 2014 20:29:11 +0200
Oleg Nesterov <oleg@...hat.com> wrote:

> > Nevermind, seems that Namhyung Kim beat you to it (and it's already in
> > my for-next branch).
> >
> > http://lkml.kernel.org/r/1402584972-17824-1-git-send-email-namhyung@kernel.org
> 
> Thanks for your report Steven, I updated my ~/people-i-hate file.

Is that for me or Namhyung? Silly question, it has to be for Namhyung,
as I'm sure I'm one of the first people already in that list.

> 
> 
> This motivated me to try to find something else unused. And it seems that
> almost all code in kernel/trace/trace_sched_switch.c is dead? Hmm, and

sched_switch? Move along, nothing to see here...

OK, there was a time we had a bunch of "tracers" (those things in
the available_tracers file). And since events and perf came along,
there was a push to remove them all. We never got rid of function,
function_graph, mmiotrace and the latency tracers as they are quite
different from events (function is close, but they need special care).

One of the casualties to that tracer purge was the sched_switch tracer.
But it wasn't such a simple removal, as that code was in charge of the
trace_find_cmdline() logic. Well, to get people away from using it, we
removed it from the "available_tracers" file, but kept most of the code
as clean up for another day.

As with most things on a TODO list, they get pushed down to the bottom,
crushed by the many things above it, and finally swept under the rug
until some nosy developer decides to take a peek under that carpet and
point to the maintainer of said code with his white glove on and the
smudge at the end of his finger and say "WHAT'S THIS!".

Well, here's a broom and dustpan, have at it!

> probably even event_context_switch... I'll recheck and send the patch.
> 
> But is there any documentation about /sys/kernel/debug/tracing/events/ftrace/*
> files ?

No, they are mostly internal, and only there for the format files for
things like trace-cmd and perf to be able to parse it.

> 
> OK, as I just figured out ftrace/function is special, it is visible to
> perf and thus "record ftrace:function" should work.
> 
> But what a user can do with other files? You obviously can't enable, say,
> ftrace/bputs, if I understand correctly this is for trace_puts().
> 

Yeah, as trace_printk() can turn into a trace_puts() we still want
those to be read by trace-cmd. To do that, the formats for those files
are exported.

See kernel/trace/trace_export.c and trace_entries.h

> Confused...

Aren't we all?

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