From: Mykyta Yatsenko <mykyta.yatsenko5@gmail.com>
To: bot+bpf-ci@kernel.org, bpf@vger.kernel.org, ast@kernel.org,
andrii@kernel.org, daniel@iogearbox.net, kafai@meta.com,
kernel-team@meta.com, eddyz87@gmail.com, memxor@gmail.com,
peterz@infradead.org, rostedt@goodmis.org
Cc: yatsenko@meta.com, martin.lau@kernel.org,
yonghong.song@linux.dev, clm@meta.com, ihor.solodrai@linux.dev
Subject: Re: [PATCH bpf-next v13 3/6] bpf: Add sleepable support for classic tracepoint programs
Date: Thu, 23 Apr 2026 14:42:38 +0100 [thread overview]
Message-ID: <a340164a-3e83-403b-aa7d-3bd65b861ee0@gmail.com> (raw)
In-Reply-To: <869b8823e672ed52c7cca6ed2d188130f66cb23cb0be1d6f821247b7f6d7da99@mail.kernel.org>
On 4/22/26 9:57 PM, bot+bpf-ci@kernel.org wrote:
>> diff --git a/kernel/trace/trace_syscalls.c b/kernel/trace/trace_syscalls.c
>> index 8ad72e17d8eb..e98ee7e1e66f 100644
>> --- a/kernel/trace/trace_syscalls.c
>> +++ b/kernel/trace/trace_syscalls.c
>
> [ ... ]
>
>> @@ -1410,12 +1410,7 @@ static void perf_syscall_enter(void *ignore, struct pt_regs *regs, long id)
>> int size = 0;
>> int uargs = 0;
>>
>> - /*
>> - * Syscall probe called with preemption enabled, but the ring
>> - * buffer and per-cpu data require preemption to be disabled.
>> - */
>> might_fault();
>> - guard(preempt_notrace)();
>>
>> syscall_nr = trace_get_syscall_nr(current, regs);
>> if (syscall_nr < 0 || syscall_nr >= NR_syscalls)
>> @@ -1429,6 +1424,26 @@ static void perf_syscall_enter(void *ignore, struct pt_regs *regs, long id)
>>
>> syscall_get_arguments(current, regs, args);
>>
>> + /*
>> + * Run BPF program in faultable context before per-cpu buffer
>> + * allocation, allowing sleepable BPF programs to execute.
>> + */
>> + valid_prog_array = bpf_prog_array_valid(sys_data->enter_event);
>> + if (valid_prog_array &&
>> + !perf_call_bpf_enter(sys_data->enter_event, sys_data,
>> + syscall_nr, args))
>> + return;
>> +
>> + /*
>> + * Per-cpu ring buffer and perf event list operations require
>> + * preemption to be disabled.
>> + */
>> + guard(preempt_notrace)();
>> +
>> + head = this_cpu_ptr(sys_data->enter_event->perf_events);
>> + if (hlist_empty(head))
>> + return;
>> +
>
> Could this lead to unnecessary buffer allocation in a race scenario?
>
> The patch moves BPF execution before preempt_disable to enable sleepable
> programs. The new code checks valid_prog_array outside preempt_disable
> and runs BPF if true. Then it enters preempt_disable and checks if the
> hlist is empty.
>
> Between the BPF check (outside preempt_disable) and the hlist check
> (inside preempt_disable), another CPU could unregister the last perf
> event, making the hlist empty. In this window, the code would:
>
> 1. Run BPF and pass the filter (before preempt_disable)
> 2. Check valid_prog_array and find it true (before preempt_disable)
> 3. Enter preempt_disable via guard(preempt_notrace)()
> 4. Check hlist_empty(head) and find it false (inside preempt_disable)
> 5. Allocate buffer via perf_trace_buf_alloc()
> 6. Submit to an empty or nearly-empty hlist
>
> The old code checked both conditions together under preempt_disable
> before buffer allocation:
>
> head = this_cpu_ptr(sys_data->enter_event->perf_events);
> valid_prog_array = bpf_prog_array_valid(sys_data->enter_event);
> if (!valid_prog_array && hlist_empty(head))
> return; /* Early exit before buffer allocation */
>
> If the perf event is unregistered between the new code's BPF execution
> and the hlist check, would the buffer allocation and data copying be
> wasted work?
>
Given that the downside is wasted work of allocation and data copy,
it's not necessarily a problem, because it's not a hot path.
> [ ... ]
>
>
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
>
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/24799223877
next prev parent reply other threads:[~2026-04-23 13:42 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-22 19:41 [PATCH bpf-next v13 0/6] bpf: Add support for sleepable tracepoint programs Mykyta Yatsenko
2026-04-22 19:41 ` [PATCH bpf-next v13 1/6] bpf: Add sleepable support for raw " Mykyta Yatsenko
2026-04-22 19:41 ` [PATCH bpf-next v13 2/6] bpf: Add bpf_prog_run_array_sleepable() Mykyta Yatsenko
2026-04-22 19:41 ` [PATCH bpf-next v13 3/6] bpf: Add sleepable support for classic tracepoint programs Mykyta Yatsenko
2026-04-22 20:57 ` bot+bpf-ci
2026-04-23 13:42 ` Mykyta Yatsenko [this message]
2026-04-22 23:35 ` sashiko-bot
2026-04-23 13:38 ` Mykyta Yatsenko
2026-04-22 19:41 ` [PATCH bpf-next v13 4/6] bpf: Verifier support for sleepable " Mykyta Yatsenko
2026-04-22 19:41 ` [PATCH bpf-next v13 5/6] libbpf: Add section handlers for sleepable tracepoints Mykyta Yatsenko
2026-04-22 19:41 ` [PATCH bpf-next v13 6/6] selftests/bpf: Add tests for sleepable tracepoint programs Mykyta Yatsenko
2026-04-22 20:30 ` bot+bpf-ci
2026-04-22 20:37 ` Mykyta Yatsenko
2026-04-22 20:49 ` Kumar Kartikeya Dwivedi
2026-04-22 21:00 ` [PATCH bpf-next v13 0/6] bpf: Add support " patchwork-bot+netdevbpf
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=a340164a-3e83-403b-aa7d-3bd65b861ee0@gmail.com \
--to=mykyta.yatsenko5@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bot+bpf-ci@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=clm@meta.com \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=ihor.solodrai@linux.dev \
--cc=kafai@meta.com \
--cc=kernel-team@meta.com \
--cc=martin.lau@kernel.org \
--cc=memxor@gmail.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=yatsenko@meta.com \
--cc=yonghong.song@linux.dev \
/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.