Skip to contentSkip to conversation

selftests/bpf: skip verifier tests that depend on CONFIG_CGROUP_BPF

PATCH In review Stanislav Fomichev 6 participants 18 messages Dec 12, 2018 – Dec 14, 2018

Subsystems (6)
Networking Network drivers Kselftest BPF +2 more subsystems
lore
Share & tools
lore

Stanislav Fomichev

author
#0 lore raw

PATCH 1/2 selftests/bpf: skip verifier tests that depend on CONFIG_CGROUP_BPF

The following prog types don't make sense without bpf cgroup:
* BPF_PROG_TYPE_CGROUP_SKB
* BPF_PROG_TYPE_CGROUP_SOCK
* BPF_PROG_TYPE_CGROUP_SOCK_ADDR

Skip running verifier tests that exercise these prog types if kernel is built without proper support.

See commit e5c504858a18 ("selftests/bpf: skip verifier sockmap tests on kernels without support") for original motivation.

Signed-off-by Stanislav Fomichev <[email protected]>
---
 tools/testing/selftests/bpf/test_verifier.c | 35 +++++++++++++++++++++
 1 file changed, 35 insertions(+)
tools/testing/selftests/bpf/test_verifier.c +35 -0
index f5015566ae1b..b5470a399996 100644
@@ -44,6 +44,7 @@
 /* fallback to all features enabled */
 # define CONFIG_BPF_STREAM_PARSER 1
 # define CONFIG_XDP_SOCKETS 1
+# define CONFIG_CGROUP_BPF 1
 #endif
 #include "bpf_rlimit.h"
 #include "bpf_rand.h"

