From: Mykyta Yatsenko <mykyta.yatsenko5@gmail.com>
To: Kumar Kartikeya Dwivedi <memxor@gmail.com>, bpf@vger.kernel.org
Cc: Vineet Gupta <vineet.gupta@linux.dev>,
Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Martin KaFai Lau <martin.lau@kernel.org>,
Eduard Zingerman <eddyz87@gmail.com>,
Ihor Solodrai <ihor.solodrai@linux.dev>,
kkd@meta.com, kernel-team@meta.com
Subject: Re: [PATCH bpf-next v3 2/4] bpf: Introduce __bpf_kfunc_mark_deprecated annotation
Date: Mon, 20 Apr 2026 15:21:11 +0100 [thread overview]
Message-ID: <e8fa6144-b295-46a8-8cec-72e84579a98e@gmail.com> (raw)
In-Reply-To: <20260418171701.610025-3-memxor@gmail.com>
On 4/18/26 6:16 PM, Kumar Kartikeya Dwivedi wrote:
> Documentation for KF_DEPRECATED documents the expectations and
> recommendations for deprecating existing kfuncs. Until now, such a flag
> never materialized. Unlike other kfunc flags, more context needs to be
> carried with such a flag, thus we introduce __bpf_kfunc_mark_deprecated
> as a replacement for the (non-existent) kfunc flag which takes a
> replacement kfunc to provide recommendations to the user.
>
> Apply it to all existing impl-suffixed kfuncs that are preserved for
> backwards compatibility for a few kernel releases, after we introduced
> versions with KF_IMPLICIT_ARGS.
>
> Note that this is only supported by LLVM-compiled kernels as of writing,
> since GCC does not support for BTF declaration tags.
>
> Cc: Vineet Gupta <vineet.gupta@linux.dev>
> Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
> ---
> Documentation/bpf/kfuncs.rst | 42 ++++++++++---------
> include/linux/bpf_verifier.h | 1 +
> include/linux/btf.h | 5 +++
> include/linux/compiler_types.h | 14 ++++++-
> kernel/bpf/helpers.c | 8 ++++
> kernel/bpf/verifier.c | 41 ++++++++++++++++++
> .../selftests/bpf/test_kmods/bpf_testmod.c | 1 +
> 7 files changed, 90 insertions(+), 22 deletions(-)
>
...
> +static void warn_for_deprecated_kfuncs(struct bpf_verifier_env *env,
> + struct bpf_kfunc_call_arg_meta *meta,
> + int insn_idx, s16 offset)
> +{
> + const struct bpf_line_info *linfo;
> + const char *replacement;
> + const struct btf_type *t;
> + struct bpf_kfunc_desc *desc;
> + const char *file;
> + int line_num;
> +
> + if (!env->prog->aux->btf)
> + return;
> +
> + t = btf_type_by_id(meta->btf, meta->func_id);
> + replacement = btf_find_decl_tag_value(meta->btf, t, -1, BPF_KFUNC_DECL_TAG_DEPRECATED);
> + if (IS_ERR(replacement) || str_is_empty(replacement))
> + return;
> +
> + desc = find_kfunc_desc(env->prog, meta->func_id, offset);
> + if (!desc || desc->warned_deprecated)
> + return;
> +
> + linfo = bpf_find_linfo(env->prog, insn_idx);
> + if (linfo) {
> + bpf_get_linfo_file_line(env->prog->aux->btf, linfo, &file, NULL, &line_num);
> + warn(env, "%s:%d (insn #%d) uses deprecated kfunc %s(), which will be removed.\n",
> + file, line_num, insn_idx, meta->func_name);
> + } else {
> + warn(env, "(insn #%d) uses deprecated kfunc %s(), which will be removed.\n",
> + insn_idx, meta->func_name);
> + }
> +
> + warn(env, "Switch to kfunc %s() instead.\n", replacement);
> + warn(env, "For older kernels, choose the correct kfunc using bpf_ksym_exists().\n");
Is it right to reference bpf_ksym_exists() macro from the verifier log,
what if user does not use bpf_helpers.h header?
> +
> + desc->warned_deprecated = true;
> +}
> +
> static int check_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
> int *insn_idx_p)
> {
> @@ -13016,6 +13055,8 @@ static int check_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
>
> insn_aux->is_iter_next = bpf_is_iter_next_kfunc(&meta);
>
> + warn_for_deprecated_kfuncs(env, &meta, insn_idx, insn->off);
> +
> if (!insn->off &&
> (insn->imm == special_kfunc_list[KF_bpf_res_spin_lock] ||
> insn->imm == special_kfunc_list[KF_bpf_res_spin_lock_irqsave])) {
> diff --git a/tools/testing/selftests/bpf/test_kmods/bpf_testmod.c b/tools/testing/selftests/bpf/test_kmods/bpf_testmod.c
> index d876314a4d67..5a57a92a8f8c 100644
> --- a/tools/testing/selftests/bpf/test_kmods/bpf_testmod.c
> +++ b/tools/testing/selftests/bpf/test_kmods/bpf_testmod.c
> @@ -1252,6 +1252,7 @@ __bpf_kfunc int bpf_kfunc_multi_st_ops_test_1_assoc(struct st_ops_args *args, st
>
> __bpf_kfunc int bpf_kfunc_implicit_arg(int a, struct bpf_prog_aux *aux);
> __bpf_kfunc int bpf_kfunc_implicit_arg_legacy(int a, int b, struct bpf_prog_aux *aux);
> +__bpf_kfunc_mark_deprecated(bpf_kfunc_implicit_arg_legacy)
> __bpf_kfunc int bpf_kfunc_implicit_arg_legacy_impl(int a, int b, struct bpf_prog_aux *aux);
>
> /* hook targets */
next prev parent reply other threads:[~2026-04-20 14:21 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-18 17:16 [PATCH bpf-next v3 0/4] Add support to emit verifier warnings Kumar Kartikeya Dwivedi
2026-04-18 17:16 ` [PATCH bpf-next v3 1/4] bpf: Add support for verifier warning messages Kumar Kartikeya Dwivedi
2026-04-18 17:42 ` sashiko-bot
2026-04-18 20:33 ` Kumar Kartikeya Dwivedi
2026-04-20 13:37 ` Mykyta Yatsenko
2026-04-20 15:26 ` Kumar Kartikeya Dwivedi
2026-04-18 17:16 ` [PATCH bpf-next v3 2/4] bpf: Introduce __bpf_kfunc_mark_deprecated annotation Kumar Kartikeya Dwivedi
2026-04-18 18:06 ` sashiko-bot
2026-04-18 20:34 ` Kumar Kartikeya Dwivedi
2026-04-20 14:21 ` Mykyta Yatsenko [this message]
2026-04-20 15:27 ` Kumar Kartikeya Dwivedi
2026-04-20 18:15 ` David Faust
2026-04-20 18:19 ` Kumar Kartikeya Dwivedi
2026-04-18 17:16 ` [PATCH bpf-next v3 3/4] libbpf: Request verifier warnings for object loads Kumar Kartikeya Dwivedi
2026-04-18 18:35 ` sashiko-bot
2026-04-18 20:38 ` Kumar Kartikeya Dwivedi
2026-04-20 13:57 ` Mykyta Yatsenko
2026-04-20 15:23 ` Kumar Kartikeya Dwivedi
2026-04-20 15:49 ` Alexei Starovoitov
2026-04-18 17:16 ` [PATCH bpf-next v3 4/4] selftests/bpf: Test verifier warning logging Kumar Kartikeya Dwivedi
2026-04-18 18:45 ` sashiko-bot
2026-04-18 20:39 ` Kumar Kartikeya Dwivedi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e8fa6144-b295-46a8-8cec-72e84579a98e@gmail.com \
--to=mykyta.yatsenko5@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=ihor.solodrai@linux.dev \
--cc=kernel-team@meta.com \
--cc=kkd@meta.com \
--cc=martin.lau@kernel.org \
--cc=memxor@gmail.com \
--cc=vineet.gupta@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox