This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug kprobes/2637] skipped probes in FC6
- From: "fche at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sources dot redhat dot com
- Date: 5 May 2006 13:49:34 -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 fche at redhat dot com 2006-05-05 13:49 -------
(In reply to comment #6)
> 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.
Quite possible - the faulting strings appear to come from the ps/sh executables'
data pages. Maybe, under new kernels, those are faulted in later than before.
This would be difficult to work around. Some possibilities:
- Teach the translator to look for user_string($targetvar) constructs. Find a
way of "prefetching" the requested area of user memory, before the probe handler
gets under way.
- Defer the user_string() calls in tapset script code to the .return handler, or
some other point *after* the kernel's syscall routine ran (and presumably
faulted in all needed pages).
- Reconsider the atomic probe handler model.
>[...] Should we remove incrementing the nmissed count even if
fixup_exception() fails?
"nmissed" is a misnomer in this case, since the fault occurred once the probe
handler was already running, so may have done work. But for systemtap purposes,
"missed" ideally means "never started; no side-effects occurred". Maybe we can
choose to interpret kprobes.nmissed changing as an error, and only
kretprobes.nmissed as a genuine "missed" event.
--
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.