mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Quentin Monnet <qmo@kernel.org>
To: Jiayuan Chen <jiayuan.chen@linux.dev>, bpf@vger.kernel.org
Cc: Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Eduard Zingerman <eddyz87@gmail.com>, Song Liu <song@kernel.org>,
	Yonghong Song <yonghong.song@linux.dev>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@kernel.org>,
	Stanislav Fomichev <sdf@fomichev.me>, Hao Luo <haoluo@google.com>,
	Jiri Olsa <jolsa@kernel.org>, Daniel Xu <dxu@dxuuu.xyz>,
	Mykyta Yatsenko <yatsenko@meta.com>,
	Tao Chen <chen.dylane@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH bpf-next v2] bpftool: Add support for custom BTF path in prog load/loadall
Date: Thu, 15 May 2025 10:17:05 +0100	[thread overview]
Message-ID: <d4e30634-b64e-47c7-9089-a37d20e29d2f@kernel.org> (raw)
In-Reply-To: <20250515065018.240188-1-jiayuan.chen@linux.dev>

2025-05-15 14:50 UTC+0800 ~ Jiayuan Chen <jiayuan.chen@linux.dev>
> This patch exposes the btf_custom_path feature to bpftool, allowing users
> to specify a custom BTF file when loading BPF programs using prog load or
> prog loadall commands.
> 
> The argument 'btf_custom_path' in libbpf is used for those kernes that


Typo: "kernes"


> don't have CONFIG_DEBUG_INFO_BTF enabled but still want to perform CO-RE
> relocations.
> 
> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
> ---
>  tools/bpf/bpftool/Documentation/bpftool-prog.rst |  7 ++++++-
>  tools/bpf/bpftool/bash-completion/bpftool        |  2 +-
>  tools/bpf/bpftool/prog.c                         | 12 +++++++++++-
>  3 files changed, 18 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/bpf/bpftool/Documentation/bpftool-prog.rst b/tools/bpf/bpftool/Documentation/bpftool-prog.rst
> index d6304e01afe0..e60a829ab8d0 100644
> --- a/tools/bpf/bpftool/Documentation/bpftool-prog.rst
> +++ b/tools/bpf/bpftool/Documentation/bpftool-prog.rst
> @@ -127,7 +127,7 @@ bpftool prog pin *PROG* *FILE*
>      Note: *FILE* must be located in *bpffs* mount. It must not contain a dot
>      character ('.'), which is reserved for future extensions of *bpffs*.
>  
> -bpftool prog { load | loadall } *OBJ* *PATH* [type *TYPE*] [map { idx *IDX* | name *NAME* } *MAP*] [{ offload_dev | xdpmeta_dev } *NAME*] [pinmaps *MAP_DIR*] [autoattach]
> +bpftool prog { load | loadall } *OBJ* *PATH* [type *TYPE*] [map { idx *IDX* | name *NAME* } *MAP*] [{ offload_dev | xdpmeta_dev } *NAME*] [pinmaps *MAP_DIR*] [autoattach] [kernel_btf *BTF_DIR*]
>      Load bpf program(s) from binary *OBJ* and pin as *PATH*. **bpftool prog
>      load** pins only the first program from the *OBJ* as *PATH*. **bpftool prog
>      loadall** pins all programs from the *OBJ* under *PATH* directory. **type**
> @@ -153,6 +153,11 @@ bpftool prog { load | loadall } *OBJ* *PATH* [type *TYPE*] [map { idx *IDX* | na
>      program does not support autoattach, bpftool falls back to regular pinning
>      for that program instead.
>  
> +    The **kernel_btf** option allows specifying an external BTF file to replace
> +    the system's own vmlinux BTF file for CO-RE relocations. NOTE that any
> +    other feature (e.g., fentry/fexit programs, struct_ops, etc) will require


Nit: No need for both "e.g." and "etc", they're redundant.


> +    actual kernel BTF like /sys/kernel/btf/vmlinux.
> +


Can we rephrase the second part of the paragraph a little bit please?
“Any other feature” could be clearer, how about:

	Note that any other feature relying on BTF (such as fentry/fexit
	programs, struct_ops) requires the BTF file for the actual
	kernel running on the host, often exposed at
	/sys/kernel/btf/vmlinux.


>      Note: *PATH* must be located in *bpffs* mount. It must not contain a dot
>      character ('.'), which is reserved for future extensions of *bpffs*.
>  
> diff --git a/tools/bpf/bpftool/bash-completion/bpftool b/tools/bpf/bpftool/bash-completion/bpftool
> index 1ce409a6cbd9..609938c287b7 100644
> --- a/tools/bpf/bpftool/bash-completion/bpftool
> +++ b/tools/bpf/bpftool/bash-completion/bpftool
> @@ -511,7 +511,7 @@ _bpftool()
>                              ;;
>                          *)
>                              COMPREPLY=( $( compgen -W "map" -- "$cur" ) )
> -                            _bpftool_once_attr 'type pinmaps autoattach'
> +                            _bpftool_once_attr 'type pinmaps autoattach kernel_btf'
>                              _bpftool_one_of_list 'offload_dev xdpmeta_dev'
>                              return 0
>                              ;;


Correct, but right before this could you also add the following, please:

	@@ -505,13 +505,13 @@ _bpftool()
	                             _bpftool_get_map_names
	                             return 0
	                             ;;
	-                        pinned|pinmaps)
	+                        pinned|pinmaps|kernel_btf)
	                             _filedir
	                             return 0
	                             ;;
	                         *)

