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: resuming after stop at syscall_entry


Roland McGrath wrote:

This processing makes sense I think.  It is a bit complicated of course,
but not unnecessarily so.

I'd like to ask you how this stuff would relate to systemtap (so I've
added the systemtap mailing list).  I've interspersed a few
comments/questions below.

... stuff deleted ...
> SYSCALL_ENTRY is unlike all other events.  Right after this callback
> loop is when the important user-visible stuff happens (the system call).
> So we stop immediately there as for the other two.  But, if another
> engine used UTRACE_STOP and maybe did something asynchronously, like
> modifying the syscall argument registers, you get no opportunity to see
> what happened.  Once all engines lift UTRACE_STOP, the system call runs.

... stuff deleted ...

> As explained above, the norm of interacting with other engines and their
> use of UTRACE_STOP is to use the final report.  When your callback's
> action argument includes UTRACE_STOP, you know an earlier engine might
> be fiddling before the thread resumes.  So, your callback can decide to
> return UTRACE_REPORT.  That ensures that some report_quiesce (or
> report_signal/UTRACE_SIGNAL_REPORT) callback will be made after the
> other engine lifts its UTRACE_STOP and before user mode.  At that point,
> you can see what user register values it might have installed, etc.  In
> all events but syscall entry, a final report_quiesce(0) serves this need.
> 
> My proposal is to extend this "resume report" approach to the syscall
> entry case.  That is, after when some report_syscall_entry returned
> UTRACE_STOP so we've stopped, allow for a second reporting pass after
> we've been resumed, before running the system call.  You'd get this pass
> if someone used UTRACE_REPORT.  That is, in the first callback loop, one
> engine used UTRACE_STOP and another used UTRACE_REPORT.  Then when the
> first engine used utrace_control() to resume, there would be a second
> reporting pass because of the second engine's earlier request.  Or, even
> if there was just one engine, but it used UTRACE_STOP and then used
> utrace_control(UTRACE_REPORT) to resume, then it would get the second
> reporting pass.  If someone uses UTRACE_STOP+UTRACE_REPORT in that pass,
> there would be a third pass, etc.
> 
> What I have in mind is that the second (and however many more) pass
> would just be another report_syscall_entry callback to everyone with
> UTRACE_EVENT(SYSCALL_ENTRY) set.  A flag bit in the action argument says
> this is a repeat notification.
> 
> I think this strikes a decent balance of not adding more callbacks and
> more arguments to bloat the API in general, while imposing a fairly
> simple burden on engines to avoid getting confused by multiple calls.
> 
> A tracing-only engine that just wants to see the syscall that is going
> to be done can just do:
> 
> 	if (utrace_resume_action(action) == UTRACE_STOP)
> 		return UTRACE_REPORT;
> 
> at the top of report_syscall_entry, so it just doesn't think about it
> until it thinks the call will go now through.  

Systemtap currently doesn't support changing syscall arguments, if it
does, obviously a few things would need to change.

But, I think systemtap would probably fall here - only see the syscall
that is actually going to be done.  So systemtap could possibly get
multiple callbacks for the same syscall, but only pay attention to the
last one, correct?

> Say an engine has a different agenda, just to see what syscall argument
> values came in from user mode before someone else changes them.  It does:
> 
> 	if (action & UTRACE_SYSCALL_RESUMED)
> 		return UTRACE_RESUME;
> 
> to ignore the additional callbacks that might come after somebody
> decided to stop and report.  It just does its work on the first one.
> 
> Here comes Renzo again!  He wants to have two or three or nineteen
> layers of the first kind of Renzo engine: each one stops at syscall
> entry, then resumes after changing some registers.  He wants these to
> "nest", meaning that after the "outermost" one stops, fiddles, and
> resumes, the "next one in" stops, looks at the register as fiddled by
> the outermost guy, fiddles in a different way, and resumes, and on and
> on.  Perhaps the first model (if last guy is stopping, punt to look
> again at resume report) works for that.  Or perhaps the engine also
> needs to keep track with its own state flag it sets whenever it does its
> work, and then resets in exit tracing to prepare for next time.

... stuff deleted ...

> So, even I can't write that much text and still think this interface
> choice is simple to understand.  But I kind of think it's around as
> simple as it can be for its mandates.  I'd appreciate any feedback.

This is understandable, but does hurt my head a *little* bit.  I think
if you put the above full text somewhere and provided some examples this
would make sense to people.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)


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