All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Masami Hiramatsu <mhiramat@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	lkml <linux-kernel@vger.kernel.org>, Avi Kivity <avi@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Andi Kleen <andi@firstfloor.org>,
	Jim Keniston <jkenisto@us.ibm.com>,
	"K.Prasad" <prasad@linux.vnet.ibm.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	systemtap <systemtap@sources.redhat.com>,
	kvm <kvm@vger.kernel.org>, Tom Zanussi <zanussi@comcast.net>
Subject: Re: [PATCH -tip v5 0/7] tracing: kprobe-based event tracer and x86 instruction decoder
Date: Mon, 11 May 2009 23:47:12 +0200	[thread overview]
Message-ID: <20090511214712.GF21232@elte.hu> (raw)
In-Reply-To: <4A088523.6080003@redhat.com>


* Masami Hiramatsu <mhiramat@redhat.com> wrote:

> Steven Rostedt wrote:
> > On Mon, 11 May 2009, Masami Hiramatsu wrote:
> >>> Two high-level comments:
> >>>
> >>>  - There's no self-test - would it be possible to add one? See 
> >>>    trace_selftest* in kernel/trace/
> >> I'm not so sure. Currently, it seems that those self-tests are
> >> only for tracers which define new event-entry on ring-buffer.
> >> Since this tracer just use ftrace_bprintk, it might need
> >> another kind of selftest. e.g. comparing outputs with
> >> expected patterns.
> >> In that case, would it be better to make a user-space self test
> >> including filters and tracepoints?
> > 
> > Or have the workings in the selftest in kernel. As if a user started it. 
> > It does not need to write to the ring buffer, that is just what I did. The 
> > event selftests don't check if anything was written to the ring buffer, 
> > they just make sure that the tests don't crash the system.
> 
> Would you mean that it is enough to enable some probes and just
> see what happened at boot time?
> That's so easy to add.

Yes, that's the idea!

Try to think of regressions/crashes/misbehavior you generally 
trigger while you developed kprobes, and try to add a reasonable set 
of probes that test the code from those angles.

It doesnt have to be a full, complex test-suite, but even just 80% 
of coverage of functionality keeps 4/5th of all regressions out of 
the kernel at a very early stage ...

	Ingo

WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@elte.hu>
To: Masami Hiramatsu <mhiramat@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
		lkml <linux-kernel@vger.kernel.org>, Avi Kivity <avi@redhat.com>,
		"H. Peter Anvin" <hpa@zytor.com>,
		Frederic Weisbecker <fweisbec@gmail.com>,
		Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
		Andrew Morton <akpm@linux-foundation.org>,
		Andi Kleen <andi@firstfloor.org>,
		Jim Keniston <jkenisto@us.ibm.com>,
		"K.Prasad" <prasad@linux.vnet.ibm.com>,
		KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
		systemtap <systemtap@sources.redhat.com>,
	kvm <kvm@vger.kernel.org>, 	Tom Zanussi <zanussi@comcast.net>
Subject: Re: [PATCH -tip v5 0/7] tracing: kprobe-based event tracer and x86 	instruction decoder
Date: Mon, 11 May 2009 23:47:12 +0200	[thread overview]
Message-ID: <20090511214712.GF21232@elte.hu> (raw)
In-Reply-To: <4A088523.6080003@redhat.com>


* Masami Hiramatsu <mhiramat@redhat.com> wrote:

> Steven Rostedt wrote:
> > On Mon, 11 May 2009, Masami Hiramatsu wrote:
> >>> Two high-level comments:
> >>>
> >>>  - There's no self-test - would it be possible to add one? See 
> >>>    trace_selftest* in kernel/trace/
> >> I'm not so sure. Currently, it seems that those self-tests are
> >> only for tracers which define new event-entry on ring-buffer.
> >> Since this tracer just use ftrace_bprintk, it might need
> >> another kind of selftest. e.g. comparing outputs with
> >> expected patterns.
> >> In that case, would it be better to make a user-space self test
> >> including filters and tracepoints?
> > 
> > Or have the workings in the selftest in kernel. As if a user started it. 
> > It does not need to write to the ring buffer, that is just what I did. The 
> > event selftests don't check if anything was written to the ring buffer, 
> > they just make sure that the tests don't crash the system.
> 
> Would you mean that it is enough to enable some probes and just
> see what happened at boot time?
> That's so easy to add.

Yes, that's the idea!

Try to think of regressions/crashes/misbehavior you generally 
trigger while you developed kprobes, and try to add a reasonable set 
of probes that test the code from those angles.

