[PATCH 0/4 update] Linux Kernel Markers - i386 : pIII erratum 49 : XMC
Frank Ch. Eigler
fche@redhat.com
Tue Jan 16 18:35:00 GMT 2007
Mathieu Desnoyers <compudj@krystal.dyndns.org> writes:
> [...]
> It would be nice to push the study of the kprobes debug trap handler so it can
> become possible to use it to put breakpoints in trap handlers. For now, kprobes
> refuses to insert breakpoints in __kprobes marked functions. However, as we
> instrument specific spots of the functions (not necessarily the function entry),
> it is sometimes correct to use kprobes on a marker within the function even if
> it is not correct to use it in the prologue. [...]
It may help to note that the issue with __kprobes attributes is
separate from putting probes in the prologue vs. elsewhere. The
__kprobes functions are so marked because they can cause infinite
regress if probed. Examples are fault handlers that would service
vmalloc-related faults, and some other functions unavoidably callable
from early probe handling context. Over time, the list has shrunk.
Indeed, __kprobes marking is a conservative measure, in that there may
be spots in such functions that are immune from recursion hazards.
But so far, we haven't encountered enough examples of this to warrant
refining this blacklist somehow.
- FChE
More information about the Systemtap
mailing list