[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAADnVQ+WYLfoR1W6AsCJF6fNKEUgfxANXP01EQCJh1=99ZpoNw@mail.gmail.com>
Date: Tue, 22 Apr 2025 07:37:15 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Feng Yang <yangfeng59949@....com>
Cc: Andrii Nakryiko <andrii@...nel.org>, Alexei Starovoitov <ast@...nel.org>, bpf <bpf@...r.kernel.org>,
Daniel Borkmann <daniel@...earbox.net>, Eduard <eddyz87@...il.com>,
LKML <linux-kernel@...r.kernel.org>,
linux-trace-kernel <linux-trace-kernel@...r.kernel.org>,
Martin KaFai Lau <martin.lau@...ux.dev>, Network Development <netdev@...r.kernel.org>,
Song Liu <song@...nel.org>, Feng Yang <yangfeng@...inos.cn>,
Yonghong Song <yonghong.song@...ux.dev>
Subject: Re:
On Tue, Apr 22, 2025 at 1:04 AM Feng Yang <yangfeng59949@....com> wrote:
>
> Subject: Re: [PATCH bpf-next] bpf: Remove bpf_get_smp_processor_id_proto
>
> On Mon, 21 Apr 2025 18:53:07 -0700 Alexei Starovoitov <alexei.starovoitov@...il.com> wrote:
>
> > On Thu, Apr 17, 2025 at 8:41 PM Feng Yang <yangfeng59949@....com> wrote:
> > >
> > > From: Feng Yang <yangfeng@...inos.cn>
> > >
> > > All BPF programs either disable CPU preemption or CPU migration,
> > > so the bpf_get_smp_processor_id_proto can be safely removed,
> > > and the bpf_get_raw_smp_processor_id_proto in bpf_base_func_proto works perfectly.
> > >
> > > Suggested-by: Andrii Nakryiko <andrii.nakryiko@...il.com>
> > > Signed-off-by: Feng Yang <yangfeng@...inos.cn>
> > > ---
> > > include/linux/bpf.h | 1 -
> > > kernel/bpf/core.c | 1 -
> > > kernel/bpf/helpers.c | 12 ------------
> > > kernel/trace/bpf_trace.c | 2 --
> > > net/core/filter.c | 6 ------
> > > 5 files changed, 22 deletions(-)
> > >
> > > diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> > > index 3f0cc89c0622..36e525141556 100644
> > > --- a/include/linux/bpf.h
> > > +++ b/include/linux/bpf.h
> > > @@ -3316,7 +3316,6 @@ extern const struct bpf_func_proto bpf_map_peek_elem_proto;
> > > extern const struct bpf_func_proto bpf_map_lookup_percpu_elem_proto;
> > >
> > > extern const struct bpf_func_proto bpf_get_prandom_u32_proto;
> > > -extern const struct bpf_func_proto bpf_get_smp_processor_id_proto;
> > > extern const struct bpf_func_proto bpf_get_numa_node_id_proto;
> > > extern const struct bpf_func_proto bpf_tail_call_proto;
> > > extern const struct bpf_func_proto bpf_ktime_get_ns_proto;
> > > diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> > > index ba6b6118cf50..1ad41a16b86e 100644
> > > --- a/kernel/bpf/core.c
> > > +++ b/kernel/bpf/core.c
> > > @@ -2943,7 +2943,6 @@ const struct bpf_func_proto bpf_spin_unlock_proto __weak;
> > > const struct bpf_func_proto bpf_jiffies64_proto __weak;
> > >
> > > const struct bpf_func_proto bpf_get_prandom_u32_proto __weak;
> > > -const struct bpf_func_proto bpf_get_smp_processor_id_proto __weak;
> > > const struct bpf_func_proto bpf_get_numa_node_id_proto __weak;
> > > const struct bpf_func_proto bpf_ktime_get_ns_proto __weak;
> > > const struct bpf_func_proto bpf_ktime_get_boot_ns_proto __weak;
> > > diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> > > index e3a2662f4e33..2d2bfb2911f8 100644
> > > --- a/kernel/bpf/helpers.c
> > > +++ b/kernel/bpf/helpers.c
> > > @@ -149,18 +149,6 @@ const struct bpf_func_proto bpf_get_prandom_u32_proto = {
> > > .ret_type = RET_INTEGER,
> > > };
> > >
> > > -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,
> > > -};
> > > -
> >
> > bpf_get_raw_smp_processor_id_proto doesn't have
> > allow_fastcall = true
> >
> > so this breaks tests.
> >
> > Instead of removing BPF_CALL_0(bpf_get_smp_processor_id)
> > we should probably remove BPF_CALL_0(bpf_get_raw_cpu_id)
> > and adjust SKF_AD_OFF + SKF_AD_CPU case.
> > I don't recall why raw_ version was used back in 2014.
> >
>
> The following two seem to explain the reason:
> https://lore.kernel.org/all/7103e2085afa29c006cd5b94a6e4a2ac83efc30d.1467106475.git.daniel@iogearbox.net/
> https://lore.kernel.org/all/02fa71ebe1c560cad489967aa29c653b48932596.1474586162.git.daniel@iogearbox.net/
>
Ahh. socket filters run in RCU CS. They don't disable preemption or migration.
Then let's keep things as-is.
We still want debugging provided by smp_processor_id().
If we switch everything to raw_ may miss things. Like this example with
socket filters.
Powered by blists - more mailing lists