Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement signal #967

Merged
merged 5 commits into from Nov 19, 2019
Merged

Implement signal #967

merged 5 commits into from Nov 19, 2019

Conversation

fbs
Copy link
Contributor

@fbs fbs commented Nov 13, 2019

This adds new call, signal, which makes use of bpf_send_signal. It supports both signals by name and by number, e.g.:

# bpftrace  -e 'kprobe:__x64_sys_execve /comm == "bash"/ { signal("ABRT"); }' --unsafe
$ ls
Hangup

Fixes #693

@brendangregg
Copy link
Contributor

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.:

/*
 * TODO: auto-generate these mappings, especially to support other kernnels.
 */

@fbs fbs force-pushed the 693_send_signal branch 2 times, most recently from 7172812 to a8381aa Compare November 18, 2019 20:56
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.
@fbs
Copy link
Contributor Author

fbs commented Nov 18, 2019

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.:

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).

@brendangregg
Copy link
Contributor

Tested, works, thanks. Here's my new go-fast tool:

# bpftrace --unsafe -e 't:syscalls:sys_enter_nanosleep /comm == "sleep"/ { signal("TERM"); printf("PID %d terminated\n", pid); }'
Attaching 1 probe...
PID 31638 terminated
^C

@brendangregg brendangregg merged commit 435086e into bpftrace:master Nov 19, 2019
@fbs fbs deleted the 693_send_signal branch February 25, 2020 09:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

support for bpftrace_send_signal
2 participants