diff options
| author | Aditya Sharma <adi.sharma@zohomail.in> | 2026-10-01 12:54:49 +0530 |
|---|---|---|
| committer | Alexei Starovoitov <ast@kernel.org> | 2026-10-24 04:00:57 +0000 |
| commit | 2c79610f72bb880cbb42adacec5a4b1b335040bf (patch) | |
| tree | 52567a5ee852dd9593022a8864ff945772bcb90a /include/linux/timerqueue.h | |
| parent | 93bd472336ac2424f5f3cf05cbb24e02242343b7 (diff) | |
selftests/bpf: Test bpf_send_signal_task() from kernel thread context
The existing send_signal tests, including the _remote variants that
exercise bpf_send_signal_task() with a caller-supplied target, all
gate on
if ((bpf_get_current_pid_tgid() >> 32) == pid)
so the BPF program only ever runs while current is the test process.
The caller-context dimension is therefore untested, which is how
bpf_send_signal_task() failing from kernel thread context went
unnoticed.
Add a program attached to tp_btf/workqueue_execute_start, where
current is always a kworker. It cannot filter on current, so it is
driven by target_pid and gated on a kworker_test flag that only this
test sets, and the test asserts the child receives the signal.
Setting pid to 0 leaves the pre-existing programs in the skeleton
inert. Workqueues run on their own, so nothing has to be triggered
from userspace.
Without removing the nmi_uaccess_okay() check, this test fails on x86.
Signed-off-by: Aditya Sharma <adi.sharma@zohomail.in>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://patch.msgid.link/20261001072449.1377267-3-adi.sharma@zohomail.in
Diffstat (limited to 'include/linux/timerqueue.h')
0 files changed, 0 insertions, 0 deletions
