Re: [PATCH v3] bpf: Fix smp_processor_id() call trace for preemptible kernels

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Wrapping the entire batch operation in `bpf_disable_instrumentation()` elevates `bpf_prog_active` for an unbounded duration, leaking the state across preemption and blinding BPF tracing globally on the CPU.
--

commit 121a3f2517b4814c567c049b787ed0317746073a
Author: Edward Adam Davis <eadavis@qq.com>

bpf: Fix smp_processor_id() call trace for preemptible kernels

This commit addresses an smp_processor_id() warning in preemptible context by
wrapping the batch loop with bpf_disable_instrumentation() and
bpf_enable_instrumentation().

Closes: https://syzkaller.appspot.com/bug?extid=fd7e415d891073b83e1f

> diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
> index 9f394e1aa2e85..d3f2f8a379e86 100644
> --- a/kernel/bpf/hashtab.c
> +++ b/kernel/bpf/hashtab.c
> @@ -3299,6 +3299,7 @@ static int __rhtab_map_lookup_and_delete_batch(struct bpf_map *map,
>  	dst_val = values;
>  	total = 0;
>  
> +	bpf_disable_instrumentation();
>  	rcu_read_lock();

[Severity: High]
Does wrapping this batch operation in bpf_disable_instrumentation() risk
blinding BPF tracing globally on the CPU if preemption occurs?

bpf_disable_instrumentation() increments the per-CPU bpf_prog_active counter.
Because migrate_disable() and rcu_read_lock() do not disable preemption under
CONFIG_PREEMPT_RCU, the task can be preempted during this potentially long
loop.

If preempted, bpf_prog_active would remain elevated on that CPU, which could
cause subsequent tasks scheduled on the same CPU to silently drop BPF tracing
events (kprobes, tracepoints, perf).

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/tencent_4F9E5F1B854B1D1BB42574BA76BB5133BF08@qq.com?part=1