Re: Tapset for Signals....

[Li Guanglei <guanglei at cn dot ibm dot com>]

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