linux-kernel - Re: [PATCH -tip tracing/kprobes 0/9] tracing/kprobes, perf: perf probe and kprobe-tracer bugfixes

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: <20091017103427.GA31238@elte.hu>
Date:	Sat, 17 Oct 2009 12:34:27 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Masami Hiramatsu <mhiramat@...hat.com>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	lkml <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Mike Galbraith <efault@....de>,
	Paul Mackerras <paulus@...ba.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Christoph Hellwig <hch@...radead.org>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	Jim Keniston <jkenisto@...ibm.com>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	systemtap <systemtap@...rces.redhat.com>,
	DLE <dle-develop@...ts.sourceforge.net>
Subject: Re: [PATCH -tip tracing/kprobes 0/9] tracing/kprobes, perf: perf
	probe and kprobe-tracer bugfixes

I took a good look at the current bits, and there are a few more things 
that need to be fixed before we can consider 'perf probe' for upstream.

Firstly, this decoder bug is still not fixed:

  CHK     include/linux/compile.h
  TEST    posttest
Error: ffffffff81068fe0:        66 0f 73 fd 04          pslldq $0x4,%xmm5
Error: objdump says 5 bytes, but insn_get_length() says 4 (attr:8000)
make[1]: *** [posttest] Error 2

64-bit allyesconfig will trigger this for example, but the attached 
smaller config too. This needs to be fixed before we can apply any
new commits.

Secondly, the probe syntax is quite non-obvious currently. All the 'p' 
and -P gymnastics is just a barrier to the first-time user getting his 
first probe inserted successfully.

The user need not worry about whether it's a 'kprobe' or a 'kretprobe'. 
The user should _specify_ what it wants to probe, and _that_ will lead 
to 'perf probe' picking the most suitable facility to achieve that kind 
of probing.

It might be a kprobe, a kretprobe, or an mcount driven function probe, 
an existing tracepoint if it happens to be present in that place already 
- or some other future mechanism. The driving force must be a robust 
specification of 'what', not the mechanics of 'how'.

Considering that, the current 'perf probe' syntax does not achieve that 
goal yet.

Here are a few syntax suggestions

The simpest probe syntax should be to add a probe to a single function 
name:

  perf probe +schedule

_nothing else_.

To remove it, the user should just do something like:

  perf probe -schedule

(to be symmetric 'perf probe +schedule' should work as well)

perf probe will make up a synthetic probe name for that - probe-1 for 
example. It will also pick the suitable probe mechanism (kprobes).

All the other extensions and possibilities - arguments, variables, 
source code lines, etc. should be natural and intuitive extensions of 
this basic, minimal syntax.

To insert a simple probe no -P should be needed, 'p', no ':' - no probe 
name even.

Furthermore, there should be a way to list existing probes (and only 
probes), probably via 'perf list --probes' or 'perf probe --list'.

Plus, 'perf probe --help' should list a few simple examples, beyond the 
syntax.

Ok?

	Ingo

View attachment "config" of type "text/plain" (65740 bytes)