[PATCH bpf-next 1/2] selftests/bpf: skip verifier tests that depend on CONFIG_CGROUP_BPF

[PATCH bpf-next 1/2] selftests/bpf: skip verifier tests that depend on CONFIG_CGROUP_BPF

[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 <sdf@google.com>
---
 tools/testing/selftests/bpf/test_verifier.c | 35 +++++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/tools/testing/selftests/bpf/test_verifier.c b/tools/testing/selftests/bpf/test_verifier.c
index f5015566ae1b..b5470a399996 100644
--- a/tools/testing/selftests/bpf/test_verifier.c
+++ b/tools/testing/selftests/bpf/test_verifier.c
@@ -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",
-- 
2.20.0.rc2.403.gdbc3b29805-goog

[PATCH bpf-next 2/2] selftests/bpf: skip verifier tests that depend on CONFIG_BPF_EVENTS

[Stanislav Fomichev]

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 <sdf@google.com>
---
 tools/testing/selftests/bpf/test_verifier.c | 108 ++++++++++++++++++++
 1 file changed, 108 insertions(+)

diff --git a/tools/testing/selftests/bpf/test_verifier.c b/tools/testing/selftests/bpf/test_verifier.c
index b5470a399996..5b291daf8948 100644
--- a/tools/testing/selftests/bpf/test_verifier.c
+++ b/tools/testing/selftests/bpf/test_verifier.c
@@ -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",
-- 
2.20.0.rc2.403.gdbc3b29805-goog

Re: [PATCH bpf-next 1/2] selftests/bpf: skip verifier tests that depend on CONFIG_CGROUP_BPF

[Alexei Starovoitov]

On Wed, Dec 12, 2018 at 10:27:24AM -0800, Stanislav Fomichev wrote:
> 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 <sdf@google.com>
> ---
>  tools/testing/selftests/bpf/test_verifier.c | 35 +++++++++++++++++++++
>  1 file changed, 35 insertions(+)
> 
> diff --git a/tools/testing/selftests/bpf/test_verifier.c b/tools/testing/selftests/bpf/test_verifier.c
> index f5015566ae1b..b5470a399996 100644
> --- a/tools/testing/selftests/bpf/test_verifier.c
> +++ b/tools/testing/selftests/bpf/test_verifier.c
> @@ -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.

Re: [PATCH bpf-next 1/2] selftests/bpf: skip verifier tests that depend on CONFIG_CGROUP_BPF

[Stanislav Fomichev]

On 12/12, Alexei Starovoitov wrote:
> On Wed, Dec 12, 2018 at 10:27:24AM -0800, Stanislav Fomichev wrote:
> > 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 <sdf@google.com>
> > ---
> >  tools/testing/selftests/bpf/test_verifier.c | 35 +++++++++++++++++++++
> >  1 file changed, 35 insertions(+)
> > 
> > diff --git a/tools/testing/selftests/bpf/test_verifier.c b/tools/testing/selftests/bpf/test_verifier.c
> > index f5015566ae1b..b5470a399996 100644
> > --- a/tools/testing/selftests/bpf/test_verifier.c
> > +++ b/tools/testing/selftests/bpf/test_verifier.c
> > @@ -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)

Re: [PATCH bpf-next 1/2] selftests/bpf: skip verifier tests that depend on CONFIG_CGROUP_BPF

[Alexei Starovoitov]

On Wed, Dec 12, 2018 at 10:59:13AM -0800, Stanislav Fomichev wrote:
> On 12/12, Alexei Starovoitov wrote:
> > On Wed, Dec 12, 2018 at 10:27:24AM -0800, Stanislav Fomichev wrote:
> > > 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 <sdf@google.com>
> > > ---
> > >  tools/testing/selftests/bpf/test_verifier.c | 35 +++++++++++++++++++++
> > >  1 file changed, 35 insertions(+)
> > > 
> > > diff --git a/tools/testing/selftests/bpf/test_verifier.c b/tools/testing/selftests/bpf/test_verifier.c
> > > index f5015566ae1b..b5470a399996 100644
> > > --- a/tools/testing/selftests/bpf/test_verifier.c
> > > +++ b/tools/testing/selftests/bpf/test_verifier.c
> > > @@ -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)

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