This will make the completion offer file names after the user has typed
"kernel_btf".


> diff --git a/tools/bpf/bpftool/prog.c b/tools/bpf/bpftool/prog.c
> index f010295350be..3b6a361dd0f8 100644
> --- a/tools/bpf/bpftool/prog.c
> +++ b/tools/bpf/bpftool/prog.c
> @@ -1681,8 +1681,17 @@ static int load_with_options(int argc, char **argv, bool first_prog_only)
>  		} else if (is_prefix(*argv, "autoattach")) {
>  			auto_attach = true;
>  			NEXT_ARG();
> +		} else if (is_prefix(*argv, "kernel_btf")) {
> +			NEXT_ARG();
> +
> +			if (!REQ_ARGS(1))
> +				goto err_free_reuse_maps;
> +
> +			open_opts.btf_custom_path = GET_ARG();
>  		} else {
> -			p_err("expected no more arguments, 'type', 'map' or 'dev', got: '%s'?",
> +			p_err("expected no more arguments, "
> +			      "'type', 'map', 'dev', 'offload_dev', 'xdpmeta_dev', 'pinmaps', "
> +			      "'autoattach', or 'kernel_btf', got: '%s'?",


Some of them were missing, thanks for this! Can you remove "dev" from
the list, please? It's been deprecated in favour of "offload_dev", to
avoid confusion with "xdpmeta_dev".

pw-bot: cr


>  			      *argv);
>  			goto err_free_reuse_maps;
>  		}
> @@ -2474,6 +2483,7 @@ static int do_help(int argc, char **argv)
>  		"                         [map { idx IDX | name NAME } MAP]\\\n"
>  		"                         [pinmaps MAP_DIR]\n"
>  		"                         [autoattach]\n"
> +		"                         [kernel_btf BTF_DIR]\n"
>  		"       %1$s %2$s attach PROG ATTACH_TYPE [MAP]\n"
>  		"       %1$s %2$s detach PROG ATTACH_TYPE [MAP]\n"
>  		"       %1$s %2$s run PROG \\\n"


Thanks,
Quentin

  reply	other threads:[~2025-05-15  9:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-15  6:50 Jiayuan Chen
2025-05-15  9:17 ` Quentin Monnet [this message]
2025-05-15 13:00   ` Jiayuan Chen
2025-05-15 16:03 ` Andrii Nakryiko

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=d4e30634-b64e-47c7-9089-a37d20e29d2f@kernel.org \
    --to=qmo@kernel.org \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=chen.dylane@gmail.com \
    --cc=daniel@iogearbox.net \
    --cc=dxu@dxuuu.xyz \
    --cc=eddyz87@gmail.com \
    --cc=haoluo@google.com \
    --cc=jiayuan.chen@linux.dev \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=sdf@fomichev.me \
    --cc=song@kernel.org \
    --cc=yatsenko@meta.com \
    --cc=yonghong.song@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

all inboxes | Powered by JetHome®