[dtrace-discuss] Asynchronous signal handling in fasttrap provider

[Adam Leventhal]

Recall that displaced execution refers to relocating the original instruction
to memory at a different location.

There are some possibilities for exactly what memory we use for thes
displaced instructions. One option is that the kernel could allocate memory
on the process's behalf by mapping memory into the process; we could then
have scratch space for every traced instruction.  This would work (and was
seriously explored at one point), but mapping memory on a process's behalf
is a serious pain and at least a little rude (no matter what door_call(3C)
tells you).

We observed that a given thread can only be executing one instruction at any
given moment so we reserved a part of the per thread structure (ulwp_t) to
hold our displaced instructions. There was, however, a catch. When a thread is
interrupted by a signal and there's an associated signal handler, that
thread's execution will be diverted to the handler; when the handler is
done, executing returns to the interrupted instruction. If that instruction
was in the per-thread scratch space, it would be possible for that scratch
space to have been overwritten if a traced instruction was executed from
the signal handler. In other words, a given thread can have multiple contexts
active each of which could be executing from the scratch space.

To resolve this problem, we needed to make sure that the interrupted context
wouldn't return to the displaced instruction scratch space. For synchronous
signals -- ones caused by the executed instruction itself -- we simply back
up the program counter so that the same instruction would be executed again.
For asynchronous signals -- ones caused by some external activity -- we defer
their reception until after the thread has exited the per-thread scratch
space, and it's fine to defer this signals briefly since there are no
guarantees about when exactly they'll be handled.

To see the code that deals with signals and the pid provider look for
dtrace_safe_synchronous_signal() for synchronous signals, and for
dtrace_safe_defer_signal() for asynchronous signals (for the curious,
the 'dtrace_safe_' prefix indicates that the function is associated with
DTrace, but can safely be traced by the fbt provider).

If, by some fluke, you think this was an overly terse response, check out
this presentation where I delved into some the implementation details of
the pid provider:

  http://blogs.sun.com/ahl/entry/pid_provider_exposed

Adam

On Wed, Feb 14, 2007 at 10:11:50AM +0900, Saravanan S wrote:
> Hi,
> 
> I was going through the implementation of the fasttrap provider. I found
> that when displaced execution happens (ie., when the instruction traced is
> being executed out of the scratch space) if an asynchrnous signal comes we
> need to defer the delivery.
> 
> Can somebody explain why this is necessary and how is it implemented?
> 
> Thanks in advance
> Saravanan S

> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org

-- 
Adam Leventhal, Solaris Kernel Development       http://blogs.sun.com/ahl