Re: [PATCH bpf-next 1/2] selftests/bpf: skip verifier tests that depend on CONFIG_CGROUP_BPF

[Stanislav Fomichev]

On 12/12, Alexei Starovoitov wrote:
> On Wed, Dec 12, 2018 at 10:59:13AM -0800, Stanislav Fomichev wrote:
> > On 12/12, Alexei Starovoitov wrote:
> > > On Wed, Dec 12, 2018 at 10:27:24AM -0800, Stanislav Fomichev wrote:
> > > > 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 <sdf@google.com>
> > > > ---
> > > >  tools/testing/selftests/bpf/test_verifier.c | 35 +++++++++++++++++++++
> > > >  1 file changed, 35 insertions(+)
> > > > 
> > > > diff --git a/tools/testing/selftests/bpf/test_verifier.c b/tools/testing/selftests/bpf/test_verifier.c
> > > > index f5015566ae1b..b5470a399996 100644
> > > > --- a/tools/testing/selftests/bpf/test_verifier.c
> > > > +++ b/tools/testing/selftests/bpf/test_verifier.c
> > > > @@ -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)
> 
> 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.

Re: [PATCH bpf-next 1/2] selftests/bpf: skip verifier tests that depend on CONFIG_CGROUP_BPF

[Stanislav Fomichev]

On 12/12, Stanislav Fomichev wrote:
> On 12/12, Alexei Starovoitov wrote:
> > On Wed, Dec 12, 2018 at 10:59:13AM -0800, Stanislav Fomichev wrote:
> > > On 12/12, Alexei Starovoitov wrote:
> > > > On Wed, Dec 12, 2018 at 10:27:24AM -0800, Stanislav Fomichev wrote:
> > > > > 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 <sdf@google.com>
> > > > > ---
> > > > >  tools/testing/selftests/bpf/test_verifier.c | 35 +++++++++++++++++++++
> > > > >  1 file changed, 35 insertions(+)
> > > > > 
> > > > > diff --git a/tools/testing/selftests/bpf/test_verifier.c b/tools/testing/selftests/bpf/test_verifier.c
> > > > > index f5015566ae1b..b5470a399996 100644
> > > > > --- a/tools/testing/selftests/bpf/test_verifier.c
> > > > > +++ b/tools/testing/selftests/bpf/test_verifier.c
> > > > > @@ -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)
> > 
> > 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.

---

diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index aa582cd5bfcf..e55c116ff971 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -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,
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index aa582cd5bfcf..e55c116ff971 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -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,
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index e2bc75ee1614..40f26f50556d 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -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:
diff --git a/tools/testing/selftests/bpf/test_verifier.c b/tools/testing/selftests/bpf/test_verifier.c
index f5015566ae1b..e86a4e0ef921 100644
--- a/tools/testing/selftests/bpf/test_verifier.c
+++ b/tools/testing/selftests/bpf/test_verifier.c
@@ -93,6 +93,52 @@ struct bpf_test {
 	bool config_disabled;
 };
 
+/* TODO: move this to probe_helpers.[ch] to be able to share with test_maps.c */
+/* {{{ */
+static bool __bpf_proge_prog_type(enum bpf_prog_type prog_type)
+{
+	struct bpf_load_program_attr attr;
+	struct bpf_insn insns[] = {
+		BPF_MOV64_IMM(BPF_REG_0, 0),
+		BPF_EXIT_INSN(),
+	};
+	int ret;
+
+	memset(&attr, 0, sizeof(attr));
+	attr.prog_type = prog_type;
+	attr.insns = insns;
+	attr.insns_cnt = ARRAY_SIZE(insns);
+	attr.license = "GPL";
+
+	ret = bpf_load_program_xattr(&attr, NULL, 0);
+	if (ret < 0)
+		return false;
+	close(ret);
+
+	return true;
+}
+
+static bool prog_type_supported[MAX_BPF_PROG_TYPE];
+
+void bpf_probe_prog_types()
+{
+	int i;
+
+	for (i = 0; i < MAX_BPF_PROG_TYPE; i++) {
+		if (i == (int)BPF_PROG_TYPE_UNSPEC)
+			continue;
+		prog_type_supported[i] =
+			__bpf_proge_prog_type((enum bpf_prog_type)i);
+	}
+}
+
+bool bpf_prog_type_supported(enum bpf_prog_type prog_type)
+{
+	return prog_type == BPF_PROG_TYPE_UNSPEC ||
+		    prog_type_supported[(int)prog_type];
+}
+/* }}} */
+
 /* Note we want this to be 64 bit aligned so that the end of our array is
  * actually the end of the structure.
  */
