Re: [PATCH bpf-next v2 2/2] bpf: Add preempt disable for bpf_get_stackid

[Tao Chen]

在 2026/2/7 01:20, Andrii Nakryiko 写道:
> On Fri, Feb 6, 2026 at 1:07 AM Tao Chen <chen.dylane@xxxxxxxxx> 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@xxxxxxxxx>
> > ---
> >   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

Ok, I've tried to follow this approach to make the code clearer. Thanks.

> 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.
>
> [...]


--
Best Regards
Tao Chen