Re: [Bug uprobes/11672] utrace_report_syscall_exit crash

[Mark Wielaard <mjw@redhat.com>]

On Mon, 2010-06-14 at 01:40 -0700, Roland McGrath wrote:
> >       (__stp_utrace_attach): Loop on -ERESTARTSYS after utrace_barrier.
> >       (__stp_utrace_task_finder_target_quiesce): Likewise.
> 
> That is a busy-wait loop, because -ERESTARTSYS means "signal is pending"
> and that stays true without any blocking until you let it get back to user
> mode (or almost, i.e. signal handling).  I don't really understand the
> context of where these functions get called.  I'm guessing it is in some
> control thread belonging to stapio or something like that.  In that case,
> the signal pending is a SIGINT killing stapio or something like that I
> suppose.  Is that the case?

This is called from the task finder cleanup code and the utrace probe
exit code before the module tries to unload. There could be some signals
involved since we might unload the module by forking, executing and
waiting for a child, runstap -d, process to do it (this might happen
when the stap process gets a ^C). It also happens when a script calls
exit(), or someone explicitly calls rmmod on us. Precise description can
be found in runtime/transport/transport.txt (SHUTDOWN AND UNLOADING).

> This is a relatively "safe" busy-wait.  utrace_barrier will return 0 when
> the tracee is all clear, not short-circuit because of signal_pending()
> unless it actually has to block.  It's waiting for the tracee on the other
> CPU to complete your callback, which should be pretty quick.  But it's
> still a busy-wait that suddenly chews CPU in a spurt, and all quite fragile.

Busy-waiting is bad, so if there is an alternative that would be nice.
All we need is that if after a utrace_control UTRACE_DETACH we get an
-EINPROGRESS that we can wait till we are sure any pending handlers have
finished and that the detach fully succeeded.

Thanks,

Mark