@@ -14545,8 +14591,8 @@ static int do_test(bool unpriv, unsigned int from, unsigned int to)
 	for (i = from; i < to; i++) {
 		struct bpf_test *test = &tests[i];
 
-		if (test->config_disabled) {
-			printf("#%d/u %s SKIP (missing required config)\n",
+		if (!bpf_prog_type_supported(test->prog_type)) {
+			printf("#%d/u %s SKIP (unsupported program type)\n",
 			       i, test->descr);
 			skips++;
 			continue;
@@ -14611,5 +14657,6 @@ int main(int argc, char **argv)
 	}
 
 	bpf_semi_rand_init();
+	bpf_probe_prog_types();
 	return do_test(unpriv, from, to);
 }

Re: [PATCH bpf-next 1/2] selftests/bpf: skip verifier tests that depend on CONFIG_CGROUP_BPF

[Alexei Starovoitov]

On Wed, Dec 12, 2018 at 11:54:20AM -0800, Stanislav Fomichev wrote:
> On 12/12, Stanislav Fomichev wrote:
> > On 12/12, Alexei Starovoitov wrote:
> > > On Wed, Dec 12, 2018 at 10:59:13AM -0800, Stanislav Fomichev wrote:
> > > > On 12/12, Alexei Starovoitov wrote:
> > > > > On Wed, Dec 12, 2018 at 10:27:24AM -0800, Stanislav Fomichev wrote:
> > > > > > 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 <sdf@google.com>
> > > > > > ---
> > > > > >  tools/testing/selftests/bpf/test_verifier.c | 35 +++++++++++++++++++++
> > > > > >  1 file changed, 35 insertions(+)
> > > > > > 
> > > > > > diff --git a/tools/testing/selftests/bpf/test_verifier.c b/tools/testing/selftests/bpf/test_verifier.c
> > > > > > index f5015566ae1b..b5470a399996 100644
> > > > > > --- a/tools/testing/selftests/bpf/test_verifier.c
> > > > > > +++ b/tools/testing/selftests/bpf/test_verifier.c
> > > > > > @@ -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)
> > > 
> > > 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.
> 
> ---
> 
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index aa582cd5bfcf..e55c116ff971 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -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.

Re: [PATCH bpf-next 1/2] selftests/bpf: skip verifier tests that depend on CONFIG_CGROUP_BPF

[Edward Cree]

On 12/12/18 20:13, Alexei Starovoitov wrote:
> 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

Re: [PATCH bpf-next 1/2] selftests/bpf: skip verifier tests that depend on CONFIG_CGROUP_BPF

[Alexei Starovoitov]

On Wed, Dec 12, 2018 at 09:23:30PM +0000, Edward Cree wrote:
> On 12/12/18 20:13, Alexei Starovoitov wrote:
> > 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.

> 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.

Re: [PATCH bpf-next 1/2] selftests/bpf: skip verifier tests that depend on CONFIG_CGROUP_BPF

[Stanislav Fomichev]

On 12/12, Alexei Starovoitov wrote:
> On Wed, Dec 12, 2018 at 09:23:30PM +0000, Edward Cree wrote:
> > On 12/12/18 20:13, Alexei Starovoitov wrote:
> > > 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.
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).

> > 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.
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.

Re: [PATCH bpf-next 1/2] selftests/bpf: skip verifier tests that depend on CONFIG_CGROUP_BPF

[Alexei Starovoitov]

On Wed, Dec 12, 2018 at 02:32:01PM -0800, Stanislav Fomichev wrote:
> 
> 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.

