diff options
author | Yonghong Song <yhs@fb.com> | 2019-05-23 14:47:45 -0700 |
---|---|---|
committer | Daniel Borkmann <daniel@iogearbox.net> | 2019-05-24 23:26:47 +0200 |
commit | 8b401f9ed2441ad9e219953927a842d24ed051fc (patch) | |
tree | 50fa7aad59d5e95c7e18f3aa84e4271addbabbd7 /kernel/rseq.c | |
parent | 5420f3207759cd618a7b8a04a4eb5fc1c12b35cb (diff) | |
download | linux-8b401f9ed2441ad9e219953927a842d24ed051fc.tar.bz2 |
bpf: implement bpf_send_signal() helper
This patch tries to solve the following specific use case.
Currently, bpf program can already collect stack traces
through kernel function get_perf_callchain()
when certain events happens (e.g., cache miss counter or
cpu clock counter overflows). But such stack traces are
not enough for jitted programs, e.g., hhvm (jited php).
To get real stack trace, jit engine internal data structures
need to be traversed in order to get the real user functions.
bpf program itself may not be the best place to traverse
the jit engine as the traversing logic could be complex and
it is not a stable interface either.
Instead, hhvm implements a signal handler,
e.g. for SIGALARM, and a set of program locations which
it can dump stack traces. When it receives a signal, it will
dump the stack in next such program location.
Such a mechanism can be implemented in the following way:
. a perf ring buffer is created between bpf program
and tracing app.
. once a particular event happens, bpf program writes
to the ring buffer and the tracing app gets notified.
. the tracing app sends a signal SIGALARM to the hhvm.
But this method could have large delays and causing profiling
results skewed.
This patch implements bpf_send_signal() helper to send
a signal to hhvm in real time, resulting in intended stack traces.
Acked-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Yonghong Song <yhs@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Diffstat (limited to 'kernel/rseq.c')
0 files changed, 0 insertions, 0 deletions