Re: MAXACTION exceeded error while using systemtap

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi -


hunt wrote:

> I think we keep repeating this discussion. You argue for a general-
> purpose language which dynamically detects unsafe code and exits.  I
> argue that the language is application-specific and certain unsafe
> behaviors should not be permitted at all.

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?).


> You say this might disallow some theoretical useful code. 

This is fact.

> I say it just confuses the programmers into writing bad code..

This is speculation.


> For example, imagine a kprobe on an infrequently used function.
> When it is finally hit, it might be nice to sort and print a stored
> array of collected data. Doing it in the kprobe risks hitting
> MAXACTION.  Setting a flag and having a timer event that checks the
> flag and dumps the data would be a better solution.

Really?  What if the kprobe hits more than the expected number of
times per timer poll?

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?


> Another acceptable solution would be to have a way to automatically
> defer printing and sorting of arrays to a more acceptable time [...]
> but the current printing syntax would need significant changes.

This is worth further investigation, but of course has its own
complications.  These include concurrency: this would either require
locking the to-be-sorted/printed arrays until the printing coroutine
runs, or suffer the loss of coherence, or a potentially large
array-snapshot.


> [...]  I am in no way advocating eliminating MAXACTION. Just
> replacing it with a more flexible function that know what context we
> are in (kprobe, timer, end probe, etc).

OK, but you still need to justify your belief that this more flexible
function can safely have drastically different values in those
different contexts.


> > I'm not suggesting that such a calculation need be precise enough to
> > be anything more than a trivial function of the subject map size.  It
> > just needs to be vaguely proportional to the cost, so we can keep to a
> > rough deadline.
> 
> So we allow people to write code that will work for a while until some
> arbitrary point when MAXACTION gets exceeded.  Then (if we still allow
> it)  they rerun with MAXACTION set higher and higher until their kernel
> crashes. 

Yes, that's possible.  Setting MAXACTION very high (for some unknown
value of "very") is tantamount to guru-mode loss of protection.


> I think it is possible that on a large multiprocessor system,
> determining the size of a pmap could well take longer than is safe
> within a kprobe. [...]

How is that?  I've already said in the relevant PR and above that we
would not need an accurate size of the hypothetically-aggregated pmap.
A plain sum over the unaggregated per-cpu arrays would be good enough.
That would take just one for loop over the number of CPUs, and might
not even require locks.


> > > For timer events, MAXACTION would be very large. Large enough to
> > > sort any size arrays and print maybe 1000 lines or so.  For begin
> > > and end probes, MAXACTION would be something less than infinite so
> > > there are no infinite loops.
> > 
> > I believe this expresses the mistaken belief that deadlines are only
> > necessary for kprobes.
> 
> I believe that contradicts everything I wrote. 

Sorry, I could not interpret "something less than infinite" as an
endorsement of deadlines.

> We are simply arguing over how fine-grained those deadlines are and
> how to calculate them, are we not?

No.  You suggested subsetting the language for kprobe contexts, which
goes well beyond this.


- FChE