It doesnt have to be a full, complex test-suite, but even just 80% 
of coverage of functionality keeps 4/5th of all regressions out of 
the kernel at a very early stage ...

	Ingo

  reply	other threads:[~2009-05-11 21:48 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-09  0:48 [PATCH -tip v5 0/7] tracing: kprobe-based event tracer and x86 instruction decoder Masami Hiramatsu
2009-05-09  0:48 ` Masami Hiramatsu
2009-05-09  0:48 ` [PATCH -tip v5 1/7] x86: instruction decorder API Masami Hiramatsu
2009-05-11  9:27   ` Christoph Hellwig
2009-05-11  9:27     ` Christoph Hellwig
2009-05-11 14:36     ` Masami Hiramatsu
2009-05-11 14:36       ` Masami Hiramatsu
2009-05-13  8:23   ` Gleb Natapov
2009-05-13  8:23     ` Gleb Natapov
2009-05-13  9:35     ` Przemysław Pawełczyk
2009-05-13  9:43       ` Gleb Natapov
2009-05-13  9:43         ` Gleb Natapov
2009-05-13 14:35         ` Masami Hiramatsu
2009-05-13 14:35           ` Masami Hiramatsu
2009-05-13 15:20           ` Gleb Natapov
2009-05-09  0:48 ` [PATCH -tip v5 2/7] kprobes: checks probe address is instruction boudary on x86 Masami Hiramatsu
2009-05-09  0:48   ` Masami Hiramatsu
2009-05-11 14:20   ` Steven Rostedt
2009-05-11 15:01     ` Masami Hiramatsu
2009-05-11 15:01       ` Masami Hiramatsu
2009-05-11 15:14       ` Masami Hiramatsu
2009-05-11 15:14         ` Masami Hiramatsu
2009-05-11 15:22       ` Steven Rostedt
2009-05-11 18:21         ` Masami Hiramatsu
2009-05-11 18:21           ` Masami Hiramatsu
2009-05-09  0:48 ` [PATCH -tip v5 3/7] kprobes: cleanup fix_riprel() using insn decoder " Masami Hiramatsu
2009-05-09  0:48   ` Masami Hiramatsu
2009-05-09  0:48 ` [PATCH -tip v5 4/7] tracing: add kprobe-based event tracer Masami Hiramatsu
2009-05-09 16:36   ` Frédéric Weisbecker
2009-05-09 16:36     ` Frédéric Weisbecker
2009-05-09 17:33     ` Masami Hiramatsu
2009-05-11 21:26       ` Frederic Weisbecker
2009-05-11  9:32   ` Christoph Hellwig
2009-05-11 10:53     ` Ingo Molnar
2009-05-11 10:53       ` Ingo Molnar
2009-05-11 15:28     ` Frank Ch. Eigler
2009-05-11 15:28       ` Frank Ch. Eigler
2009-05-09  0:49 ` [PATCH -tip v5 5/7] x86: fix kernel_trap_sp() Masami Hiramatsu
2009-05-11  9:28   ` Christoph Hellwig
2009-05-11 13:48     ` Masami Hiramatsu
2009-05-11 13:48       ` Masami Hiramatsu
2009-05-09  0:49 ` [PATCH -tip v5 6/7] x86: add pt_regs register and stack access APIs Masami Hiramatsu
2009-05-09  0:49 ` [PATCH -tip v5 7/7] tracing: add arguments support on kprobe-based event tracer Masami Hiramatsu
2009-05-11 14:35   ` Steven Rostedt
2009-05-11 14:35     ` Steven Rostedt
2009-05-09  4:43 ` [PATCH -tip v5 0/7] tracing: kprobe-based event tracer and x86 instruction decoder Ingo Molnar
2009-05-09  4:43   ` Ingo Molnar
2009-05-11 14:40   ` Masami Hiramatsu
2009-05-11 14:56     ` Steven Rostedt
2009-05-11 20:05       ` Masami Hiramatsu
2009-05-11 20:05         ` Masami Hiramatsu
2009-05-11 21:47         ` Ingo Molnar [this message]
2009-05-11 21:47           ` Ingo Molnar
2009-05-12 22:03   ` Masami Hiramatsu
2009-05-12 22:03     ` Masami Hiramatsu
2009-05-13 13:21     ` Ingo Molnar
2009-05-13 13:21       ` Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090511214712.GF21232@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@linux-foundation.org \
    --cc=ananth@in.ibm.com \
    --cc=andi@firstfloor.org \
    --cc=avi@redhat.com \
    --cc=fweisbec@gmail.com \
    --cc=hpa@zytor.com \
    --cc=jkenisto@us.ibm.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@redhat.com \
    --cc=prasad@linux.vnet.ibm.com \
    --cc=rostedt@goodmis.org \
    --cc=systemtap@sources.redhat.com \
    --cc=zanussi@comcast.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.