This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug kprobes/2637] skipped probes in FC6


------- 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]