newly created engine immediately notified of exec already in progress

[Roland McGrath]

> The current implementation is that if I create a new engine in response
> to an exec (when called from some other engine's report_exec callback),
> and set that engine's flags to be notified of execs, the new engine gets
> notified of the exec that's already underway.  This turns out to be
> rather inconvenient for uprobes, but is it counterintuitive?

To clarify, this is not specific to exec.  Every kind of event callback
constitutes what I call a "reporting pass", and they all behave the same.
A normal reporting pass is the loop across all engines, in which interested
ones get first a report_quiesce(eventbit) and then a report_event().  
A resume reporting pass is the similar loop where engines get either just
report_quiesce(0) or just report_signal().

The question is what happens in the current reporting pass when a callback
attaches a new engine to current and sets its event mask to include the
event that elicited this reporting pass.

The current behavior is that the new engine goes immediately on the end of
the list of engines to get callbacks, so the reporting pass already in
progress will later get to all the new engines before it's done.

The alternative behavior would be that any new engines attached after a
reporting pass has begun will not be included in that pass.  They will be
included in the next reporting pass of any kind.  A side effect is that if
there was not going to be any other report before returning to user mode,
there will be a resume reporting pass (that the new engine will see).
That is the same effect of utrace_control(UTRACE_REPORT) being done when
the utrace_attach_task() is done.

Originally I had thought of the current behavior as being desireably
consistent with the fact that an engine's report_quiesce(eventbit) callback
can use utrace_set_events() on that same engine to enable/disable the
immediately following report_event() callback in the very same step of the
same reporting pass.

But another way to look at it is that any utrace_attach_task() call from
any other task behaves this (alternative) way.  That is, if some reporting
pass has already begun, the new engine is not included, but a UTRACE_REPORT
is done instead to get the new engine fully signed on "soon".  So it would
be simply consistent for any attach made during a reporting pass
(synchronously or asynchronously) not to take effect during that same pass.

I was musing about adding a UTRACE_ATTACH_* flag bit to let you select the
behavior.  But that seems overly fiddly for no good reason.

So I don't mind changing this as Jim prefers.  The actual change is simple,
just remove the "splice_attaching" case from utrace_attach_task.

Jim, can you look through the kerneldoc comments and the Documentation/
files and cite any places where the description of this behavior now needs
to be corrected or explained more clearly and explicitly?


Thanks,
Roland