Re: [Bug uprobes/11672] utrace_report_syscall_exit crash

[Mark Wielaard <mjw@redhat.com>]

On Mon, 2010-06-14 at 09:58 -0700, Roland McGrath wrote:
> > This is called from the task finder cleanup code and the utrace probe
> > exit code before the module tries to unload. 
> 
> From a quick glance I'm still not really clear on the important question:
> what thread is current when calling into this code?

I think it depends on which method of exiting/unloading is being used.
As far as I understand the code this is called from the proc transport
on response to an exit packet being writen to our .cmd file. Otherwise
it is done through DECLARE_DELAYED_WORK, but I am not completely sure
how that works. Maybe someone who hacked on the transport layer can
explain the precise interactions.

> > 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.
> 
> As I said, utrace_barrier is that except that it's a busy-wait if
> signal_pending().  The alternative requires changing your model such that
> any waiting is via your own synchronization with your ops->release
> function.

OK, thanks. The current solution seems to make things more stable (I am
unable to trigger any crashes anymore). Lets not rewrite the whole
synchronization just for this small possibility of a busy wait. Unless
someone else wants to of course.

Cheers,

Mark