From: Mykyta Yatsenko <mykyta.yatsenko5@gmail.com>
To: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Cc: bpf@vger.kernel.org, ast@kernel.org, andrii@kernel.org,
daniel@iogearbox.net, kafai@meta.com, kernel-team@meta.com,
eddyz87@gmail.com, Mykyta Yatsenko <yatsenko@meta.com>
Subject: Re: [PATCH bpf-next v6 0/6] bpf: Add support for sleepable tracepoint programs
Date: Tue, 24 Mar 2026 22:20:41 +0000 [thread overview]
Message-ID: <871ph8kgxy.fsf@gmail.com> (raw)
In-Reply-To: <CAP01T74asfp5DY+wFd6pDVpSsiuPxjPaPE8iaFaczBUHe0BERw@mail.gmail.com>
Kumar Kartikeya Dwivedi <memxor@gmail.com> writes:
> On Tue, 24 Mar 2026 at 20:03, Mykyta Yatsenko
> <mykyta.yatsenko5@gmail.com> wrote:
>>
>> This series adds support for sleepable BPF programs attached to raw
>> tracepoints (tp_btf), classic raw tracepoints (raw_tp), and classic
>> tracepoints (tp). The motivation is to allow BPF programs on syscall
>> tracepoints to use sleepable helpers such as bpf_copy_from_user(),
>> enabling reliable user memory reads that can page-fault.
>>
>> This series removes restriction for faultable tracepoints:
>>
>> Patch 1 modifies __bpf_trace_run() to support sleepable programs
>> following the uprobe_prog_run() pattern: use explicit
>> rcu_read_lock_trace() for sleepable programs and rcu_read_lock() for
>> non-sleepable programs. Also removes preempt_disable from the faultable
>> tracepoint BPF callback wrapper, since migration protection and RCU
>> locking are now managed per-program inside __bpf_trace_run().
>>
>> Patch 2 renames bpf_prog_run_array_uprobe() to
>> bpf_prog_run_array_sleepable() to support new usecase.
>>
>> Patch 3 adds sleepable support for classic tracepoints
>> (BPF_PROG_TYPE_TRACEPOINT) by introducing trace_call_bpf_faultable()
>> and restructuring perf_syscall_enter/exit() to run BPF programs in
>> faultable context before the preempt-disabled per-cpu buffer
>> allocation. trace_call_bpf_faultable() uses rcu_tasks_trace for
>> lifetime protection, following the uprobe pattern. This adds
>> rcu_tasks_trace overhead for all classic tracepoint BPF programs on
>> syscall tracepoints, not just sleepable ones.
>>
>> Patch 4 allows BPF_TRACE_RAW_TP, BPF_PROG_TYPE_RAW_TRACEPOINT, and
>> BPF_PROG_TYPE_TRACEPOINT programs to be loaded as sleepable, with
>> load-time and attach-time checks to reject sleepable programs on
>> non-faultable tracepoints.
>>
>> Patch 5 adds libbpf SEC_DEF handlers: tp_btf.s, raw_tp.s,
>> raw_tracepoint.s, tp.s, and tracepoint.s.
>>
>> Patch 6 adds selftests covering tp_btf.s, raw_tp.s, and tp.s positive
>> cases using bpf_copy_from_user() on sys_enter nanosleep, plus negative
>> tests for non-faultable tracepoints.
>>
>> Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com>
>> ---
>> Changes in v6:
>> - Remove recursion check from trace_call_bpf_faultable(), sleepable
>> tracepoints are called from syscall enter/exit, no recursion is
>> possible.(Kumar)
>
> Is this true? Can't the same program reenter due to the same syscall
> from a different task which preempted the task running the previous
> program?
> Just asking because it wasn't clear to me, since we discussed
> bpf_prog_get_recursion_context() instead.
>
Good question, this is my understanding, though I'm not 100% confident:
There are 2 mechanisms we discussed:
* bpf_prog_get_recursion_context() - per program recursion guard, I
understand this is used to prevent self-recursion, where BPF program
infinitely generates calls to itself.
* bpf_prog_active - per CPU counter used to prevent deadlock between
instrumentation BPF prog (tracepoint, kprobe) and map operation
generating an event triggering those BPF progs when holding map bucket
spinlock.
I suggest that none of these applies for the usecase, because we open
sleepable only for syscall enter/exit:
* Deadlock on the map bucket spinlock is not possible (bpf_prog_active)
* BPF program can't generate another syscall enter/exit - no infinite
recursion (bpf_prog_get_recursion_context())
As for the situation that you describe: same program reenter due to the
same syscall from a different task which preempted the task running the
previous - this is normally supported, behaviour - similar to what
we have when NMI runs on the same CPU and calls common BPF subprog, or
two tasks schedule sleepable bpf_task_works callbacks, that can
interleave on the same CPU.
Let me know if my understanding is not correct. Thanks for checking this
series!
>> [...]
next prev parent reply other threads:[~2026-03-24 22:20 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-24 19:03 [PATCH bpf-next v6 0/6] bpf: Add support for sleepable tracepoint programs Mykyta Yatsenko
2026-03-24 19:03 ` [PATCH bpf-next v6 1/6] bpf: Add sleepable support for raw " Mykyta Yatsenko
2026-03-24 19:46 ` Alexei Starovoitov
2026-03-24 22:25 ` Mykyta Yatsenko
2026-03-24 19:03 ` [PATCH bpf-next v6 2/6] bpf: Rename bpf_prog_run_array_uprobe() to bpf_prog_run_array_sleepable() Mykyta Yatsenko
2026-03-24 19:03 ` [PATCH bpf-next v6 3/6] bpf: Add sleepable support for classic tracepoint programs Mykyta Yatsenko
2026-03-24 19:56 ` Alexei Starovoitov
2026-03-24 19:03 ` [PATCH bpf-next v6 4/6] bpf: Verifier support for sleepable " Mykyta Yatsenko
2026-03-24 19:03 ` [PATCH bpf-next v6 5/6] libbpf: Add section handlers for sleepable tracepoints Mykyta Yatsenko
2026-03-24 19:03 ` [PATCH bpf-next v6 6/6] selftests/bpf: Add tests for sleepable tracepoint programs Mykyta Yatsenko
2026-03-24 20:05 ` [PATCH bpf-next v6 0/6] bpf: Add support " Kumar Kartikeya Dwivedi
2026-03-24 22:20 ` Mykyta Yatsenko [this message]
2026-03-24 23:57 ` Alexei Starovoitov
2026-03-24 23:59 ` Alexei Starovoitov
-- strict thread matches above, loose matches on Subject: below --
2026-03-25 18:55 Mykyta Yatsenko
2026-03-26 16:52 ` Kumar Kartikeya Dwivedi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871ph8kgxy.fsf@gmail.com \
--to=mykyta.yatsenko5@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=kafai@meta.com \
--cc=kernel-team@meta.com \
--cc=memxor@gmail.com \
--cc=yatsenko@meta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.