This is the mail archive of the mailing list for the systemtap project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Tapset for Signals....

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]