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


On Wed, 2005-12-07 at 16:09 -0500, Frank Ch. Eigler wrote:

> > It would prevent things like sorting and printing maps, no matter
> > what their size. Theoretically we could allow these for very small
> > maps, but why would we want to?
> 
> Well, because they may be necessary for some as-yet-unimagined probing
> context.  The problem is not sorting per se, but the amount of time
> that sorting (or anything else) takes.  If we were to impose
> language-level restrictions, and someone still needed to sort/print
> array pieces from within a kprobe, they'd just work around it.

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. You say this might disallow
some theoretical useful code. I say it just confuses the programmers
into writing bad code..

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.

Another acceptable solution would be to have a way to automatically
defer printing and sorting of arrays to a more acceptable time
(basically like the previous example, but without the need to create a
timer event). This is easy enough to implement internally, but the
current printing syntax would need significant changes.

> They
> can go and open-code a bubble sort in script language, a foreach/print
> over the array.  I'm sure you agree this is not desirable.

Of course not. But if they attempted that, they would still run into the
MAXACTION limit. So it would be safe to do so.

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

> > Rather than attempt to calculate how much time a potentially
> > time-consuming function will really take [...]
> 
> 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. 

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. But I don't have access to hardware to run any tests.
If fact, this is the real problem. Without access to hardware, any value
approximating how long it takes to aggregate a pmap is just a wild
guess. So I am reluctant to go to a lot of work and testing just to come
up with a better guess, which may well be wrong. And all to support
something I think is probably not safe or a good idea.

> > 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. We are simply arguing
over how fine-grained those deadlines are and how to calculate them, are
we not?

Martin



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