Re: [PATCH bpf-next v5 1/4] bpf: Add bpf_call_rcu() kfunc

["Alexei Starovoitov" <alexei.starovoitov@gmail.com>]

On Tue Sep 22, 2026 at 2:17 PM UTC, Puranjay Mohan wrote:
>> > +     prog = bpf_prog_inc_not_zero(aux->prog);
>> > +     if (IS_ERR(prog)) {
>> > +             WRITE_ONCE(rhk->armed, 0);
>> > +             return -EBADF;
>> > +     }
>>
>> can we drop prog_inc and remove prog pointer from rhk ?
>> with something like if (prog->has_call_rcu) rcu_barrier() during prog unload?
>
> That could work but we would need more than just the calls to
> rcu_barrier_tasks_trace() and/or  rcu_barrier(). As the rcu_barrier
> only waits for callbacks enqueued before it was called, the registered
> callback and re-queue itself and cause problems. So, we would need a
> flag that is set before the call to rcu_barrier() which stops further
> queueing of callbacks from that program. Also, assuming we add these
> barrier calls in bpf_prog_free_deferred() which is runs from
> system_percpu_wq, it could make this run for much longer than
> expected. What is the motivation for using rcu_barrier() instead of
> bpf_prog_inc_not_zero()? is it the 8B pointer in rhk or the atomic
> operation in bpf_prog_inc_not_zero()?

ok. fair enough. let's keep prog inc.

>> > That avoids an allocation and a state machine on the arming path at the
>> > cost of 64 bytes per element, 48 of which are used today.

What was the thinking here? Why ask all progs to waste 16 bytes
for future extensibility that may never happen?
If rcu_head growth we can switch to dynamic alloc while
keeping the struct at 48 bytes.

I feel it's a better trade off.

pw-bot: cr