This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: MAXACTION exceeded error while using systemtap
hunt wrote:
> > Or, in other words, for ensuring one type of safety, I believe runtime
> > means are sufficient with unrestricted language; you believe
> > probe-point-specific language restrictions are necessary and/or
> > sufficient (which?).
>
> Necessary, but not sufficient.
But it can't be necessary either, since plain maxaction counting is by
itself sufficient to provide that same type of safety.
> [...] However from a systemtap users perspective, what you propose
> is terrible. You are proposing having functions that depending on
> where they are used may work some of the time [...] And then your
> program terminates with an error!
What is so terrible about an error, when it is easily explained? Once
my bemoaned data vacuum is filled, and a more informed maxaction
default is set (perhaps on a per-probe-point family basis), we may not
actually encounter it in realistic scenarios.
> I believe having something like MAXACTION is necessary as a check
> against putting too much in a kprobe or infinite looping. However it
> should trigger immediately and should not be based on dynamically
> changing thresholds. And should not be user-visible at all.
What does that mean? Triggering "immediately" is impossible for
computability reasons. How do you imagine aborted probes should be
presented if they are "not user-visible"? We shouldn't notify the
user that their code did not run to completion?
> Systemtap is not a general-purpose programming environment. kprobes
> are very timing sensitive. They should do data collection and
> printing of simple scalar data. Data analysis can/should be done in
> other contexts. I see nothing wrong with documenting this and
> enforcing it.
Please be specific by what "this" is that you wish to permit kprobes.
Something loop-free straitjacketed like dtrace? If not, then the
language restrictions don't matter (since sorting / array printing can
be reduced to scalar operations, as we've already covered).
> > Can you explain why you believe that an operation that takes the exact
> > same amount of time (dumping the data) is necessarily unsafe in a
> > kprobe and necessarily safe in a timer probe?
>
> Because timer probes can run in process context which means they
> sleep, can be scheduled, take as long as they want? [...]
You're getting hung up on an accident of implementation. Probe
handlers are not supposed to be able to sleep (be blocking /
interupted / scheduled). This was written on day one. The fact that
timers and begin/end probes don't behave this way is a bug. Reopening
this issue is possible, but needs better justification than wanting to
run ten-second loops in kernel space.
- FChE