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: 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


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