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]

gettimeofday args & Re: Begin probes & irqs disabled?


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.

For safety reasons, this designation should require guru mode for
kprobes, though it could become default for begin/end.  The translator
can likely emit code that checks heuristics such as !in_interrupt() at
probe entry and skip the probe otherwise.  Since the rwlocks on
systemtap script global variables are still necessary, probes that
sleep can block the rest of the script due to lock timeouts, but
that's OK (and should just result in skipped probes).

It might work.  Thoughts?

- FChE


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