Re: [PATCH bpf-next v3] bpf: Remove redundant checks

[Feng Yang]

On Thu, 17 Apr 2025 17:52:45 +0800 Feng Yang wrote:
> > >         case BPF_FUNC_get_smp_processor_id:
> > >                 return &bpf_get_smp_processor_id_proto;
> >
> > this one should be cleaned up as well and
> > bpf_get_smp_processor_id_proto removed. All BPF programs either
> > disable CPU preemption or CPU migration, so bpf_base_func_proto's
> > implementation should work just fine (but please do it as a separate
> > patch)
> > 

> BPF_CALL_0(bpf_get_smp_processor_id)
> {
>	return smp_processor_id();
> }
> const struct bpf_func_proto bpf_get_smp_processor_id_proto = {
>	.func		= bpf_get_smp_processor_id,
>	.gpl_only	= false,
>	.ret_type	= RET_INTEGER,
>	.allow_fastcall	= true,
> };
> When attempting to remove bpf_get_smp_processor_id_proto,
> it was observed that bpf_get_smp_processor_id is extensively used.
> Should we also replace all instances of bpf_get_smp_processor_id with bpf_get_raw_cpu_id in these cases?
>
> For example:
> #define ___BPF_FUNC_MAPPER(FN, ctx...)			\
>        ......
>	FN(get_smp_processor_id, 8, ##ctx)		\

> samples/bpf/sockex3_kern.c:
> static struct globals *this_cpu_globals(void)
> {
>        u32 key = bpf_get_smp_processor_id();
>        return bpf_map_lookup_elem(&percpu_map, &key);
> }
> and so on......
> Thanks.

I think I understand the issue now: removing this bpf_get_smp_processor_id has no impact.

For the code:
 case BPF_FUNC_get_smp_processor_id:
    return &bpf_get_raw_smp_processor_id_proto;

This configuration allows bpf_get_smp_processor_id to actually invoke the bpf_get_raw_smp_processor_id_proto function implementation.
Thanks.