@@ -2098,6 +2099,7 @@ static struct bpf_test tests[] = {
 		.errstr = "invalid bpf_context access",
 		.result = REJECT,
 		.prog_type = BPF_PROG_TYPE_CGROUP_SOCK,
+		.config_disabled = !IS_BUILTIN(CONFIG_CGROUP_BPF),
 	},
 	{
 		"check cb access: half",

@@ -2256,6 +2258,7 @@ static struct bpf_test tests[] = {
 		.errstr = "invalid bpf_context access",
 		.result = REJECT,
 		.prog_type = BPF_PROG_TYPE_CGROUP_SOCK,
+		.config_disabled = !IS_BUILTIN(CONFIG_CGROUP_BPF),
 	},
 	{
 		"check cb access: word",

@@ -2428,6 +2431,7 @@ static struct bpf_test tests[] = {
 		.errstr = "invalid bpf_context access",
 		.result = REJECT,
 		.prog_type = BPF_PROG_TYPE_CGROUP_SOCK,
+		.config_disabled = !IS_BUILTIN(CONFIG_CGROUP_BPF),
 	},
 	{
 		"check out of range skb->cb access",

@@ -4981,6 +4985,7 @@ static struct bpf_test tests[] = {
 		.result_unpriv = REJECT,
 		.errstr_unpriv = "invalid bpf_context access off=76 size=4",
 		.prog_type = BPF_PROG_TYPE_CGROUP_SKB,
+		.config_disabled = !IS_BUILTIN(CONFIG_CGROUP_BPF),
 	},
 	{
 		"direct packet read test#2 for CGROUP_SKB",

@@ -5005,6 +5010,7 @@ static struct bpf_test tests[] = {
 		},
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_CGROUP_SKB,
+		.config_disabled = !IS_BUILTIN(CONFIG_CGROUP_BPF),
 	},
 	{
 		"direct packet read test#3 for CGROUP_SKB",

@@ -5036,6 +5042,7 @@ static struct bpf_test tests[] = {
 		},
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_CGROUP_SKB,
+		.config_disabled = !IS_BUILTIN(CONFIG_CGROUP_BPF),
 	},
 	{
 		"direct packet read test#4 for CGROUP_SKB",

@@ -5071,6 +5078,7 @@ static struct bpf_test tests[] = {
 		},
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_CGROUP_SKB,
+		.config_disabled = !IS_BUILTIN(CONFIG_CGROUP_BPF),
 	},
 	{
 		"invalid access of tc_classid for CGROUP_SKB",

@@ -5083,6 +5091,7 @@ static struct bpf_test tests[] = {
 		.result = REJECT,
 		.errstr = "invalid bpf_context access",
 		.prog_type = BPF_PROG_TYPE_CGROUP_SKB,
+		.config_disabled = !IS_BUILTIN(CONFIG_CGROUP_BPF),
 	},
 	{
 		"invalid access of data_meta for CGROUP_SKB",

@@ -5095,6 +5104,7 @@ static struct bpf_test tests[] = {
 		.result = REJECT,
 		.errstr = "invalid bpf_context access",
 		.prog_type = BPF_PROG_TYPE_CGROUP_SKB,
+		.config_disabled = !IS_BUILTIN(CONFIG_CGROUP_BPF),
 	},
 	{
 		"invalid access of flow_keys for CGROUP_SKB",

@@ -5107,6 +5117,7 @@ static struct bpf_test tests[] = {
 		.result = REJECT,
 		.errstr = "invalid bpf_context access",
 		.prog_type = BPF_PROG_TYPE_CGROUP_SKB,
+		.config_disabled = !IS_BUILTIN(CONFIG_CGROUP_BPF),
 	},
 	{
 		"invalid write access to napi_id for CGROUP_SKB",

@@ -5121,6 +5132,7 @@ static struct bpf_test tests[] = {
 		.result = REJECT,
 		.errstr = "invalid bpf_context access",
 		.prog_type = BPF_PROG_TYPE_CGROUP_SKB,
+		.config_disabled = !IS_BUILTIN(CONFIG_CGROUP_BPF),
 	},
 	{
 		"valid cgroup storage access",

@@ -5137,6 +5149,7 @@ static struct bpf_test tests[] = {
 		.fixup_cgroup_storage = { 1 },
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_CGROUP_SKB,
+		.config_disabled = !IS_BUILTIN(CONFIG_CGROUP_BPF),
 	},
 	{
 		"invalid cgroup storage access 1",

@@ -5154,6 +5167,7 @@ static struct bpf_test tests[] = {
 		.result = REJECT,
 		.errstr = "cannot pass map_type 1 into func bpf_get_local_storage",
 		.prog_type = BPF_PROG_TYPE_CGROUP_SKB,
+		.config_disabled = !IS_BUILTIN(CONFIG_CGROUP_BPF),
 	},
 	{
 		"invalid cgroup storage access 2",

@@ -5168,6 +5182,7 @@ static struct bpf_test tests[] = {
 		.result = REJECT,
 		.errstr = "fd 1 is not pointing to valid bpf_map",
 		.prog_type = BPF_PROG_TYPE_CGROUP_SKB,
+		.config_disabled = !IS_BUILTIN(CONFIG_CGROUP_BPF),
 	},
 	{
 		"invalid cgroup storage access 3",

@@ -5185,6 +5200,7 @@ static struct bpf_test tests[] = {
 		.result = REJECT,
 		.errstr = "invalid access to map value, value_size=64 off=256 size=4",
 		.prog_type = BPF_PROG_TYPE_CGROUP_SKB,
+		.config_disabled = !IS_BUILTIN(CONFIG_CGROUP_BPF),
 	},
 	{
 		"invalid cgroup storage access 4",

@@ -5202,6 +5218,7 @@ static struct bpf_test tests[] = {
 		.result = REJECT,
 		.errstr = "invalid access to map value, value_size=64 off=-2 size=4",
 		.prog_type = BPF_PROG_TYPE_CGROUP_SKB,
+		.config_disabled = !IS_BUILTIN(CONFIG_CGROUP_BPF),
 		.flags = F_NEEDS_EFFICIENT_UNALIGNED_ACCESS,
 	},
 	{

@@ -5220,6 +5237,7 @@ static struct bpf_test tests[] = {
 		.result = REJECT,
 		.errstr = "get_local_storage() doesn't support non-zero flags",
 		.prog_type = BPF_PROG_TYPE_CGROUP_SKB,
+		.config_disabled = !IS_BUILTIN(CONFIG_CGROUP_BPF),
 	},
 	{
 		"invalid cgroup storage access 6",

@@ -5238,6 +5256,7 @@ static struct bpf_test tests[] = {
 		.errstr = "get_local_storage() doesn't support non-zero flags",
 		.errstr_unpriv = "R2 leaks addr into helper function",
 		.prog_type = BPF_PROG_TYPE_CGROUP_SKB,
+		.config_disabled = !IS_BUILTIN(CONFIG_CGROUP_BPF),
 	},
 	{
 		"valid per-cpu cgroup storage access",

@@ -5254,6 +5273,7 @@ static struct bpf_test tests[] = {
 		.fixup_percpu_cgroup_storage = { 1 },
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_CGROUP_SKB,
+		.config_disabled = !IS_BUILTIN(CONFIG_CGROUP_BPF),
 	},
 	{
 		"invalid per-cpu cgroup storage access 1",

@@ -5271,6 +5291,7 @@ static struct bpf_test tests[] = {
 		.result = REJECT,
 		.errstr = "cannot pass map_type 1 into func bpf_get_local_storage",
 		.prog_type = BPF_PROG_TYPE_CGROUP_SKB,
+		.config_disabled = !IS_BUILTIN(CONFIG_CGROUP_BPF),
 	},
 	{
 		"invalid per-cpu cgroup storage access 2",

@@ -5285,6 +5306,7 @@ static struct bpf_test tests[] = {
 		.result = REJECT,
 		.errstr = "fd 1 is not pointing to valid bpf_map",
 		.prog_type = BPF_PROG_TYPE_CGROUP_SKB,
+		.config_disabled = !IS_BUILTIN(CONFIG_CGROUP_BPF),
 	},
 	{
 		"invalid per-cpu cgroup storage access 3",

@@ -5302,6 +5324,7 @@ static struct bpf_test tests[] = {
 		.result = REJECT,
 		.errstr = "invalid access to map value, value_size=64 off=256 size=4",
 		.prog_type = BPF_PROG_TYPE_CGROUP_SKB,
+		.config_disabled = !IS_BUILTIN(CONFIG_CGROUP_BPF),
 	},
 	{
 		"invalid per-cpu cgroup storage access 4",

@@ -5319,6 +5342,7 @@ static struct bpf_test tests[] = {
 		.result = REJECT,
 		.errstr = "invalid access to map value, value_size=64 off=-2 size=4",
 		.prog_type = BPF_PROG_TYPE_CGROUP_SKB,
+		.config_disabled = !IS_BUILTIN(CONFIG_CGROUP_BPF),
 		.flags = F_NEEDS_EFFICIENT_UNALIGNED_ACCESS,
 	},
 	{

@@ -5337,6 +5361,7 @@ static struct bpf_test tests[] = {
 		.result = REJECT,
 		.errstr = "get_local_storage() doesn't support non-zero flags",
 		.prog_type = BPF_PROG_TYPE_CGROUP_SKB,
+		.config_disabled = !IS_BUILTIN(CONFIG_CGROUP_BPF),
 	},
 	{
 		"invalid per-cpu cgroup storage access 6",

@@ -5355,6 +5380,7 @@ static struct bpf_test tests[] = {
 		.errstr = "get_local_storage() doesn't support non-zero flags",
 		.errstr_unpriv = "R2 leaks addr into helper function",
 		.prog_type = BPF_PROG_TYPE_CGROUP_SKB,
+		.config_disabled = !IS_BUILTIN(CONFIG_CGROUP_BPF),
 	},
 	{
 		"write tstamp from CGROUP_SKB",

@@ -5369,6 +5395,7 @@ static struct bpf_test tests[] = {
 		.result_unpriv = REJECT,
 		.errstr_unpriv = "invalid bpf_context access off=152 size=8",
 		.prog_type = BPF_PROG_TYPE_CGROUP_SKB,
+		.config_disabled = !IS_BUILTIN(CONFIG_CGROUP_BPF),
 	},
 	{
 		"read tstamp from CGROUP_SKB",

@@ -5380,6 +5407,7 @@ static struct bpf_test tests[] = {
 		},
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_CGROUP_SKB,
+		.config_disabled = !IS_BUILTIN(CONFIG_CGROUP_BPF),
 	},
 	{
 		"multiple registers share map_lookup_elem result",

@@ -10770,6 +10798,7 @@ static struct bpf_test tests[] = {
 		.errstr = "R0 has value (0x0; 0xffffffff)",
 		.result = REJECT,
 		.prog_type = BPF_PROG_TYPE_CGROUP_SOCK,
+		.config_disabled = !IS_BUILTIN(CONFIG_CGROUP_BPF),
 	},
 	{
 		"bpf_exit with invalid return code. test2",

@@ -10780,6 +10809,7 @@ static struct bpf_test tests[] = {
 		},
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_CGROUP_SOCK,
+		.config_disabled = !IS_BUILTIN(CONFIG_CGROUP_BPF),
 	},
 	{
 		"bpf_exit with invalid return code. test3",

@@ -10791,6 +10821,7 @@ static struct bpf_test tests[] = {
 		.errstr = "R0 has value (0x0; 0x3)",
 		.result = REJECT,
 		.prog_type = BPF_PROG_TYPE_CGROUP_SOCK,
+		.config_disabled = !IS_BUILTIN(CONFIG_CGROUP_BPF),
 	},
 	{
 		"bpf_exit with invalid return code. test4",

@@ -10800,6 +10831,7 @@ static struct bpf_test tests[] = {
 		},
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_CGROUP_SOCK,
+		.config_disabled = !IS_BUILTIN(CONFIG_CGROUP_BPF),
 	},
 	{
 		"bpf_exit with invalid return code. test5",

@@ -10810,6 +10842,7 @@ static struct bpf_test tests[] = {
 		.errstr = "R0 has value (0x2; 0x0)",
 		.result = REJECT,
 		.prog_type = BPF_PROG_TYPE_CGROUP_SOCK,
+		.config_disabled = !IS_BUILTIN(CONFIG_CGROUP_BPF),
 	},
 	{
 		"bpf_exit with invalid return code. test6",

@@ -10820,6 +10853,7 @@ static struct bpf_test tests[] = {
 		.errstr = "R0 is not a known value (ctx)",
 		.result = REJECT,
 		.prog_type = BPF_PROG_TYPE_CGROUP_SOCK,
+		.config_disabled = !IS_BUILTIN(CONFIG_CGROUP_BPF),
 	},
 	{
 		"bpf_exit with invalid return code. test7",

@@ -10832,6 +10866,7 @@ static struct bpf_test tests[] = {
 		.errstr = "R0 has unknown scalar value",
 		.result = REJECT,
 		.prog_type = BPF_PROG_TYPE_CGROUP_SOCK,
+		.config_disabled = !IS_BUILTIN(CONFIG_CGROUP_BPF),
 	},
 	{
 		"calls: basic sanity",
Signature · 1 line
2.20.0.rc2.403.gdbc3b29805-goog
author
#1 lore raw

PATCH 2/2 selftests/bpf: skip verifier tests that depend on CONFIG_BPF_EVENTS

The following prog types don't make sense without bpf cgroup:
* BPF_PROG_TYPE_KPROBE
* BPF_PROG_TYPE_TRACEPOINT
* BPF_PROG_TYPE_PERF_EVENT
* BPF_PROG_TYPE_RAW_TRACEPOINT
* bpf_trace_printk is not available without trace events

Skip running verifier tests that exercise these prog types if kernel is built without proper support.

See commit e5c504858a18 ("selftests/bpf: skip verifier sockmap tests on kernels without support") for original motivation.

Signed-off-by Stanislav Fomichev <[email protected]>
---
 tools/testing/selftests/bpf/test_verifier.c | 108 ++++++++++++++++++++
 1 file changed, 108 insertions(+)
tools/testing/selftests/bpf/test_verifier.c +108 -0
index b5470a399996..5b291daf8948 100644
@@ -45,6 +45,7 @@
 # define CONFIG_BPF_STREAM_PARSER 1
 # define CONFIG_XDP_SOCKETS 1
 # define CONFIG_CGROUP_BPF 1
+# define CONFIG_BPF_EVENTS 1
 #endif
 #include "bpf_rlimit.h"
 #include "bpf_rand.h"

@@ -2629,6 +2630,7 @@ static struct bpf_test tests[] = {
 		.errstr_unpriv = "unknown func bpf_trace_printk#6",
 		.result_unpriv = REJECT,
 		.result = ACCEPT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"unpriv: pass pointer to helper function",

@@ -2949,6 +2951,7 @@ static struct bpf_test tests[] = {
 		.result = REJECT,
 		.errstr = "same insn cannot be used with different pointers",
 		.prog_type = BPF_PROG_TYPE_PERF_EVENT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"unpriv: write pointer into map elem value",

@@ -4699,6 +4702,7 @@ static struct bpf_test tests[] = {
 		.result = REJECT,
 		.errstr = "cannot pass map_type 7 into func bpf_map_lookup_elem",
 		.prog_type = BPF_PROG_TYPE_PERF_EVENT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"prevent map lookup in prog array",

@@ -5582,6 +5586,7 @@ static struct bpf_test tests[] = {
 		},
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"constant register |= constant should not bypass stack boundary checks",

@@ -5597,6 +5602,7 @@ static struct bpf_test tests[] = {
 		.errstr = "invalid stack type R1 off=-48 access_size=58",
 		.result = REJECT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"constant register |= constant register should keep constant type",

@@ -5612,6 +5618,7 @@ static struct bpf_test tests[] = {
 		},
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"constant register |= constant register should not bypass stack boundary checks",

@@ -5628,6 +5635,7 @@ static struct bpf_test tests[] = {
 		.errstr = "invalid stack type R1 off=-48 access_size=58",
 		.result = REJECT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"invalid direct packet write for LWT_IN",

@@ -5887,6 +5895,7 @@ static struct bpf_test tests[] = {
 		.fixup_map_hash_48b = { 3 },
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to map: partial range",

@@ -5906,6 +5915,7 @@ static struct bpf_test tests[] = {
 		.fixup_map_hash_48b = { 3 },
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to map: empty range",

@@ -5925,6 +5935,7 @@ static struct bpf_test tests[] = {
 		.errstr = "invalid access to map value, value_size=48 off=0 size=0",
 		.result = REJECT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to map: out-of-bound range",

@@ -5945,6 +5956,7 @@ static struct bpf_test tests[] = {
 		.errstr = "invalid access to map value, value_size=48 off=0 size=56",
 		.result = REJECT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to map: negative range",

@@ -5965,6 +5977,7 @@ static struct bpf_test tests[] = {
 		.errstr = "R2 min value is negative",
 		.result = REJECT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to adjusted map (via const imm): full range",

@@ -5988,6 +6001,7 @@ static struct bpf_test tests[] = {
 		.fixup_map_hash_48b = { 3 },
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to adjusted map (via const imm): partial range",

@@ -6009,6 +6023,7 @@ static struct bpf_test tests[] = {
 		.fixup_map_hash_48b = { 3 },
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to adjusted map (via const imm): empty range",

@@ -6030,6 +6045,7 @@ static struct bpf_test tests[] = {
 		.errstr = "invalid access to map value, value_size=48 off=4 size=0",
 		.result = REJECT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to adjusted map (via const imm): out-of-bound range",

@@ -6054,6 +6070,7 @@ static struct bpf_test tests[] = {
 		.errstr = "invalid access to map value, value_size=48 off=4 size=52",
 		.result = REJECT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to adjusted map (via const imm): negative range (> adjustment)",

@@ -6076,6 +6093,7 @@ static struct bpf_test tests[] = {
 		.errstr = "R2 min value is negative",
 		.result = REJECT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to adjusted map (via const imm): negative range (< adjustment)",

@@ -6098,6 +6116,7 @@ static struct bpf_test tests[] = {
 		.errstr = "R2 min value is negative",
 		.result = REJECT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to adjusted map (via const reg): full range",

@@ -6122,6 +6141,7 @@ static struct bpf_test tests[] = {
 		.fixup_map_hash_48b = { 3 },
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to adjusted map (via const reg): partial range",

@@ -6144,6 +6164,7 @@ static struct bpf_test tests[] = {
 		.fixup_map_hash_48b = { 3 },
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to adjusted map (via const reg): empty range",

@@ -6165,6 +6186,7 @@ static struct bpf_test tests[] = {
 		.errstr = "R1 min value is outside of the array range",
 		.result = REJECT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to adjusted map (via const reg): out-of-bound range",

@@ -6190,6 +6212,7 @@ static struct bpf_test tests[] = {
 		.errstr = "invalid access to map value, value_size=48 off=4 size=52",
 		.result = REJECT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to adjusted map (via const reg): negative range (> adjustment)",

@@ -6213,6 +6236,7 @@ static struct bpf_test tests[] = {
 		.errstr = "R2 min value is negative",
 		.result = REJECT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to adjusted map (via const reg): negative range (< adjustment)",

@@ -6236,6 +6260,7 @@ static struct bpf_test tests[] = {
 		.errstr = "R2 min value is negative",
 		.result = REJECT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to adjusted map (via variable): full range",

@@ -6261,6 +6286,7 @@ static struct bpf_test tests[] = {
 		.fixup_map_hash_48b = { 3 },
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to adjusted map (via variable): partial range",

@@ -6284,6 +6310,7 @@ static struct bpf_test tests[] = {
 		.fixup_map_hash_48b = { 3 },
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to adjusted map (via variable): empty range",

@@ -6307,6 +6334,7 @@ static struct bpf_test tests[] = {
 		.errstr = "R1 min value is outside of the array range",
 		.result = REJECT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to adjusted map (via variable): no max check",

@@ -6329,6 +6357,7 @@ static struct bpf_test tests[] = {
 		.errstr = "R1 unbounded memory access",
 		.result = REJECT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to adjusted map (via variable): wrong max check",

@@ -6355,6 +6384,7 @@ static struct bpf_test tests[] = {
 		.errstr = "invalid access to map value, value_size=48 off=4 size=45",
 		.result = REJECT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to map: bounds check using <, good access",

@@ -6378,6 +6408,7 @@ static struct bpf_test tests[] = {
 		.fixup_map_hash_48b = { 3 },
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to map: bounds check using <, bad access",

@@ -6402,6 +6433,7 @@ static struct bpf_test tests[] = {
 		.result = REJECT,
 		.errstr = "R1 unbounded memory access",
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to map: bounds check using <=, good access",

@@ -6425,6 +6457,7 @@ static struct bpf_test tests[] = {
 		.fixup_map_hash_48b = { 3 },
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to map: bounds check using <=, bad access",

@@ -6449,6 +6482,7 @@ static struct bpf_test tests[] = {
 		.result = REJECT,
 		.errstr = "R1 unbounded memory access",
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to map: bounds check using s<, good access",

@@ -6473,6 +6507,7 @@ static struct bpf_test tests[] = {
 		.fixup_map_hash_48b = { 3 },
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to map: bounds check using s<, good access 2",

@@ -6497,6 +6532,7 @@ static struct bpf_test tests[] = {
 		.fixup_map_hash_48b = { 3 },
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to map: bounds check using s<, bad access",

@@ -6522,6 +6558,7 @@ static struct bpf_test tests[] = {
 		.result = REJECT,
 		.errstr = "R1 min value is negative",
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to map: bounds check using s<=, good access",

@@ -6546,6 +6583,7 @@ static struct bpf_test tests[] = {
 		.fixup_map_hash_48b = { 3 },
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to map: bounds check using s<=, good access 2",

@@ -6570,6 +6608,7 @@ static struct bpf_test tests[] = {
 		.fixup_map_hash_48b = { 3 },
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to map: bounds check using s<=, bad access",

@@ -6595,6 +6634,7 @@ static struct bpf_test tests[] = {
 		.result = REJECT,
 		.errstr = "R1 min value is negative",
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"map access: known scalar += value_ptr",

@@ -6863,6 +6903,7 @@ static struct bpf_test tests[] = {
 		.fixup_map_hash_16b = { 3, 8 },
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"map update helper access to map",

@@ -6883,6 +6924,7 @@ static struct bpf_test tests[] = {
 		.fixup_map_hash_16b = { 3, 10 },
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"map update helper access to map: wrong size",

@@ -6905,6 +6947,7 @@ static struct bpf_test tests[] = {
 		.result = REJECT,
 		.errstr = "invalid access to map value, value_size=8 off=0 size=16",
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"map helper access to adjusted map (via const imm)",

@@ -6925,6 +6968,7 @@ static struct bpf_test tests[] = {
 		.fixup_map_hash_16b = { 3, 9 },
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"map helper access to adjusted map (via const imm): out-of-bound 1",

@@ -6946,6 +6990,7 @@ static struct bpf_test tests[] = {
 		.result = REJECT,
 		.errstr = "invalid access to map value, value_size=16 off=12 size=8",
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"map helper access to adjusted map (via const imm): out-of-bound 2",

@@ -6966,6 +7011,7 @@ static struct bpf_test tests[] = {
 		.result = REJECT,
 		.errstr = "invalid access to map value, value_size=16 off=-4 size=8",
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"map helper access to adjusted map (via const reg)",

@@ -6987,6 +7033,7 @@ static struct bpf_test tests[] = {
 		.fixup_map_hash_16b = { 3, 10 },
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"map helper access to adjusted map (via const reg): out-of-bound 1",

@@ -7009,6 +7056,7 @@ static struct bpf_test tests[] = {
 		.result = REJECT,
 		.errstr = "invalid access to map value, value_size=16 off=12 size=8",
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"map helper access to adjusted map (via const reg): out-of-bound 2",

@@ -7030,6 +7078,7 @@ static struct bpf_test tests[] = {
 		.result = REJECT,
 		.errstr = "invalid access to map value, value_size=16 off=-4 size=8",
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"map helper access to adjusted map (via variable)",

@@ -7052,6 +7101,7 @@ static struct bpf_test tests[] = {
 		.fixup_map_hash_16b = { 3, 11 },
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"map helper access to adjusted map (via variable): no max check",

@@ -7073,6 +7123,7 @@ static struct bpf_test tests[] = {
 		.result = REJECT,
 		.errstr = "R2 unbounded memory access, make sure to bounds check any array access into a map",
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"map helper access to adjusted map (via variable): wrong max check",

@@ -7096,6 +7147,7 @@ static struct bpf_test tests[] = {
 		.result = REJECT,
 		.errstr = "invalid access to map value, value_size=16 off=9 size=8",
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"map element value is preserved across register spilling",

@@ -7366,6 +7418,7 @@ static struct bpf_test tests[] = {
 		},
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to variable memory: stack, bitwise AND, zero included",

@@ -7383,6 +7436,7 @@ static struct bpf_test tests[] = {
 		.errstr = "invalid indirect read from stack off -64+0 size 64",
 		.result = REJECT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to variable memory: stack, bitwise AND + JMP, wrong max",

@@ -7403,6 +7457,7 @@ static struct bpf_test tests[] = {
 		.errstr = "invalid stack type R1 off=-64 access_size=65",
 		.result = REJECT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to variable memory: stack, JMP, correct bounds",

@@ -7431,6 +7486,7 @@ static struct bpf_test tests[] = {
 		},
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to variable memory: stack, JMP (signed), correct bounds",

@@ -7459,6 +7515,7 @@ static struct bpf_test tests[] = {
 		},
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to variable memory: stack, JMP, bounds + offset",

@@ -7480,6 +7537,7 @@ static struct bpf_test tests[] = {
 		.errstr = "invalid stack type R1 off=-64 access_size=65",
 		.result = REJECT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to variable memory: stack, JMP, wrong max",

@@ -7500,6 +7558,7 @@ static struct bpf_test tests[] = {
 		.errstr = "invalid stack type R1 off=-64 access_size=65",
 		.result = REJECT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to variable memory: stack, JMP, no max check",

@@ -7520,6 +7579,7 @@ static struct bpf_test tests[] = {
 		.errstr = "R2 min value is negative, either use unsigned or 'var &= const'",
 		.result = REJECT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to variable memory: stack, JMP, no min check",

@@ -7538,6 +7598,7 @@ static struct bpf_test tests[] = {
 		.errstr = "invalid indirect read from stack off -64+0 size 64",
 		.result = REJECT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to variable memory: stack, JMP (signed), no min check",

@@ -7556,6 +7617,7 @@ static struct bpf_test tests[] = {
 		.errstr = "R2 min value is negative",
 		.result = REJECT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to variable memory: map, JMP, correct bounds",

@@ -7582,6 +7644,7 @@ static struct bpf_test tests[] = {
 		.fixup_map_hash_48b = { 3 },
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to variable memory: map, JMP, wrong max",

@@ -7609,6 +7672,7 @@ static struct bpf_test tests[] = {
 		.errstr = "invalid access to map value, value_size=48 off=0 size=49",
 		.result = REJECT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to variable memory: map adjusted, JMP, correct bounds",

@@ -7636,6 +7700,7 @@ static struct bpf_test tests[] = {
 		.fixup_map_hash_48b = { 3 },
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to variable memory: map adjusted, JMP, wrong max",

@@ -7664,6 +7729,7 @@ static struct bpf_test tests[] = {
 		.errstr = "R1 min value is outside of the array range",
 		.result = REJECT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to variable memory: size = 0 allowed on NULL (ARG_PTR_TO_MEM_OR_NULL)",

@@ -7820,6 +7886,7 @@ static struct bpf_test tests[] = {
 		.errstr = "R1 type=inv expected=fp",
 		.result = REJECT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to variable memory: size > 0 not allowed on NULL (!ARG_PTR_TO_MEM_OR_NULL)",

@@ -7833,6 +7900,7 @@ static struct bpf_test tests[] = {
 		.errstr = "R1 type=inv expected=fp",
 		.result = REJECT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to variable memory: size = 0 allowed on != NULL stack pointer (!ARG_PTR_TO_MEM_OR_NULL)",

@@ -7846,6 +7914,7 @@ static struct bpf_test tests[] = {
 		},
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to variable memory: size = 0 allowed on != NULL map pointer (!ARG_PTR_TO_MEM_OR_NULL)",

@@ -7865,6 +7934,7 @@ static struct bpf_test tests[] = {
 		.fixup_map_hash_8b = { 3 },
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to variable memory: size possible = 0 allowed on != NULL stack pointer (!ARG_PTR_TO_MEM_OR_NULL)",

@@ -7886,6 +7956,7 @@ static struct bpf_test tests[] = {
 		.fixup_map_hash_8b = { 3 },
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to variable memory: size possible = 0 allowed on != NULL map pointer (!ARG_PTR_TO_MEM_OR_NULL)",

@@ -7906,6 +7977,7 @@ static struct bpf_test tests[] = {
 		.fixup_map_hash_8b = { 3 },
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to variable memory: 8 bytes leak",

@@ -7933,6 +8005,7 @@ static struct bpf_test tests[] = {
 		.errstr = "invalid indirect read from stack off -64+32 size 64",
 		.result = REJECT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"helper access to variable memory: 8 bytes no leak (init memory)",

@@ -7959,6 +8032,7 @@ static struct bpf_test tests[] = {
 		},
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"invalid and of negative number",

@@ -8264,6 +8338,7 @@ static struct bpf_test tests[] = {
 		},
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_PERF_EVENT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"check bpf_perf_event_data->sample_period half load permitted",

@@ -8280,6 +8355,7 @@ static struct bpf_test tests[] = {
 		},
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_PERF_EVENT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"check bpf_perf_event_data->sample_period word load permitted",

@@ -8296,6 +8372,7 @@ static struct bpf_test tests[] = {
 		},
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_PERF_EVENT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"check bpf_perf_event_data->sample_period dword load permitted",

@@ -8307,6 +8384,7 @@ static struct bpf_test tests[] = {
 		},
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_PERF_EVENT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"check skb->data half load not permitted",

@@ -10878,6 +10956,7 @@ static struct bpf_test tests[] = {
 			BPF_EXIT_INSN(),
 		},
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 		.result = ACCEPT,
 	},
 	{

@@ -10986,6 +11065,7 @@ static struct bpf_test tests[] = {
 			BPF_EXIT_INSN(),
 		},
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 		.errstr = "last insn is not an exit or jmp",
 		.result = REJECT,
 	},

@@ -11001,6 +11081,7 @@ static struct bpf_test tests[] = {
 			BPF_EXIT_INSN(),
 		},
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 		.errstr = "jump out of range",
 		.result = REJECT,
 	},

@@ -11012,6 +11093,7 @@ static struct bpf_test tests[] = {
 			BPF_EXIT_INSN(),
 		},
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 		.errstr = "BPF_CALL uses reserved fields",
 		.result = REJECT,
 	},

@@ -11025,6 +11107,7 @@ static struct bpf_test tests[] = {
 			BPF_EXIT_INSN(),
 		},
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 		.errstr = "BPF_CALL uses reserved fields",
 		.result = REJECT,
 	},

@@ -11036,6 +11119,7 @@ static struct bpf_test tests[] = {
 			BPF_EXIT_INSN(),
 		},
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 		.errstr = "back-edge from insn 0 to 0",
 		.result = REJECT,
 	},

@@ -11052,6 +11136,7 @@ static struct bpf_test tests[] = {
 			BPF_EXIT_INSN(),
 		},
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 		.errstr = "jump out of range",
 		.result = REJECT,
 	},

@@ -11070,6 +11155,7 @@ static struct bpf_test tests[] = {
 			BPF_EXIT_INSN(),
 		},
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 		.result = ACCEPT,
 	},
 	{

@@ -11087,6 +11173,7 @@ static struct bpf_test tests[] = {
 			BPF_JMP_IMM(BPF_JA, 0, 0, -6),
 		},
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 		.errstr = "back-edge from insn",
 		.result = REJECT,
 	},

@@ -11105,6 +11192,7 @@ static struct bpf_test tests[] = {
 			BPF_EXIT_INSN(),
 		},
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 		.result = ACCEPT,
 	},
 	{

@@ -11122,6 +11210,7 @@ static struct bpf_test tests[] = {
 			BPF_EXIT_INSN(),
 		},
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 		.errstr = "back-edge from insn",
 		.result = REJECT,
 	},

@@ -11136,6 +11225,7 @@ static struct bpf_test tests[] = {
 			BPF_EXIT_INSN(),
 		},
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 		.errstr = "back-edge from insn",
 		.result = REJECT,
 	},

@@ -11148,6 +11238,7 @@ static struct bpf_test tests[] = {
 			BPF_EXIT_INSN(),
 		},
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 		.result = ACCEPT,
 	},
 	{

@@ -11158,6 +11249,7 @@ static struct bpf_test tests[] = {
 			BPF_EXIT_INSN(),
 		},
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 		.errstr = "!read_ok",
 		.result = REJECT,
 	},

@@ -11196,6 +11288,7 @@ static struct bpf_test tests[] = {
 			BPF_EXIT_INSN(),
 		},
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 		.errstr = "R2 !read_ok",
 		.result = REJECT,
 	},

@@ -11354,6 +11447,7 @@ static struct bpf_test tests[] = {
 			BPF_EXIT_INSN(),
 		},
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 		.errstr = "jump out of range from insn 11 to 9",
 		.result = REJECT,
 	},

@@ -11366,6 +11460,7 @@ static struct bpf_test tests[] = {
 			BPF_EXIT_INSN(),
 		},
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 		.errstr = "back-edge",
 		.result = REJECT,
 	},

@@ -11378,6 +11473,7 @@ static struct bpf_test tests[] = {
 			BPF_EXIT_INSN(),
 		},
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 		.errstr = "back-edge",
 		.result = REJECT,
 	},

@@ -11394,6 +11490,7 @@ static struct bpf_test tests[] = {
 			BPF_EXIT_INSN(),
 		},
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 		.errstr = "unreachable insn 6",
 		.result = REJECT,
 	},

@@ -11406,6 +11503,7 @@ static struct bpf_test tests[] = {
 			BPF_EXIT_INSN(),
 		},
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 		.errstr = "invalid destination",
 		.result = REJECT,
 	},

@@ -11418,6 +11516,7 @@ static struct bpf_test tests[] = {
 			BPF_EXIT_INSN(),
 		},
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 		.errstr = "invalid destination",
 		.result = REJECT,
 	},

@@ -11431,6 +11530,7 @@ static struct bpf_test tests[] = {
 			BPF_EXIT_INSN(),
 		},
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 		.errstr = "jump out of range",
 		.result = REJECT,
 	},

@@ -11444,6 +11544,7 @@ static struct bpf_test tests[] = {
 			BPF_EXIT_INSN(),
 		},
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 		.errstr = "jump out of range",
 		.result = REJECT,
 	},

@@ -11458,6 +11559,7 @@ static struct bpf_test tests[] = {
 			BPF_JMP_IMM(BPF_JEQ, BPF_REG_1, 0, -2),
 		},
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 		.errstr = "not an exit",
 		.result = REJECT,
 	},

@@ -11472,6 +11574,7 @@ static struct bpf_test tests[] = {
 			BPF_EXIT_INSN(),
 		},
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 		.errstr = "last insn",
 		.result = REJECT,
 	},

@@ -11487,6 +11590,7 @@ static struct bpf_test tests[] = {
 			BPF_EXIT_INSN(),
 		},
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 		.errstr = "last insn",
 		.result = REJECT,
 	},

@@ -11532,6 +11636,7 @@ static struct bpf_test tests[] = {
 			BPF_EXIT_INSN(),
 		},
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 		.errstr = "not an exit",
 		.result = REJECT,
 	},

@@ -12914,6 +13019,7 @@ static struct bpf_test tests[] = {
 		.errstr = "R6 invalid mem access 'inv'",
 		.result = REJECT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"search pruning: all branches should be verified (invalid stack access)",

@@ -12938,6 +13044,7 @@ static struct bpf_test tests[] = {
 		.errstr = "invalid read from stack off -16+0 size 8",
 		.result = REJECT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"jit: lsh, rsh, arsh by 1",

@@ -13170,6 +13277,7 @@ static struct bpf_test tests[] = {
 		.fixup_map_hash_48b = { 4 },
 		.result = ACCEPT,
 		.prog_type = BPF_PROG_TYPE_TRACEPOINT,
+		.config_disabled = !IS_BUILTIN(CONFIG_BPF_EVENTS),
 	},
 	{
 		"ld_abs: invalid op 1",
Signature · 1 line
2.20.0.rc2.403.gdbc3b29805-goog
#2 lore raw
In reply to Stanislav Fomichev
Quoted 21 lines · Stanislav Fomichev

The following prog types don't make sense without bpf cgroup:
* BPF_PROG_TYPE_CGROUP_SKB
* BPF_PROG_TYPE_CGROUP_SOCK
* BPF_PROG_TYPE_CGROUP_SOCK_ADDR

Skip running verifier tests that exercise these prog types if kernel is built without proper support.

See commit e5c504858a18 ("selftests/bpf: skip verifier sockmap tests on kernels without support") for original motivation.

Signed-off-by Stanislav Fomichev <[email protected]>
---
 tools/testing/selftests/bpf/test_verifier.c | 35 +++++++++++++++++++++
 1 file changed, 35 insertions(+)
tools/testing/selftests/bpf/test_verifier.c +0 -0
index f5015566ae1b..b5470a399996 100644

tools/testing/selftests/bpf/test_verifier.c line 47

Quoted 4 lines
tools/testing/selftests/bpf/test_verifier.c +1 -0
@@ -44,6 +44,7 @@
 /* fallback to all features enabled */
 # define CONFIG_BPF_STREAM_PARSER 1
 # define CONFIG_XDP_SOCKETS 1
+# define CONFIG_CGROUP_BPF 1

I really don't like where these is going.
I think previous set should be reverted.
This is not a scalable approach.
Use libbpf probing approach to check whether feature is present instead.

#3 lore raw
Quoted 17 lines · Alexei Starovoitov
Quoted 16 lines · Stanislav Fomichev

The following prog types don't make sense without bpf cgroup:
* BPF_PROG_TYPE_CGROUP_SKB
* BPF_PROG_TYPE_CGROUP_SOCK
* BPF_PROG_TYPE_CGROUP_SOCK_ADDR

Skip running verifier tests that exercise these prog types if kernel is built without proper support.

See commit e5c504858a18 ("selftests/bpf: skip verifier sockmap tests on kernels without support") for original motivation.

Signed-off-by Stanislav Fomichev <[email protected]>
---
 tools/testing/selftests/bpf/test_verifier.c | 35 +++++++++++++++++++++
 1 file changed, 35 insertions(+)
Quoted 14 lines

tools/testing/selftests/bpf/test_verifier.c line 47

Quoted 9 lines
tools/testing/selftests/bpf/test_verifier.c +1 -0
index f5015566ae1b..b5470a399996 100644
@@ -44,6 +44,7 @@
 /* fallback to all features enabled */
 # define CONFIG_BPF_STREAM_PARSER 1
 # define CONFIG_XDP_SOCKETS 1
+# define CONFIG_CGROUP_BPF 1

I really don't like where these is going.
I think previous set should be reverted.
This is not a scalable approach.
Use libbpf probing approach to check whether feature is present instead.

I can probably add runtime probing instead of depending on compile-time config, but I think that we would still need some per-test mechanism to say that it depends on feature X (per-test .config_disabled or similar).
Will moving these checks to runtime address your concern? (there is sill a scalability issue though)

#4 lore raw
Quoted 32 lines · Stanislav Fomichev
Quoted 17 lines · Alexei Starovoitov
Quoted 16 lines · Stanislav Fomichev

The following prog types don't make sense without bpf cgroup:
* BPF_PROG_TYPE_CGROUP_SKB
* BPF_PROG_TYPE_CGROUP_SOCK
* BPF_PROG_TYPE_CGROUP_SOCK_ADDR

Skip running verifier tests that exercise these prog types if kernel is built without proper support.

See commit e5c504858a18 ("selftests/bpf: skip verifier sockmap tests on kernels without support") for original motivation.

Signed-off-by Stanislav Fomichev <[email protected]>
---
 tools/testing/selftests/bpf/test_verifier.c | 35 +++++++++++++++++++++
 1 file changed, 35 insertions(+)
Quoted 14 lines

tools/testing/selftests/bpf/test_verifier.c line 47

Quoted 9 lines
tools/testing/selftests/bpf/test_verifier.c +1 -0
index f5015566ae1b..b5470a399996 100644
@@ -44,6 +44,7 @@
 /* fallback to all features enabled */
 # define CONFIG_BPF_STREAM_PARSER 1
 # define CONFIG_XDP_SOCKETS 1
+# define CONFIG_CGROUP_BPF 1

I really don't like where these is going.
I think previous set should be reverted.
This is not a scalable approach.
Use libbpf probing approach to check whether feature is present instead.

Quoted 6 lines

I can probably add runtime probing instead of depending on compile-time config, but I think that we would still need some per-test mechanism to say that it depends on feature X (per-test .config_disabled or similar).
Will moving these checks to runtime address your concern? (there is sill a scalability issue though)

you said it youself. config_disabled doesn't scale. hence it's not a solution regardless of macro or runtime probing.

#5 lore raw
Quoted 40 lines · Alexei Starovoitov
Quoted 32 lines · Stanislav Fomichev
Quoted 17 lines · Alexei Starovoitov
Quoted 16 lines · Stanislav Fomichev

The following prog types don't make sense without bpf cgroup:
* BPF_PROG_TYPE_CGROUP_SKB
* BPF_PROG_TYPE_CGROUP_SOCK
* BPF_PROG_TYPE_CGROUP_SOCK_ADDR

Skip running verifier tests that exercise these prog types if kernel is built without proper support.

See commit e5c504858a18 ("selftests/bpf: skip verifier sockmap tests on kernels without support") for original motivation.

Signed-off-by Stanislav Fomichev <[email protected]>
---
 tools/testing/selftests/bpf/test_verifier.c | 35 +++++++++++++++++++++
 1 file changed, 35 insertions(+)
Quoted 14 lines

tools/testing/selftests/bpf/test_verifier.c line 47

Quoted 9 lines
tools/testing/selftests/bpf/test_verifier.c +1 -0
index f5015566ae1b..b5470a399996 100644
@@ -44,6 +44,7 @@
 /* fallback to all features enabled */
 # define CONFIG_BPF_STREAM_PARSER 1
 # define CONFIG_XDP_SOCKETS 1
+# define CONFIG_CGROUP_BPF 1

I really don't like where these is going.
I think previous set should be reverted.
This is not a scalable approach.
Use libbpf probing approach to check whether feature is present instead.

Quoted 6 lines

I can probably add runtime probing instead of depending on compile-time config, but I think that we would still need some per-test mechanism to say that it depends on feature X (per-test .config_disabled or similar).
Will moving these checks to runtime address your concern? (there is sill a scalability issue though)

Quoted 2 lines

you said it youself. config_disabled doesn't scale. hence it's not a solution regardless of macro or runtime probing.

Let me see if I can use per-test prog_type for this type of probing. Load 'return 0' program per-prog_type and use it as an indication of runtime support. This should probably work in the majority of the cases. I'll get back to you shortly.

#6 lore raw
Quoted 41 lines · Stanislav Fomichev
Quoted 40 lines · Alexei Starovoitov
Quoted 38 lines · Stanislav Fomichev
Quoted 17 lines · Alexei Starovoitov
Quoted 16 lines · Stanislav Fomichev

The following prog types don't make sense without bpf cgroup:
* BPF_PROG_TYPE_CGROUP_SKB
* BPF_PROG_TYPE_CGROUP_SOCK
* BPF_PROG_TYPE_CGROUP_SOCK_ADDR

Skip running verifier tests that exercise these prog types if kernel is built without proper support.

See commit e5c504858a18 ("selftests/bpf: skip verifier sockmap tests on kernels without support") for original motivation.

Signed-off-by Stanislav Fomichev <[email protected]>
---
 tools/testing/selftests/bpf/test_verifier.c | 35 +++++++++++++++++++++
 1 file changed, 35 insertions(+)
Quoted 14 lines

tools/testing/selftests/bpf/test_verifier.c line 47

Quoted 9 lines
tools/testing/selftests/bpf/test_verifier.c +1 -0
index f5015566ae1b..b5470a399996 100644
@@ -44,6 +44,7 @@
 /* fallback to all features enabled */
 # define CONFIG_BPF_STREAM_PARSER 1
 # define CONFIG_XDP_SOCKETS 1
+# define CONFIG_CGROUP_BPF 1

I really don't like where these is going.
I think previous set should be reverted.
This is not a scalable approach.
Use libbpf probing approach to check whether feature is present instead.

I can probably add runtime probing instead of depending on compile-time config, but I think that we would still need some per-test mechanism to say that it depends on feature X (per-test .config_disabled or similar).
Will moving these checks to runtime address your concern? (there is sill a scalability issue though)

Quoted 6 lines
Quoted 2 lines

you said it youself. config_disabled doesn't scale. hence it's not a solution regardless of macro or runtime probing.

Let me see if I can use per-test prog_type for this type of probing. Load 'return 0' program per-prog_type and use it as an indication of runtime support. This should probably work in the majority of the cases. I'll get back to you shortly.

How about doing something like the (very work-in-progress) patch below? It mostly gets the job done, I think I need to do similar probing for maps and skip the tests that have fixup_map_{sockmap,sockhash,xskmap,stacktrace} in case appropriate map type is not supported.

---

include/uapi/linux/bpf.h +3 -0
index aa582cd5bfcf..e55c116ff971 100644
@@ -157,8 +157,11 @@ enum bpf_prog_type {
 	BPF_PROG_TYPE_LIRC_MODE2,
 	BPF_PROG_TYPE_SK_REUSEPORT,
 	BPF_PROG_TYPE_FLOW_DISSECTOR,
+	__MAX_BPF_PROG_TYPE
 };
 
+#define MAX_BPF_PROG_TYPE __MAX_BPF_PROG_TYPE
+
 enum bpf_attach_type {
 	BPF_CGROUP_INET_INGRESS,
 	BPF_CGROUP_INET_EGRESS,
tools/include/uapi/linux/bpf.h +3 -0
index aa582cd5bfcf..e55c116ff971 100644
@@ -157,8 +157,11 @@ enum bpf_prog_type {
 	BPF_PROG_TYPE_LIRC_MODE2,
 	BPF_PROG_TYPE_SK_REUSEPORT,
 	BPF_PROG_TYPE_FLOW_DISSECTOR,
+	__MAX_BPF_PROG_TYPE
 };
 
+#define MAX_BPF_PROG_TYPE __MAX_BPF_PROG_TYPE
+
 enum bpf_attach_type {
 	BPF_CGROUP_INET_INGRESS,
 	BPF_CGROUP_INET_EGRESS,
tools/lib/bpf/libbpf.c +1 -0
index e2bc75ee1614..40f26f50556d 100644
@@ -1726,6 +1726,7 @@ static bool bpf_prog_type__needs_kver(enum bpf_prog_type type)
 	case BPF_PROG_TYPE_TRACEPOINT:
 	case BPF_PROG_TYPE_RAW_TRACEPOINT:
 	case BPF_PROG_TYPE_PERF_EVENT:
+	case __MAX_BPF_PROG_TYPE:
 		return false;
 	case BPF_PROG_TYPE_KPROBE:
 	default:
tools/testing/selftests/bpf/test_verifier.c +49 -2

68 lines not on this page · raw message

#7 lore raw
Quoted 61 lines · Stanislav Fomichev
Quoted 41 lines · Stanislav Fomichev
Quoted 40 lines · Alexei Starovoitov
Quoted 38 lines · Stanislav Fomichev
Quoted 17 lines · Alexei Starovoitov
Quoted 16 lines · Stanislav Fomichev

The following prog types don't make sense without bpf cgroup:
* BPF_PROG_TYPE_CGROUP_SKB
* BPF_PROG_TYPE_CGROUP_SOCK
* BPF_PROG_TYPE_CGROUP_SOCK_ADDR

Skip running verifier tests that exercise these prog types if kernel is built without proper support.

See commit e5c504858a18 ("selftests/bpf: skip verifier sockmap tests on kernels without support") for original motivation.

Signed-off-by Stanislav Fomichev <[email protected]>
---
 tools/testing/selftests/bpf/test_verifier.c | 35 +++++++++++++++++++++
 1 file changed, 35 insertions(+)
Quoted 14 lines

tools/testing/selftests/bpf/test_verifier.c line 47

Quoted 9 lines
tools/testing/selftests/bpf/test_verifier.c +1 -0
index f5015566ae1b..b5470a399996 100644
@@ -44,6 +44,7 @@
 /* fallback to all features enabled */
 # define CONFIG_BPF_STREAM_PARSER 1
 # define CONFIG_XDP_SOCKETS 1
+# define CONFIG_CGROUP_BPF 1

I really don't like where these is going.
I think previous set should be reverted.
This is not a scalable approach.
Use libbpf probing approach to check whether feature is present instead.

I can probably add runtime probing instead of depending on compile-time config, but I think that we would still need some per-test mechanism to say that it depends on feature X (per-test .config_disabled or similar).
Will moving these checks to runtime address your concern? (there is sill a scalability issue though)

Quoted 6 lines
Quoted 2 lines

you said it youself. config_disabled doesn't scale. hence it's not a solution regardless of macro or runtime probing.

Let me see if I can use per-test prog_type for this type of probing. Load 'return 0' program per-prog_type and use it as an indication of runtime support. This should probably work in the majority of the cases. I'll get back to you shortly.

How about doing something like the (very work-in-progress) patch below? It mostly gets the job done, I think I need to do similar probing for maps and skip the tests that have fixup_map_{sockmap,sockhash,xskmap,stacktrace} in case appropriate map type is not supported.

---

include/uapi/linux/bpf.h +0 -0
index aa582cd5bfcf..e55c116ff971 100644

include/uapi/linux/bpf.h enum bpf_prog_type { · line 164

Quoted 8 lines
include/uapi/linux/bpf.h +3 -0
@@ -157,8 +157,11 @@ enum bpf_prog_type {
 	BPF_PROG_TYPE_LIRC_MODE2,
 	BPF_PROG_TYPE_SK_REUSEPORT,
 	BPF_PROG_TYPE_FLOW_DISSECTOR,
+	__MAX_BPF_PROG_TYPE
 };
 
+#define MAX_BPF_PROG_TYPE __MAX_BPF_PROG_TYPE
+

that won't work either.

"bpf feature set" is a lot more than number of program and map types the kernel supports. There are all sorts of helper combinations, hooks, and verifier improvements. test_verifier.c must test all that.
I don't think there is a way to make usptream test_verfier.c not to report failure on older kernels.
I think you have to backport and enable everything if you want to run the latest test_verifier.c on your kernel. Other options are: deal with test failures in post processing or have test_verifier.c specific for your kernel. Since you've decided not to backport kernel side of sockmap, don't enable these tests in _your_ test_verifier.c.

I've dropped two 'skip * sockmap' patches in bpf-next.

#8 lore raw
Quoted 7 lines · Alexei Starovoitov

that won't work either.
"bpf feature set" is a lot more than number of program and map types the kernel supports. There are all sorts of helper combinations, hooks, and verifier improvements. test_verifier.c must test all that.
I don't think there is a way to make usptream test_verfier.c not to report failure on older kernels.

But it's not just older kernels; AIUI there are config options that also affect this.  Are you saying that test_verifier should only be expected to run / pass on allyesconfig kernels?

I think that for the cases where we _can_ do it easily (which seems to be precisely things like prog_type which don't require any additional annotation of test cases) we should skip tests that aren't supported by the running kernel.

An alternative is to have a whitelist of verifier error messages that all mean "your kernel is missing a feature this program needs" in test_verifier, so that any test case that hits any of them can be marked as skipped.  That doesn't cover every possibility (sometimes the same message could be caused by a plain old invalid program) but it might help.

-Ed

#9 lore raw
Quoted 11 lines · Edward Cree
Quoted 7 lines · Alexei Starovoitov

that won't work either.
"bpf feature set" is a lot more than number of program and map types the kernel supports. There are all sorts of helper combinations, hooks, and verifier improvements. test_verifier.c must test all that.
I don't think there is a way to make usptream test_verfier.c not to report failure on older kernels.

But it's not just older kernels; AIUI there are config options that also affect this.  Are you saying that test_verifier should only be expected to run / pass on allyesconfig kernels?

not allyesconfig, but allbpfyesconfig.

Quoted 4 lines

I think that for the cases where we _can_ do it easily (which seems to be precisely things like prog_type which don't require any additional annotation of test cases) we should skip tests that aren't supported by the running kernel.

Submitters of bpf patches need to enable all bpf features in their kernels and make sure that all of the selftests/bpf are still passing.
"but I don't use XDP today" or "LLVM is hard to install" is not an excuse.

Before I apply any patch I build and test manually. If anything breaks means folks didn't do enough testing and karma suffers.

#10 lore raw
Quoted 9 lines · Alexei Starovoitov
Quoted 8 lines · Edward Cree
Quoted 7 lines · Alexei Starovoitov

that won't work either.
"bpf feature set" is a lot more than number of program and map types the kernel supports. There are all sorts of helper combinations, hooks, and verifier improvements. test_verifier.c must test all that.
I don't think there is a way to make usptream test_verfier.c not to report failure on older kernels.

Quoted 5 lines
Quoted 3 lines

But it's not just older kernels; AIUI there are config options that also affect this.  Are you saying that test_verifier should only be expected to run / pass on allyesconfig kernels?

not allyesconfig, but allbpfyesconfig.

Yes, to reiterate, this patch series was mostly about running verifier against the kernel where we don't have all bpf features enabled (to make sure we also don't break them by having some (un)related inhouse patches).

Quoted 11 lines
Quoted 4 lines

I think that for the cases where we _can_ do it easily (which seems to be precisely things like prog_type which don't require any additional annotation of test cases) we should skip tests that aren't supported by the running kernel.

Submitters of bpf patches need to enable all bpf features in their kernels and make sure that all of the selftests/bpf are still passing.
"but I don't use XDP today" or "LLVM is hard to install" is not an excuse.

Quoted 3 lines

Before I apply any patch I build and test manually. If anything breaks means folks didn't do enough testing and karma suffers.

Your use case would still work, you just make sure there are no skips. Karma would still suffer if you run the tests and they fail, but for the submitter they were skipped ;-)

To summarize, I like your idea about doing runtime tests and I think I can make it work quite nicely without any config_disabled ugliness by looking at the prog_type of each test.
I can send an RFC patch series out if there still a small chance you could take it, but if you've already set you mind, I'd just keep them internally. So let me know if you have a hard NACK on the runtime probing approach or there is still some wiggle room.

#11 lore raw
Quoted 8 lines · Stanislav Fomichev

To summarize, I like your idea about doing runtime tests and I think I can make it work quite nicely without any config_disabled ugliness by looking at the prog_type of each test.
I can send an RFC patch series out if there still a small chance you could take it, but if you've already set you mind, I'd just keep them internally. So let me know if you have a hard NACK on the runtime probing approach or there is still some wiggle room.

If there is no uapi/bpf.h change, it's likely fine.
Like if test_verifier tries to load 'foo() {return 0;}' prog for the .prog_type in the test that failed to confirm that
such prog type is supported by the kernel...
that is fine, since no extra prog_loads are happening for the default case.

maintainer
#12 lore raw
Quoted 10 lines · Alexei Starovoitov
Quoted 8 lines · Stanislav Fomichev

To summarize, I like your idea about doing runtime tests and I think I can make it work quite nicely without any config_disabled ugliness by looking at the prog_type of each test.
I can send an RFC patch series out if there still a small chance you could take it, but if you've already set you mind, I'd just keep them internally. So let me know if you have a hard NACK on the runtime probing approach or there is still some wiggle room.

Quoted 5 lines

If there is no uapi/bpf.h change, it's likely fine.
Like if test_verifier tries to load 'foo() {return 0;}' prog for the .prog_type in the test that failed to confirm that
such prog type is supported by the kernel...
that is fine, since no extra prog_loads are happening for the default case.

I think this would kind of go along the lines of what Quentin is working on. Idea [0] is to consolidate effort into bpftool so that one can do something like bpftool kernel probe and it generates a header file with CONFIG_* defines for features where bpftool was able to successfully probe the underlying kernel with. This would allow developers to include this header generation as part of the build workflow and avoid having to implement similar probing mechanism in various projects over and over again which aim to run on different kernel versions. I'm wondering whether it would make sense to split the probing part and put it into libbpf where then bpftool is only responsible to call the API and write out the defines? That way, the runtime probing could potentially be reused for selftests as well?

Thanks,
Daniel

[0] slide 8,12: http://vger.kernel.org/lpc_bpf2018_talks/qmo-bpf-slides-v2.pdf

#13 lore raw

2018-12-13 12:52 UTC+0100 ~ Daniel Borkmann <[email protected]>

Quoted 29 lines · Alexei Starovoitov
Quoted 10 lines · Stanislav Fomichev
Quoted 8 lines

To summarize, I like your idea about doing runtime tests and I think I can make it work quite nicely without any config_disabled ugliness by looking at the prog_type of each test.
I can send an RFC patch series out if there still a small chance you could take it, but if you've already set you mind, I'd just keep them internally. So let me know if you have a hard NACK on the runtime probing approach or there is still some wiggle room.

Quoted 5 lines

If there is no uapi/bpf.h change, it's likely fine.
Like if test_verifier tries to load 'foo() {return 0;}' prog for the .prog_type in the test that failed to confirm that
such prog type is supported by the kernel...
that is fine, since no extra prog_loads are happening for the default case.

I think this would kind of go along the lines of what Quentin is working on. Idea [0] is to consolidate effort into bpftool so that one can do something like bpftool kernel probe and it generates a header file with CONFIG_* defines for features where bpftool was able to successfully probe the underlying kernel with. This would allow developers to include this header generation as part of the build workflow and avoid having to implement similar probing mechanism in various projects over and over again which aim to run on different kernel versions. I'm wondering whether it would make sense to split the probing part and put it into libbpf where then bpftool is only responsible to call the API and write out the defines? That way, the runtime probing could potentially be reused for selftests as well?

Quoted 4 lines

Thanks,
Daniel

[0] slide 8,12: http://vger.kernel.org/lpc_bpf2018_talks/qmo-bpf-slides-v2.pdf

Hi Daniel, Stanislav,

Thanks for the Cc. I got somewhat delayed in my series, but I just finished it and was about to post the patches to the mailing list. Since the code is ready to go I'll send it in its current shape, i.e. all probes implemented on bpftool side, and we can hopefully use it as a support for further discussion.

Quentin

#14 lore raw
Quoted 29 lines · Quentin Monnet

2018-12-13 12:52 UTC+0100 ~ Daniel Borkmann <[email protected]>

Quoted 28 lines · Alexei Starovoitov
Quoted 10 lines · Stanislav Fomichev
Quoted 8 lines

To summarize, I like your idea about doing runtime tests and I think I can make it work quite nicely without any config_disabled ugliness by looking at the prog_type of each test.
I can send an RFC patch series out if there still a small chance you could take it, but if you've already set you mind, I'd just keep them internally. So let me know if you have a hard NACK on the runtime probing approach or there is still some wiggle room.

Quoted 5 lines

If there is no uapi/bpf.h change, it's likely fine.
Like if test_verifier tries to load 'foo() {return 0;}' prog for the .prog_type in the test that failed to confirm that
such prog type is supported by the kernel...
that is fine, since no extra prog_loads are happening for the default case.

I think this would kind of go along the lines of what Quentin is working on. Idea [0] is to consolidate effort into bpftool so that one can do something like bpftool kernel probe and it generates a header file with CONFIG_* defines for features where bpftool was able to successfully probe the underlying kernel with. This would allow developers to include this header generation as part of the build workflow and avoid having to implement similar probing mechanism in various projects over and over again which aim to run on different kernel versions. I'm wondering whether it would make sense to split the probing part and put it into libbpf where then bpftool is only responsible to call the API and write out the defines? That way, the runtime probing could potentially be reused for selftests as well?

+1

Keeping those low-level probing details in the libbpf seems like a good idea. bpftool feature can then be just a simple a frontend to those probes to dump them in C/JSON. Tests and other tools can use the probes on the target host via libbpf to degrade some functionality or print nice error messages instead of 'EINVAL: Invalid argument'.

Quoted 6 lines
Quoted 5 lines

Thanks,
Daniel

[0] slide 8,12: http://vger.kernel.org/lpc_bpf2018_talks/qmo-bpf-slides-v2.pdf

Quoted 7 lines

Hi Daniel, Stanislav,

Thanks for the Cc. I got somewhat delayed in my series, but I just finished it and was about to post the patches to the mailing list. Since the code is ready to go I'll send it in its current shape, i.e. all probes implemented on bpftool side, and we can hopefully use it as a support for further discussion.

Just out of curiosity: what's the usecase of generating C defines via bpftool? Is it for the BCC case where we have the complier on the target host and can run bpftool+bcc there?

Quoted 2 lines

Quentin

#15 lore raw

2018-12-13 08:37 UTC-0800 ~ Stanislav Fomichev <[email protected]>

Quoted 46 lines · Quentin Monnet
Quoted 29 lines

2018-12-13 12:52 UTC+0100 ~ Daniel Borkmann <[email protected]>

Quoted 28 lines · Alexei Starovoitov
Quoted 10 lines · Stanislav Fomichev
Quoted 8 lines

To summarize, I like your idea about doing runtime tests and I think I can make it work quite nicely without any config_disabled ugliness by looking at the prog_type of each test.
I can send an RFC patch series out if there still a small chance you could take it, but if you've already set you mind, I'd just keep them internally. So let me know if you have a hard NACK on the runtime probing approach or there is still some wiggle room.

Quoted 5 lines

If there is no uapi/bpf.h change, it's likely fine.
Like if test_verifier tries to load 'foo() {return 0;}' prog for the .prog_type in the test that failed to confirm that
such prog type is supported by the kernel...
that is fine, since no extra prog_loads are happening for the default case.

I think this would kind of go along the lines of what Quentin is working on. Idea [0] is to consolidate effort into bpftool so that one can do something like bpftool kernel probe and it generates a header file with CONFIG_* defines for features where bpftool was able to successfully probe the underlying kernel with. This would allow developers to include this header generation as part of the build workflow and avoid having to implement similar probing mechanism in various projects over and over again which aim to run on different kernel versions. I'm wondering whether it would make sense to split the probing part and put it into libbpf where then bpftool is only responsible to call the API and write out the defines? That way, the runtime probing could potentially be reused for selftests as well?

+1

Keeping those low-level probing details in the libbpf seems like a good idea. bpftool feature can then be just a simple a frontend to those probes to dump them in C/JSON. Tests and other tools can use the probes on the target host via libbpf to degrade some functionality or print nice error messages instead of 'EINVAL: Invalid argument'.

Quoted 8 lines
Quoted 5 lines

Thanks,
Daniel

[0] slide 8,12: http://vger.kernel.org/lpc_bpf2018_talks/qmo-bpf-slides-v2.pdf

Hi Daniel, Stanislav,

Quoted 8 lines
Quoted 5 lines

Thanks for the Cc. I got somewhat delayed in my series, but I just finished it and was about to post the patches to the mailing list. Since the code is ready to go I'll send it in its current shape, i.e. all probes implemented on bpftool side, and we can hopefully use it as a support for further discussion.

Just out of curiosity: what's the usecase of generating C defines via bpftool? Is it for the BCC case where we have the complier on the target host and can run bpftool+bcc there?

Yes, this is the idea. It produces a header file that one can include at compile time in a project: bcc is a candidate, Cilium would be another (see [0], [1]), for example. As mentioned by Daniel, I suspect a growing number of projects will need this kind of probing, so having bpftool able to do the work and to dump the result as macros could avoid implementing multiple versions of the same thing.

[0] https://github.com/cilium/cilium/blob/master/bpf/run_probes.sh
[1] https://github.com/cilium/cilium/tree/master/bpf/probes

#16 lore raw
Quoted 56 lines · Quentin Monnet

2018-12-13 08:37 UTC-0800 ~ Stanislav Fomichev <[email protected]>

Quoted 46 lines · Quentin Monnet
Quoted 29 lines

2018-12-13 12:52 UTC+0100 ~ Daniel Borkmann <[email protected]>

Quoted 28 lines · Alexei Starovoitov
Quoted 10 lines · Stanislav Fomichev
Quoted 8 lines

To summarize, I like your idea about doing runtime tests and I think I can make it work quite nicely without any config_disabled ugliness by looking at the prog_type of each test.
I can send an RFC patch series out if there still a small chance you could take it, but if you've already set you mind, I'd just keep them internally. So let me know if you have a hard NACK on the runtime probing approach or there is still some wiggle room.

Quoted 5 lines

If there is no uapi/bpf.h change, it's likely fine.
Like if test_verifier tries to load 'foo() {return 0;}' prog for the .prog_type in the test that failed to confirm that
such prog type is supported by the kernel...
that is fine, since no extra prog_loads are happening for the default case.

I think this would kind of go along the lines of what Quentin is working on. Idea [0] is to consolidate effort into bpftool so that one can do something like bpftool kernel probe and it generates a header file with CONFIG_* defines for features where bpftool was able to successfully probe the underlying kernel with. This would allow developers to include this header generation as part of the build workflow and avoid having to implement similar probing mechanism in various projects over and over again which aim to run on different kernel versions. I'm wondering whether it would make sense to split the probing part and put it into libbpf where then bpftool is only responsible to call the API and write out the defines? That way, the runtime probing could potentially be reused for selftests as well?

+1

Keeping those low-level probing details in the libbpf seems like a good idea. bpftool feature can then be just a simple a frontend to those probes to dump them in C/JSON. Tests and other tools can use the probes on the target host via libbpf to degrade some functionality or print nice error messages instead of 'EINVAL: Invalid argument'.

Quoted 8 lines
Quoted 5 lines

Thanks,
Daniel

[0] slide 8,12: http://vger.kernel.org/lpc_bpf2018_talks/qmo-bpf-slides-v2.pdf

Hi Daniel, Stanislav,

Quoted 8 lines
Quoted 5 lines

Thanks for the Cc. I got somewhat delayed in my series, but I just finished it and was about to post the patches to the mailing list. Since the code is ready to go I'll send it in its current shape, i.e. all probes implemented on bpftool side, and we can hopefully use it as a support for further discussion.

Just out of curiosity: what's the usecase of generating C defines via bpftool? Is it for the BCC case where we have the complier on the target host and can run bpftool+bcc there?

Quoted 6 lines

Yes, this is the idea. It produces a header file that one can include at compile time in a project: bcc is a candidate, Cilium would be another (see [0], [1]), for example. As mentioned by Daniel, I suspect a growing number of projects will need this kind of probing, so having bpftool able to do the work and to dump the result as macros could avoid implementing multiple versions of the same thing.

I'm also interested in a usecase where we don't have a compiler on the target, but runtime should still be able to proble some features and maybe refuse the service or degrade to a different program/feature. Those are the same probes, but executed dynamically on the target and I think having them (maybe not all?) in the libbpf is useful. WDYT?

Quoted 3 lines

[0] https://github.com/cilium/cilium/blob/master/bpf/run_probes.sh
[1] https://github.com/cilium/cilium/tree/master/bpf/probes

#17 lore raw

2018-12-13 09:10 UTC-0800 ~ Stanislav Fomichev <[email protected]>

Quoted 63 lines · Quentin Monnet
Quoted 56 lines

2018-12-13 08:37 UTC-0800 ~ Stanislav Fomichev <[email protected]>

Quoted 46 lines · Quentin Monnet
Quoted 29 lines

2018-12-13 12:52 UTC+0100 ~ Daniel Borkmann <[email protected]>

Quoted 28 lines · Alexei Starovoitov
Quoted 10 lines · Stanislav Fomichev
Quoted 8 lines

To summarize, I like your idea about doing runtime tests and I think I can make it work quite nicely without any config_disabled ugliness by looking at the prog_type of each test.
I can send an RFC patch series out if there still a small chance you could take it, but if you've already set you mind, I'd just keep them internally. So let me know if you have a hard NACK on the runtime probing approach or there is still some wiggle room.

Quoted 5 lines

If there is no uapi/bpf.h change, it's likely fine.
Like if test_verifier tries to load 'foo() {return 0;}' prog for the .prog_type in the test that failed to confirm that
such prog type is supported by the kernel...
that is fine, since no extra prog_loads are happening for the default case.

I think this would kind of go along the lines of what Quentin is working on. Idea [0] is to consolidate effort into bpftool so that one can do something like bpftool kernel probe and it generates a header file with CONFIG_* defines for features where bpftool was able to successfully probe the underlying kernel with. This would allow developers to include this header generation as part of the build workflow and avoid having to implement similar probing mechanism in various projects over and over again which aim to run on different kernel versions. I'm wondering whether it would make sense to split the probing part and put it into libbpf where then bpftool is only responsible to call the API and write out the defines? That way, the runtime probing could potentially be reused for selftests as well?

+1

Keeping those low-level probing details in the libbpf seems like a good idea. bpftool feature can then be just a simple a frontend to those probes to dump them in C/JSON. Tests and other tools can use the probes on the target host via libbpf to degrade some functionality or print nice error messages instead of 'EINVAL: Invalid argument'.

Quoted 8 lines
Quoted 5 lines

Thanks,
Daniel

[0] slide 8,12: http://vger.kernel.org/lpc_bpf2018_talks/qmo-bpf-slides-v2.pdf

Hi Daniel, Stanislav,

Quoted 8 lines
Quoted 5 lines

Thanks for the Cc. I got somewhat delayed in my series, but I just finished it and was about to post the patches to the mailing list. Since the code is ready to go I'll send it in its current shape, i.e. all probes implemented on bpftool side, and we can hopefully use it as a support for further discussion.

Just out of curiosity: what's the usecase of generating C defines via bpftool? Is it for the BCC case where we have the complier on the target host and can run bpftool+bcc there?

Quoted 6 lines

Yes, this is the idea. It produces a header file that one can include at compile time in a project: bcc is a candidate, Cilium would be another (see [0], [1]), for example. As mentioned by Daniel, I suspect a growing number of projects will need this kind of probing, so having bpftool able to do the work and to dump the result as macros could avoid implementing multiple versions of the same thing.

Quoted 5 lines

I'm also interested in a usecase where we don't have a compiler on the target, but runtime should still be able to proble some features and maybe refuse the service or degrade to a different program/feature. Those are the same probes, but executed dynamically on the target and I think having them (maybe not all?) in the libbpf is useful. WDYT?

You're the one with the use case, so I can't really argue against that :). More seriously, I also think having some of the probing in libbpf would make sense. If you just don't want the compiler on the target you could still produce the header file on that machine and send that file to some other host where you compile your soft, but if you need the probes at runtime I can't really see a better way than moving them to libbpf indeed.