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]

Re: gettimeofday args & Re: Begin probes & irqs disabled?


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




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