This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug kprobes/2637] skipped probes in FC6
- From: "hunt at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sources dot redhat dot com
- Date: 5 May 2006 16:42:42 -0000
- Subject: [Bug kprobes/2637] skipped probes in FC6
- References: <20060502201312.2637.hunt@redhat.com>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From hunt at redhat dot com 2006-05-05 16:42 -------
Subject: Re: skipped probes in FC6
On Fri, 2006-05-05 at 06:56 +0000, prasanna at in dot ibm dot com wrote:
> ------- Additional Comments From prasanna at in dot ibm dot com 2006-05-05 06:56 -------
> The example given by Martin, accesses the data in user address space. Most
> likely the data accessed from user address space may not be present in memory.
True. But such situations have in the past been extremely rare. What is
it about the new kprobes that makes it now so common and predictable? We
need to understand this better.
> It is known that such accesses causes page_faults, where in the
> fixup_exception() may not succeed most of the times, hence nmissed count goes up
> (even with the current above patch).
Could you explain what would cause such an event? It does not happen in
my experience and I don't see how it could. If there is an entry in the
fixup table, which there always should be if you use a proper userspace
copy function, fixup exception will work.
> Is it acceptable, if the probe handler fails most of the time, while accessing
> arguments from user address space. OR do we need to find some other way to
> get the agruments of the syscalls
The current situation fails too often and is completely unacceptable. I
cannot even run my simple demo programs.
If we absolutely cannot fix the problem, then we must as a minimum
change user_string() to just return "" or "<unknown>" and not generate
errors or warnings when copies fail.
Martin
--
http://sourceware.org/bugzilla/show_bug.cgi?id=2637
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.