Re: engine interaction, callback order

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Wed, 2007-08-29 at 05:15 -0700, Roland McGrath wrote:
> Renzo Davoli brought up the issue of the order of callbacks to different
> engines for the same utrace event.  I know someone working on uprobes
> brought this up before (probably on the systemtap mailing list some time
> ago).

Yeah.  I think one concern was that when a breakpoint is hit, a utrace
client other than uprobes might see the SIGTRAP first and take some
unwarranted action because it thinks that the task is going to die.

> These issues lead to the idea of changing how report_quiesce and
> report_signal work.

I'm having trouble connecting all the dots in the discussion below.
Maybe if you provide clarifications on the indicated points, I can give
you better feedback.

> report_signal tells you "without intervention, user
> mode will resume from right here and do this".  Currently report_quiesce
> tells you that user mode might resume now if permitted, but also tells you
> at some various places just that user mode is not running right now and
> it's safe to look.  (At those latter, it's not about to get back to user
> mode (or terminate) without passing through some more event points, though
> it may be working and blocking nonquiescently before then.)

I don't understand the above sentence.  In particular, your use of
"though" puzzles me, and I'm not sure what you mean by "before then."
When is "then?"

> So perhaps
> rename report_signal to report_resume, and call it when dequeuing a signal
> and when dequeuing none and preparing to return to user mode after having
> stopped for QUIESCE.

What do you mean by "and when dequeuing none?"

> That is, it's called when there is the opportunity to
> decide the disposition of resuming (fatal or signal handler or normal).
> Then do away with utrace_inject_signal entirely.  The EVENT(SIGNAL_*) bits
> say an engine wants report_resume for those dispositions, EVENT(QUIESCE)
> says the engine wants it no matter what.

Would there still be a report_quiesce callback?  Would utrace call
report_quiesce when entering quiescence and report_resume when leaving

report_signal passes several signal-related args.  Would those also be
passed to report_resume?

> An engine uses QUIESCE to get the
> thread to call report_resume.  Then every interested engine gets the
> callback, and can see the disposition choice left by the last engine,

How?  Encoded in the args to report_resume?

> and
> whether it's been left in QUIESCE.  
> ...  
> I'd appreciate any feedback anyone has in any of these areas.
> Thanks,
> Roland

[Index of Archives]     [Kernel Discussion]     [Gimp]     [Yosemite News]

  Powered by Linux