Re: [PATCH bpf-next 1/2] selftests/bpf: skip verifier tests that depend on CONFIG_CGROUP_BPF

[Daniel Borkmann]

On 12/13/2018 07:06 AM, Alexei Starovoitov wrote:
> On Wed, Dec 12, 2018 at 02:32:01PM -0800, Stanislav Fomichev wrote:
>>
>> 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.

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

Re: [PATCH bpf-next 1/2] selftests/bpf: skip verifier tests that depend on CONFIG_CGROUP_BPF

[Quentin Monnet]

2018-12-13 12:52 UTC+0100 ~ Daniel Borkmann <daniel@iogearbox.net>
> On 12/13/2018 07:06 AM, Alexei Starovoitov wrote:
>> On Wed, Dec 12, 2018 at 02:32:01PM -0800, Stanislav Fomichev wrote:
>>>
>>> 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.
> 
> 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

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

Re: [PATCH bpf-next 1/2] selftests/bpf: skip verifier tests that depend on CONFIG_CGROUP_BPF

[Stanislav Fomichev]

On 12/13, Quentin Monnet wrote:
> 2018-12-13 12:52 UTC+0100 ~ Daniel Borkmann <daniel@iogearbox.net>
> > On 12/13/2018 07:06 AM, Alexei Starovoitov wrote:
> >> On Wed, Dec 12, 2018 at 02:32:01PM -0800, Stanislav Fomichev wrote:
> >>>
> >>> 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.
> > 
> > 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'.

> > 
> > 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.
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?

> 
> Quentin

Re: [PATCH bpf-next 1/2] selftests/bpf: skip verifier tests that depend on CONFIG_CGROUP_BPF

[Quentin Monnet]

2018-12-13 08:37 UTC-0800 ~ Stanislav Fomichev <sdf@fomichev.me>
> On 12/13, Quentin Monnet wrote:
>> 2018-12-13 12:52 UTC+0100 ~ Daniel Borkmann <daniel@iogearbox.net>
>>> On 12/13/2018 07:06 AM, Alexei Starovoitov wrote:
>>>> On Wed, Dec 12, 2018 at 02:32:01PM -0800, Stanislav Fomichev wrote:
>>>>>
>>>>> 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.
>>>
>>> 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'.
> 
>>>
>>> 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.
> 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

Re: [PATCH bpf-next 1/2] selftests/bpf: skip verifier tests that depend on CONFIG_CGROUP_BPF

[Stanislav Fomichev]

On 12/13, Quentin Monnet wrote:
> 2018-12-13 08:37 UTC-0800 ~ Stanislav Fomichev <sdf@fomichev.me>
> > On 12/13, Quentin Monnet wrote:
> >> 2018-12-13 12:52 UTC+0100 ~ Daniel Borkmann <daniel@iogearbox.net>
> >>> On 12/13/2018 07:06 AM, Alexei Starovoitov wrote:
> >>>> On Wed, Dec 12, 2018 at 02:32:01PM -0800, Stanislav Fomichev wrote:
> >>>>>
> >>>>> 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.
> >>>
> >>> 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'.
> > 
> >>>
> >>> 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.
> > 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.
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?

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

Re: [PATCH bpf-next 1/2] selftests/bpf: skip verifier tests that depend on CONFIG_CGROUP_BPF

[Quentin Monnet]

2018-12-13 09:10 UTC-0800 ~ Stanislav Fomichev <sdf@fomichev.me>
> On 12/13, Quentin Monnet wrote:
>> 2018-12-13 08:37 UTC-0800 ~ Stanislav Fomichev <sdf@fomichev.me>
>>> On 12/13, Quentin Monnet wrote:
>>>> 2018-12-13 12:52 UTC+0100 ~ Daniel Borkmann <daniel@iogearbox.net>
>>>>> On 12/13/2018 07:06 AM, Alexei Starovoitov wrote:
>>>>>> On Wed, Dec 12, 2018 at 02:32:01PM -0800, Stanislav Fomichev wrote:
>>>>>>>
>>>>>>> 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.
>>>>>
>>>>> 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'.
>>>
>>>>>
>>>>> 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.
>>> 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.
> 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.