extended bpf_send_signal_thread with argument

* extended bpf_send_signal_thread with argument
@ 2021-01-31 11:14 Dmitry Vyukov
  2021-02-01  9:22 ` Peter Zijlstra
  0 siblings, 1 reply; 4+ messages in thread
From: Dmitry Vyukov @ 2021-01-31 11:14 UTC (permalink / raw)
  To: Steven Rostedt, Ingo Molnar, Alexei Starovoitov, Daniel Borkmann,
	andrii, Martin KaFai Lau, David Miller, kpsingh, John Fastabend,
	netdev, bpf, LKML, Peter Zijlstra

Hi,

I would like to send a signal from a bpf program invoked from a
perf_event. There is:

// kernel/trace/bpf_trace.c
BPF_CALL_1(bpf_send_signal_thread, u32, sig)

which is nice, but it does not allow me to pass any arguments.
I can use a bpf map indexed by pid to "pass" some additional info, but
it's messy and slow (and may cause some synchronization issues, I am
not sure yet).

Signals allow to pass additional arguments, it would be nice to expose
this to bpf programs as well. Any objections? Do you see any potential
issues with this? On the implementation side it seems to be almost
trivial to add something like this:

BPF_CALL_2(bpf_send_signal_thread_ex, u32, sig, uintptr_t sival)

However, siginfo_t is way larger and allows to pass a whole lot of
info, and the latest user-space APIs pidfd_send_signal just directly
accepts siginfo_t (and rt_tgsigqueueinfo as well). But I am not sure
how to expose it according to bpf rules. Could we do something like
(pass whatever you want, it's your business)?

BPF_CALL_2(bpf_send_signal_thread_ex, u32, sig, char siginfo[sizeof(siginfo_t)])

Does it make sense? If yes, what would be the best way to expose this?

Thanks

^ permalink raw reply	[flat|nested] 4+ messages in thread