This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Kprobes stress test prototype
- From: Ananth N Mavinakayanahalli <ananth at in dot ibm dot com>
- To: Masami Hiramatsu <mhiramat at redhat dot com>
- Cc: systemtap-ml <systemtap at sources dot redhat dot com>, "Frank Ch. Eigler" <fche at redhat dot com>
- Date: Mon, 29 Jun 2009 10:19:53 +0530
- Subject: Re: Kprobes stress test prototype
- References: <4A451460.2040206@redhat.com>
- Reply-to: ananth at in dot ibm dot com
On Fri, Jun 26, 2009 at 02:33:04PM -0400, Masami Hiramatsu wrote:
> Hi,
>
> Here is a script of kprobes stress test which uses
> kprobes-ftrace engine. Currently, this doesn't use any
> benchmarks for making a load.
> Any updates, comments, and reports are welcome!
>
> On KVM/x86-64, I've found some symbols must be marked
> as __kprobes or blacklisted by using this script.
>
> <always system hang up>
> p irq_return
> p start_critical_timing
> p time_hardirqs_off
> p bad_address
> p trace_hardirqs_off_thunk
> p restore
>
> <not always, but potentially dangerous>
> p start_critical_timings
> p stop_critical_timing
> p trace_hardirqs_on_thunk
> p restore_norax
>
> (I've encountered other odd memory corruptions too.
> However, I couldn't identify the reason, it might be a bug
> in kprobes or kvm.)
>
> Basic usage is very simple.
> Of course, this needs kprobes-ftrace engine patchset which
> I posted to lkml (http://lkml.org/lkml/2009/6/1/461).
>
> 1. Make a working area and put the script;
> $ mkdir stest/
> $ cp kprobestest stest/
>
> 2. Run it.
> $ cd stest/
> $ ./kprobestest run
>
> 3. If kernel gets trouble, reboot it and run again.
> $ cd stest/
> $ ./kprobestest run
>
> 4. Repeat it, until all symbols are tested.
Excellent!
> First, the test lists up all symbols in ".text" section, except
> ".text.kprobes"(*) and breaks it into sub-lists. Initially, each
> sub-lists has 64 symbols and are stored into "gray" dir.
> The test passes each sub-list to kprobes-ftrace engine and makes
> a load(currently, just sleep 2secs).
Wouldn't this be a very simplistic scenario? There could be cases where
the probes inserted were never hit during the 2sec interval, but may
potentially still be dangerous.
Ananth