Currently in bpftool's feature probe, we incorrectly tell the user that
all of the helper functions are supported for program types where helper
probing fails or is explicitly unsupported[1]:
$ bpftool feature probe
...
eBPF helpers supported for program type tracing:
- bpf_map_lookup_elem
- bpf_map_update_elem
- bpf_map_delete_elem
...
- bpf_redirect_neigh
- bpf_check_mtu
- bpf_sys_bpf
- bpf_sys_close
This patch adjusts bpftool to relay to the user when helper support
can't be determined:
$ bpftool feature probe
...
eBPF helpers supported for program type lirc_mode2:
Program type not supported
eBPF helpers supported for program type tracing:
Could not determine which helpers are available
eBPF helpers supported for program type struct_opts:
Could not determine which helpers are available
eBPF helpers supported for program type ext:
Could not determine which helpers are available
Rather than imply that no helpers are available for the program type, we
let the user know that helper function probing failed entirely.
[1] https://lore.kernel.org/bpf/[email protected]/
Milan Landaverde (2):
bpftool: adjust for error codes from libbpf probes
bpftool: output message if no helpers found in feature probing
tools/bpf/bpftool/feature.c | 22 +++++++++++++++++-----
1 file changed, 17 insertions(+), 5 deletions(-)
--
2.32.0
Originally [1], libbpf's (now deprecated) probe functions returned a bool
to acknowledge support but the new APIs return an int with a possible
negative error code to reflect probe failure. This change decides for
bpftool to declare maps and helpers are not available on probe failures.
[1]: https://lore.kernel.org/bpf/[email protected]/
Signed-off-by: Milan Landaverde <[email protected]>
---
tools/bpf/bpftool/feature.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/bpf/bpftool/feature.c b/tools/bpf/bpftool/feature.c
index be130e35462f..c532c8855c24 100644
--- a/tools/bpf/bpftool/feature.c
+++ b/tools/bpf/bpftool/feature.c
@@ -638,7 +638,7 @@ probe_map_type(enum bpf_map_type map_type, const char *define_prefix,
res = probe_map_type_ifindex(map_type, ifindex);
} else {
- res = libbpf_probe_bpf_map_type(map_type, NULL);
+ res = libbpf_probe_bpf_map_type(map_type, NULL) > 0;
}
/* Probe result depends on the success of map creation, no additional
@@ -701,7 +701,7 @@ probe_helper_for_progtype(enum bpf_prog_type prog_type, bool supported_type,
if (ifindex)
res = probe_helper_ifindex(id, prog_type, ifindex);
else
- res = libbpf_probe_bpf_helper(prog_type, id, NULL);
+ res = libbpf_probe_bpf_helper(prog_type, id, NULL) > 0;
#ifdef USE_LIBCAP
/* Probe may succeed even if program load fails, for
* unprivileged users check that we did not fail because of
--
2.32.0
Currently in libbpf, we have hardcoded program types that are not
supported for helper function probing (e.g. tracing, ext, lsm).
Due to this (and other legitimate failures), bpftool feature probe returns
empty for those program type helper functions.
Instead of implying to the user that there are no helper functions
available for a program type, we output a message to the user explaining
that helper function probing failed for that program type.
Signed-off-by: Milan Landaverde <[email protected]>
---
tools/bpf/bpftool/feature.c | 18 +++++++++++++++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/tools/bpf/bpftool/feature.c b/tools/bpf/bpftool/feature.c
index c532c8855c24..d12f46051aac 100644
--- a/tools/bpf/bpftool/feature.c
+++ b/tools/bpf/bpftool/feature.c
@@ -690,7 +690,7 @@ probe_helper_ifindex(enum bpf_func_id id, enum bpf_prog_type prog_type,
return res;
}
-static void
+static bool
probe_helper_for_progtype(enum bpf_prog_type prog_type, bool supported_type,
const char *define_prefix, unsigned int id,
const char *ptype_name, __u32 ifindex)
@@ -723,6 +723,8 @@ probe_helper_for_progtype(enum bpf_prog_type prog_type, bool supported_type,
if (res)
printf("\n\t- %s", helper_name[id]);
}
+
+ return res;
}
static void
@@ -732,6 +734,7 @@ probe_helpers_for_progtype(enum bpf_prog_type prog_type, bool supported_type,
const char *ptype_name = prog_type_name[prog_type];
char feat_name[128];
unsigned int id;
+ bool probe_res = false;
if (ifindex)
/* Only test helpers for offload-able program types */
@@ -764,7 +767,7 @@ probe_helpers_for_progtype(enum bpf_prog_type prog_type, bool supported_type,
continue;
/* fallthrough */
default:
- probe_helper_for_progtype(prog_type, supported_type,
+ probe_res |= probe_helper_for_progtype(prog_type, supported_type,
define_prefix, id, ptype_name,
ifindex);
}
@@ -772,8 +775,17 @@ probe_helpers_for_progtype(enum bpf_prog_type prog_type, bool supported_type,
if (json_output)
jsonw_end_array(json_wtr);
- else if (!define_prefix)
+ else if (!define_prefix) {
printf("\n");
+ if (!probe_res) {
+ if (!supported_type)
+ printf("\tProgram type not supported\n");
+ else
+ printf("\tCould not determine which helpers are available\n");
+ }
+ }
+
+
}
static void
--
2.32.0
2022-05-04 12:13 UTC-0400 ~ Milan Landaverde <[email protected]>
> Currently in bpftool's feature probe, we incorrectly tell the user that
> all of the helper functions are supported for program types where helper
> probing fails or is explicitly unsupported[1]:
>
> $ bpftool feature probe
> ...
> eBPF helpers supported for program type tracing:
> - bpf_map_lookup_elem
> - bpf_map_update_elem
> - bpf_map_delete_elem
> ...
> - bpf_redirect_neigh
> - bpf_check_mtu
> - bpf_sys_bpf
> - bpf_sys_close
>
> This patch adjusts bpftool to relay to the user when helper support
> can't be determined:
>
> $ bpftool feature probe
> ...
> eBPF helpers supported for program type lirc_mode2:
> Program type not supported
> eBPF helpers supported for program type tracing:
> Could not determine which helpers are available
> eBPF helpers supported for program type struct_opts:
> Could not determine which helpers are available
> eBPF helpers supported for program type ext:
> Could not determine which helpers are available
>
> Rather than imply that no helpers are available for the program type, we
> let the user know that helper function probing failed entirely.
>
> [1] https://lore.kernel.org/bpf/[email protected]/
>
> Milan Landaverde (2):
> bpftool: adjust for error codes from libbpf probes
> bpftool: output message if no helpers found in feature probing
>
> tools/bpf/bpftool/feature.c | 22 +++++++++++++++++-----
> 1 file changed, 17 insertions(+), 5 deletions(-)
>
> --
> 2.32.0
>
Looks good to me, thank you
Reviewed-by: Quentin Monnet <[email protected]>
Hello:
This series was applied to bpf/bpf-next.git (master)
by Andrii Nakryiko <[email protected]>:
On Wed, 4 May 2022 12:13:30 -0400 you wrote:
> Currently in bpftool's feature probe, we incorrectly tell the user that
> all of the helper functions are supported for program types where helper
> probing fails or is explicitly unsupported[1]:
>
> $ bpftool feature probe
> ...
> eBPF helpers supported for program type tracing:
> - bpf_map_lookup_elem
> - bpf_map_update_elem
> - bpf_map_delete_elem
> ...
> - bpf_redirect_neigh
> - bpf_check_mtu
> - bpf_sys_bpf
> - bpf_sys_close
>
> [...]
Here is the summary with links:
- [bpf-next,1/2] bpftool: adjust for error codes from libbpf probes
https://git.kernel.org/bpf/bpf-next/c/6d9f63b9df5e
- [bpf-next,2/2] bpftool: output message if no helpers found in feature probing
https://git.kernel.org/bpf/bpf-next/c/b06a92a18d46
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html