On Mon, 2006-12-18 at 19:55 -0500, Frank Ch. Eigler wrote:
Here is a little idea for dealing with several issues: that probes run
in interrupt-blocked state; that they thus may not call might_sleep
routines; that MAXACTIVE limits are too small for some contexts.
Let's permit a probe point option called ".sleepy" (or another better
term). When applied to several of the current probe classes (dwarf,
begin/end), this would run cause the translator to run the probe
handlers with no additional interrupt-disabling wrappers, and with an
much larger maximum-activity count.
The intent would be to assert that these probes are run in user
context, and thus should be allowed to perform blocking/sleeping
kernel calls such as copy_from_user. Good places for this would be
probes near system-call entry/exit boundaries, begin/end, and perhaps
some other probes. Some new context flag could pass this designation
to tapset (embedded-C) and thence to runtime functions.
I don't understand why we would want to add complexity to the language
when the translator already knows the probe type and context.
begin and end probes can sleep (if we allow it) and should have
MAXACTIVE set only to prevent infinite loops.
timer probes currently are implemented as interrupts and therefore
cannnot sleep and should have small MAXACTIVE. It might be possible to
implement them differently and remove this constraint.
kprobes cannot sleep because irqs are disabled. So the idea of allowing
copy_from_user() in some places will not work AFAIK. MAXACTIVE should be
small, but perhaps it can be larger when not running in interrupt
context.
Martin