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@xxxxxx> > --- > 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@xxxxxxxxx So compare meta.func_id to special_kfunc_list[KF_bpf_rcu_read_lock].
