Re: [PATCH bpf-next v2 4/8] bpf: Add kfunc bpf_rcu_read_lock/unlock()

[Yonghong Song <yhs@meta.com>]

On 11/8/22 9:09 AM, Kumar Kartikeya Dwivedi wrote:
> On Tue, Nov 08, 2022 at 01:11:09PM IST, Yonghong Song wrote:
>> Add two kfunc's bpf_rcu_read_lock() and bpf_rcu_read_unlock(). These two kfunc's
>> can be used for all program types. A new kfunc hook type BTF_KFUNC_HOOK_GENERIC
>> is added which corresponds to prog type BPF_PROG_TYPE_UNSPEC, indicating the
>> kfunc intends to be used for all prog types.
>>
>> The kfunc bpf_rcu_read_lock() is tagged with new flag KF_RCU_LOCK and
>> bpf_rcu_read_unlock() with new flag KF_RCU_UNLOCK. These two new flags
>> are used by the verifier to identify these two helpers.
>>
>> Signed-off-by: Yonghong Song <yhs@fb.com>
>> ---
>>   include/linux/bpf.h  |  3 +++
>>   include/linux/btf.h  |  2 ++
>>   kernel/bpf/btf.c     |  8 ++++++++
>>   kernel/bpf/helpers.c | 25 ++++++++++++++++++++++++-
>>   4 files changed, 37 insertions(+), 1 deletion(-)
>>
>> For new kfuncs, I added KF_RCU_LOCK and KF_RCU_UNLOCK flags to
>> indicate a helper could be bpf_rcu_read_lock/unlock(). This could
>> be a waste for kfunc flag space as the flag is used to identify
>> one helper. Alternatively, we might identify kfunc based on
>> btf_id. Any suggestions are welcome.
>>
> 
> It can be done similar to this change:
> https://lore.kernel.org/bpf/20221107230950.7117-17-memxor@gmail.com
> So compare meta.func_id to special_kfunc_list[KF_bpf_rcu_read_lock].

Thanks! This should be much better.