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@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].
Thanks! This should be much better.
