[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMB2axO3E30y2862=uMH-S-_KvCzsWyEfBK7gntgF0gyyVZg2g@mail.gmail.com>
Date: Tue, 6 Jan 2026 11:42:55 -0800
From: Amery Hung <ameryhung@...il.com>
To: Jakub Sitnicki <jakub@...udflare.com>
Cc: Alexei Starovoitov <alexei.starovoitov@...il.com>, Martin KaFai Lau <martin.lau@...ux.dev>,
Martin KaFai Lau <martin.lau@...nel.org>, bpf <bpf@...r.kernel.org>,
Network Development <netdev@...r.kernel.org>, "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>,
Jesper Dangaard Brouer <hawk@...nel.org>, John Fastabend <john.fastabend@...il.com>,
Stanislav Fomichev <sdf@...ichev.me>, Simon Horman <horms@...nel.org>, Andrii Nakryiko <andrii@...nel.org>,
Eduard Zingerman <eddyz87@...il.com>, Song Liu <song@...nel.org>,
Yonghong Song <yonghong.song@...ux.dev>, KP Singh <kpsingh@...nel.org>,
Hao Luo <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>,
kernel-team <kernel-team@...udflare.com>
Subject: Re: [PATCH bpf-next v2 15/16] bpf: Realign skb metadata for TC progs
using data_meta
On Tue, Jan 6, 2026 at 11:12 AM Jakub Sitnicki <jakub@...udflare.com> wrote:
>
> On Tue, Jan 06, 2026 at 09:46 AM -08, Amery Hung wrote:
> > On Tue, Jan 6, 2026 at 9:36 AM Jakub Sitnicki <jakub@...udflare.com> wrote:
> >> --- a/kernel/bpf/verifier.c
> >> +++ b/kernel/bpf/verifier.c
> >> @@ -21806,6 +21806,14 @@ static int convert_ctx_accesses(struct bpf_verifier_env *env)
> >> env->prog = new_prog;
> >> delta += cnt - 1;
> >>
> >> + /* gen_prologue emits function calls with target address
> >> + * relative to __bpf_call_base. Skip patch_call_imm fixup.
> >> + */
> >> + for (i = 0; i < cnt - 1; i++) {
> >> + if (bpf_helper_call(&env->prog->insnsi[i]))
> >> + env->insn_aux_data[i].finalized_call = true;
> >> + }
> >> +
> >> ret = add_kfunc_in_insns(env, insn_buf, cnt - 1);
> >
> > And then we can get rid of this function as there is no use case for
> > having a new kfunc in gen_{pro,epi}logue.
>
> Happy to convert bpf_{qdisc,testmod} gen_{pro,epi}logue to use
> BPF_EMIT_CALL instead of BPF_CALL_KFUNC.
>
> If it's alright with you, I'd like to kill kfunc support in
> {pro,epi}logue as a follow up.
>
Totally. Appreciate it!
Make sense to do in another patchset.
> Looks like there will be a bit of churn in selftests to remove the
> coverage. And this series is getting quite long.
Powered by blists - more mailing lists