Tapset for Signals....
Li Guanglei
guanglei@cn.ibm.com
Wed Aug 16 08:34:00 GMT 2006
Hi Josh,
Below are my questions while I am trying to add signal trace hooks
into LKET:
Stone, Joshua I wrote:
> * signal.send: I did a lot of digging for this to try to capture all of
> the paths where signals can be sent. The attached "send_signal.pdf"
> shows the callgraph as I found it. Those 4 marked in blue are the
> points that I chose to probe for "process.send_signal". The advantage
> to probing them separately is that I can expose a 'shared' variable that
> indicates whether the signal is going to a specific thread or the entire
> thread group. The functions marked in red are those that can generate
> STOP/KILL signals, which I haven't found a convenient way to probe
> (perhaps static markers?).
1. group_send_sig_info() will check the permissions for sending the
signal before calling __group_send_sig_info(). So probing
__group_send_sig_info() will omit the situation that a signal has been
actually sent out but was rejected due to wrong permission.
But __group_send_sig_info() will be also called by the following
functions besides group_send_sig_info(),:
1> do_notify_parent() when a process exits
2> check_process_timers() for POSIX timers
3> do_notify_parent_cldstop()
4> kill_proc_info_as_uid()
So which one do you prefer to probe, __group_send_sig_info or
group_send_sig_info?
2. send_sigqueue() and send_group_sigqueue() is only used for POSIX
timers. If we choose to probe them, then I think it's better to add a
local variable like "send_to_queue=1" to indicate that the signal is
generated by posix timers. Then by looking at "send_to_queue" and
"shared" local variables, we can determine which function actually
triggers the probe handler.
> * handle_stop_signal: Your comment says "fires when a stop signal is
> sent", but this is incorrect. This function is called to _check_
> whether this signal is a stop/cont, and if so take special action.
> Thus, this will get called for almost every signal, many of which will
> not be stop signals.
Yes. You are right. But the comment is still unchanged. :-)
>
> * syscall duplication: some of your probes are duplicating points from
> the syscall tapset (signal.syskill, etc.). Do we really need these? If
> you really want these, it would be preferable to make use of the syscall
> tapset, e.g.:
> probe signal.syskill = syscall.kill
Yes. Agree.
- Guanglei
More information about the Systemtap
mailing list