[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAEf4BzZwvAUgLwz-M0Y_NJLTmedyY9U6s7LrSmn751hQdTP4Uw@mail.gmail.com>
Date: Fri, 6 Feb 2026 09:20:24 -0800
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Tao Chen <chen.dylane@...ux.dev>
Cc: song@...nel.org, jolsa@...nel.org, ast@...nel.org, daniel@...earbox.net,
andrii@...nel.org, martin.lau@...ux.dev, eddyz87@...il.com,
yonghong.song@...ux.dev, john.fastabend@...il.com, kpsingh@...nel.org,
sdf@...ichev.me, haoluo@...gle.com, bpf@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH bpf-next v2 2/2] bpf: Add preempt disable for bpf_get_stackid
On Fri, Feb 6, 2026 at 1:07 AM Tao Chen <chen.dylane@...ux.dev> wrote:
>
> The get_perf_callchain() return values may be reused if a task is preempted
> after the BPF program enters migrate disable mode, so we should add
> preempt_disable.
> The get build-id offset in __bpf_get_stackid may increase the length
> of the preempt disabled section. Luckily, it is safe to enable preempt
> after perf callchain ips copied to BPF map bucket memory, so we can enable
> preempt before stack_map_get_build_id_offset.
>
> Signed-off-by: Tao Chen <chen.dylane@...ux.dev>
> ---
> kernel/bpf/stackmap.c | 84 +++++++++++++++++++++++++++----------------
> 1 file changed, 53 insertions(+), 31 deletions(-)
>
Let's take a step back and look at the bigger picture. This whole
trace_in thing is still problematic because one way or another we do
get perf_callchain_entry, which *needs* preemption disable. So we need
to refactor __bpf_get_stackid() in such a way that we can do all these
steps separately:
a) get stackmap entry (pcpu_freelist_pop parts)
b) (under disabled preemption) get temporary per-cpu callchain_entry
and copy its IPs into stackmap entry
c) (now with preemption enabled) perform build ID fetch and transformation
Current logic is too coupled together to allow this, but conceptually
there is nothing preventing us from breaking __bpf_get_stackid() (and
see my replies in previous email, we should do similar breakup for
__bpf_get_stack) into few separate steps.
We have to do this to make all of this work in all the combinations of
sleepable/non-sleepable and with/without build id, IMO.
Take your time, don't rush, think this through. This is a bit of a
maze of code, we should untangle it properly, not hack our way through
it.
[...]
Powered by blists - more mailing lists