Implement signal
#967
Implement signal
#967
Conversation
|
Looks awesome, thanks. While a lot of files have changed, adding a function like this shouldn't be too problematic, as most programs don't use it. Why are the number mappings hardcoded, like SIGKILL to 9? For other kernels the mappings are different (and one day, eBPF will be available on other kernels). I'm ok with putting a block comment above those points as a reminder to fix this later on, e.g.: |
fbs
force-pushed
the
693_send_signal
branch
2 times, most recently
from
7172812
to
a8381aa
Compare
This wraps the `bpf_send_signal` bpf helper that allows you to send a `signal(7)` to the current task. To keep the code simple the return code from signal is currently ignored, also making it impossible to use `signal` in an assignment. If the need arises it should be relatively easy to provide access to the return code.
As it can `SIGKILL` processes it is unsafe.
As this feature requires kernel 5.3 I've omitted the runtime tests. Almost no one will be able to run them.
This allows the use of common signal names, like SIGKILL or KILL, instead of having to remember the right ID. As IDs are arch specific (see `signal(7)`) the use of string literals also improve script portability a bit. The implementation differs in that it takes a string literal as argument which is translated into an int during codegen. This avoid introducing a set of global identifiers (like enums) that can be used in places that do not make sense.
Good point. I've updated it, using the #defines from signal.h which actually simplified it a bit (assuming all posix signals are available on all our targets). |
|
Tested, works, thanks. Here's my new go-fast tool: |
This adds new call,
signal, which makes use ofbpf_send_signal. It supports both signals by name and by number, e.g.:Fixes #693