* [PATCH bpf-next 0/4] bpf: Support non-linear skbs for BPF_PROG_TEST_RUN
@ 2025-09-04 12:07 Paul Chaignon
2025-09-04 12:09 ` [PATCH bpf-next 1/4] bpf: Refactor cleanup of bpf_prog_test_run_skb Paul Chaignon
` (4 more replies)
0 siblings, 5 replies; 16+ messages in thread
From: Paul Chaignon @ 2025-09-04 12:07 UTC (permalink / raw)
To: bpf; +Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Eduard Zingerman
This patchset adds support for non-linear skbs when running tc programs
with BPF_PROG_TEST_RUN.
We've had multiple bugs in the past few years in Cilium caused by
missing calls to bpf_skb_pull_data(). Daniel suggested this new
BPF_PROG_TEST_RUN flag as a way to uncover these bugs in our BPF tests.
Paul Chaignon (4):
bpf: Refactor cleanup of bpf_prog_test_run_skb
bpf: Craft non-linear skbs in BPF_PROG_TEST_RUN
selftests/bpf: Support non-linear flag in test loader
selftests/bpf: Test direct packet access on non-linear skbs
include/uapi/linux/bpf.h | 2 +
net/bpf/test_run.c | 103 ++++++++++++------
tools/include/uapi/linux/bpf.h | 2 +
.../bpf/progs/verifier_direct_packet_access.c | 48 ++++++++
tools/testing/selftests/bpf/test_loader.c | 9 +-
5 files changed, 129 insertions(+), 35 deletions(-)
--
2.43.0
^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH bpf-next 1/4] bpf: Refactor cleanup of bpf_prog_test_run_skb
2025-09-04 12:07 [PATCH bpf-next 0/4] bpf: Support non-linear skbs for BPF_PROG_TEST_RUN Paul Chaignon
@ 2025-09-04 12:09 ` Paul Chaignon
2025-09-05 12:57 ` kernel test robot
2025-09-04 12:11 ` [PATCH bpf-next 2/4] bpf: Craft non-linear skbs in BPF_PROG_TEST_RUN Paul Chaignon
` (3 subsequent siblings)
4 siblings, 1 reply; 16+ messages in thread
From: Paul Chaignon @ 2025-09-04 12:09 UTC (permalink / raw)
To: bpf; +Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Eduard Zingerman
This bit of refactoring aims to simplify the next patch in this series,
in which freeing 'data' is a bit less straightforward.
Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
---
net/bpf/test_run.c | 21 +++++++++++----------
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/net/bpf/test_run.c b/net/bpf/test_run.c
index 4a862d605386..4e595b7ad94f 100644
--- a/net/bpf/test_run.c
+++ b/net/bpf/test_run.c
@@ -1009,8 +1009,8 @@ int bpf_prog_test_run_skb(struct bpf_prog *prog, const union bpf_attr *kattr,
ctx = bpf_ctx_init(kattr, sizeof(struct __sk_buff));
if (IS_ERR(ctx)) {
- kfree(data);
- return PTR_ERR(ctx);
+ ret = PTR_ERR(ctx);
+ goto out;
}
switch (prog->type) {
@@ -1030,24 +1030,23 @@ int bpf_prog_test_run_skb(struct bpf_prog *prog, const union bpf_attr *kattr,
sk = sk_alloc(net, AF_UNSPEC, GFP_USER, &bpf_dummy_proto, 1);
if (!sk) {
- kfree(data);
- kfree(ctx);
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto out;
}
sock_init_data(NULL, sk);
skb = slab_build_skb(data);
if (!skb) {
- kfree(data);
- kfree(ctx);
- sk_free(sk);
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto out;
}
skb->sk = sk;
skb_reserve(skb, NET_SKB_PAD + NET_IP_ALIGN);
__skb_put(skb, size);
+ data = NULL; /* data released via kfree_skb */
+
if (ctx && ctx->ifindex > 1) {
dev = dev_get_by_index(net, ctx->ifindex);
if (!dev) {
@@ -1139,7 +1138,9 @@ int bpf_prog_test_run_skb(struct bpf_prog *prog, const union bpf_attr *kattr,
if (dev && dev != net->loopback_dev)
dev_put(dev);
kfree_skb(skb);
- sk_free(sk);
+ kfree(data);
+ if (sk)
+ sk_free(sk);
kfree(ctx);
return ret;
}
--
2.43.0
^ permalink raw reply related [flat|nested] 16+ messages in thread
* [PATCH bpf-next 2/4] bpf: Craft non-linear skbs in BPF_PROG_TEST_RUN
2025-09-04 12:07 [PATCH bpf-next 0/4] bpf: Support non-linear skbs for BPF_PROG_TEST_RUN Paul Chaignon
2025-09-04 12:09 ` [PATCH bpf-next 1/4] bpf: Refactor cleanup of bpf_prog_test_run_skb Paul Chaignon
@ 2025-09-04 12:11 ` Paul Chaignon
2025-09-04 15:56 ` Alexei Starovoitov
2025-09-04 12:13 ` [PATCH bpf-next 3/4] selftests/bpf: Support non-linear flag in test loader Paul Chaignon
` (2 subsequent siblings)
4 siblings, 1 reply; 16+ messages in thread
From: Paul Chaignon @ 2025-09-04 12:11 UTC (permalink / raw)
To: bpf; +Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Eduard Zingerman
This patch adds support for crafting non-linear skbs in BPF test runs
for tc programs, via a new flag BPF_F_TEST_SKB_NON_LINEAR. When this
flag is set, only the L2 header is pulled in the linear area.
This is particularly useful to test support for non-linear skbs in large
codebases such as Cilium. We've had multiple bugs in the past few years
where we were missing calls to bpf_skb_pull_data(). This support in
BPF_PROG_TEST_RUN would allow us to automatically cover this case in our
BPF tests.
In addition to the selftests introduced later in the series, this patch
was tested by setting BPF_F_TEST_SKB_NON_LINEAR for all tc selftests
programs and checking test failures were expected.
Suggested-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
---
include/uapi/linux/bpf.h | 2 +
net/bpf/test_run.c | 88 ++++++++++++++++++++++++----------
tools/include/uapi/linux/bpf.h | 2 +
3 files changed, 66 insertions(+), 26 deletions(-)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 233de8677382..d77c8bf4b131 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -1448,6 +1448,8 @@ enum {
#define BPF_F_TEST_XDP_LIVE_FRAMES (1U << 1)
/* If set, apply CHECKSUM_COMPLETE to skb and validate the checksum */
#define BPF_F_TEST_SKB_CHECKSUM_COMPLETE (1U << 2)
+/* If set, skb will be non-linear */
+#define BPF_F_TEST_SKB_NON_LINEAR (1U << 3)
/* type for BPF_ENABLE_STATS */
enum bpf_stats_type {
diff --git a/net/bpf/test_run.c b/net/bpf/test_run.c
index 4e595b7ad94f..645b7b5af08f 100644
--- a/net/bpf/test_run.c
+++ b/net/bpf/test_run.c
@@ -660,20 +660,29 @@ BTF_ID_FLAGS(func, bpf_kfunc_call_memb_release, KF_RELEASE)
BTF_KFUNCS_END(test_sk_check_kfunc_ids)
static void *bpf_test_init(const union bpf_attr *kattr, u32 user_size,
- u32 size, u32 headroom, u32 tailroom)
+ u32 size, u32 headroom, u32 tailroom, bool nonlinear)
{
void __user *data_in = u64_to_user_ptr(kattr->test.data_in);
- void *data;
+ void *data, *dst;
if (user_size < ETH_HLEN || user_size > PAGE_SIZE - headroom - tailroom)
return ERR_PTR(-EINVAL);
- size = SKB_DATA_ALIGN(size);
- data = kzalloc(size + headroom + tailroom, GFP_USER);
+ /* In non-linear case, data_in is copied to the paged data */
+ if (nonlinear) {
+ data = alloc_page(GFP_USER);
+ } else {
+ size = SKB_DATA_ALIGN(size);
+ data = kzalloc(size + headroom + tailroom, GFP_USER);
+ }
if (!data)
return ERR_PTR(-ENOMEM);
- if (copy_from_user(data + headroom, data_in, user_size)) {
+ if (nonlinear)
+ dst = page_address(data);
+ else
+ dst = data + headroom;
+ if (copy_from_user(dst, data_in, user_size)) {
kfree(data);
return ERR_PTR(-EFAULT);
}
@@ -984,7 +993,7 @@ static struct proto bpf_dummy_proto = {
int bpf_prog_test_run_skb(struct bpf_prog *prog, const union bpf_attr *kattr,
union bpf_attr __user *uattr)
{
- bool is_l2 = false, is_direct_pkt_access = false;
+ bool is_l2 = false, is_direct_pkt_access = false, is_nonlinear = false;
struct net *net = current->nsproxy->net_ns;
struct net_device *dev = net->loopback_dev;
u32 size = kattr->test.data_size_in;
@@ -997,21 +1006,11 @@ int bpf_prog_test_run_skb(struct bpf_prog *prog, const union bpf_attr *kattr,
void *data;
int ret;
- if ((kattr->test.flags & ~BPF_F_TEST_SKB_CHECKSUM_COMPLETE) ||
+ if ((kattr->test.flags & ~(BPF_F_TEST_SKB_CHECKSUM_COMPLETE | BPF_F_TEST_SKB_NON_LINEAR)) ||
kattr->test.cpu || kattr->test.batch_size)
return -EINVAL;
- data = bpf_test_init(kattr, kattr->test.data_size_in,
- size, NET_SKB_PAD + NET_IP_ALIGN,
- SKB_DATA_ALIGN(sizeof(struct skb_shared_info)));
- if (IS_ERR(data))
- return PTR_ERR(data);
-
- ctx = bpf_ctx_init(kattr, sizeof(struct __sk_buff));
- if (IS_ERR(ctx)) {
- ret = PTR_ERR(ctx);
- goto out;
- }
+ is_nonlinear = kattr->test.flags & BPF_F_TEST_SKB_NON_LINEAR;
switch (prog->type) {
case BPF_PROG_TYPE_SCHED_CLS:
@@ -1028,6 +1027,22 @@ int bpf_prog_test_run_skb(struct bpf_prog *prog, const union bpf_attr *kattr,
break;
}
+ if (is_nonlinear && !is_l2)
+ return -EINVAL;
+
+ data = bpf_test_init(kattr, kattr->test.data_size_in,
+ size, NET_SKB_PAD + NET_IP_ALIGN,
+ SKB_DATA_ALIGN(sizeof(struct skb_shared_info)),
+ is_nonlinear);
+ if (IS_ERR(data))
+ return PTR_ERR(data);
+
+ ctx = bpf_ctx_init(kattr, sizeof(struct __sk_buff));
+ if (IS_ERR(ctx)) {
+ ret = PTR_ERR(ctx);
+ goto out;
+ }
+
sk = sk_alloc(net, AF_UNSPEC, GFP_USER, &bpf_dummy_proto, 1);
if (!sk) {
ret = -ENOMEM;
@@ -1035,15 +1050,32 @@ int bpf_prog_test_run_skb(struct bpf_prog *prog, const union bpf_attr *kattr,
}
sock_init_data(NULL, sk);
- skb = slab_build_skb(data);
+ if (is_nonlinear)
+ skb = alloc_skb(NET_SKB_PAD + NET_IP_ALIGN + size +
+ SKB_DATA_ALIGN(sizeof(struct skb_shared_info)),
+ GFP_USER);
+ else
+ skb = slab_build_skb(data);
if (!skb) {
ret = -ENOMEM;
goto out;
}
+
skb->sk = sk;
skb_reserve(skb, NET_SKB_PAD + NET_IP_ALIGN);
- __skb_put(skb, size);
+
+ if (is_nonlinear) {
+ skb_fill_page_desc(skb, 0, data, 0, size);
+ skb->truesize += PAGE_SIZE;
+ skb->data_len = size;
+ skb->len = size;
+
+ /* eth_type_trans expects the Ethernet header in the linear area. */
+ __pskb_pull_tail(skb, ETH_HLEN);
+ } else {
+ __skb_put(skb, size);
+ }
data = NULL; /* data released via kfree_skb */
@@ -1126,9 +1158,11 @@ int bpf_prog_test_run_skb(struct bpf_prog *prog, const union bpf_attr *kattr,
convert_skb_to___skb(skb, ctx);
size = skb->len;
- /* bpf program can never convert linear skb to non-linear */
- if (WARN_ON_ONCE(skb_is_nonlinear(skb)))
+ if (skb_is_nonlinear(skb)) {
+ /* bpf program can never convert linear skb to non-linear */
+ WARN_ON_ONCE(!is_nonlinear);
size = skb_headlen(skb);
+ }
ret = bpf_test_finish(kattr, uattr, skb->data, NULL, size, retval,
duration);
if (!ret)
@@ -1138,7 +1172,8 @@ int bpf_prog_test_run_skb(struct bpf_prog *prog, const union bpf_attr *kattr,
if (dev && dev != net->loopback_dev)
dev_put(dev);
kfree_skb(skb);
- kfree(data);
+ if (data)
+ is_nonlinear ? __free_page(data) : kfree(data);
if (sk)
sk_free(sk);
kfree(ctx);
@@ -1264,7 +1299,7 @@ int bpf_prog_test_run_xdp(struct bpf_prog *prog, const union bpf_attr *kattr,
size = max_data_sz;
}
- data = bpf_test_init(kattr, size, max_data_sz, headroom, tailroom);
+ data = bpf_test_init(kattr, size, max_data_sz, headroom, tailroom, false);
if (IS_ERR(data)) {
ret = PTR_ERR(data);
goto free_ctx;
@@ -1387,7 +1422,7 @@ int bpf_prog_test_run_flow_dissector(struct bpf_prog *prog,
if (size < ETH_HLEN)
return -EINVAL;
- data = bpf_test_init(kattr, kattr->test.data_size_in, size, 0, 0);
+ data = bpf_test_init(kattr, kattr->test.data_size_in, size, 0, 0, false);
if (IS_ERR(data))
return PTR_ERR(data);
@@ -1660,7 +1695,8 @@ int bpf_prog_test_run_nf(struct bpf_prog *prog,
data = bpf_test_init(kattr, kattr->test.data_size_in, size,
NET_SKB_PAD + NET_IP_ALIGN,
- SKB_DATA_ALIGN(sizeof(struct skb_shared_info)));
+ SKB_DATA_ALIGN(sizeof(struct skb_shared_info)),
+ false);
if (IS_ERR(data))
return PTR_ERR(data);
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 233de8677382..d77c8bf4b131 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -1448,6 +1448,8 @@ enum {
#define BPF_F_TEST_XDP_LIVE_FRAMES (1U << 1)
/* If set, apply CHECKSUM_COMPLETE to skb and validate the checksum */
#define BPF_F_TEST_SKB_CHECKSUM_COMPLETE (1U << 2)
+/* If set, skb will be non-linear */
+#define BPF_F_TEST_SKB_NON_LINEAR (1U << 3)
/* type for BPF_ENABLE_STATS */
enum bpf_stats_type {
--
2.43.0
^ permalink raw reply related [flat|nested] 16+ messages in thread
* [PATCH bpf-next 3/4] selftests/bpf: Support non-linear flag in test loader
2025-09-04 12:07 [PATCH bpf-next 0/4] bpf: Support non-linear skbs for BPF_PROG_TEST_RUN Paul Chaignon
2025-09-04 12:09 ` [PATCH bpf-next 1/4] bpf: Refactor cleanup of bpf_prog_test_run_skb Paul Chaignon
2025-09-04 12:11 ` [PATCH bpf-next 2/4] bpf: Craft non-linear skbs in BPF_PROG_TEST_RUN Paul Chaignon
@ 2025-09-04 12:13 ` Paul Chaignon
2025-09-04 12:13 ` [PATCH bpf-next 4/4] selftests/bpf: Test direct packet access on non-linear skbs Paul Chaignon
2025-09-04 18:08 ` [syzbot ci] Re: bpf: Support non-linear skbs for BPF_PROG_TEST_RUN syzbot ci
4 siblings, 0 replies; 16+ messages in thread
From: Paul Chaignon @ 2025-09-04 12:13 UTC (permalink / raw)
To: bpf; +Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Eduard Zingerman
Contrary to most flags currently used in selftests, the
BPF_F_TEST_SKB_NON_LINEAR flag is not passed at program loading time,
but when calling BPF_PROG_TEST_RUN. This patch updates the test loader
to support it.
Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
---
tools/testing/selftests/bpf/test_loader.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/bpf/test_loader.c b/tools/testing/selftests/bpf/test_loader.c
index a9388ac88358..4e0a03276f6b 100644
--- a/tools/testing/selftests/bpf/test_loader.c
+++ b/tools/testing/selftests/bpf/test_loader.c
@@ -91,6 +91,7 @@ struct test_spec {
const char *btf_custom_path;
int log_level;
int prog_flags;
+ int run_flags;
int mode_mask;
int arch_mask;
int load_mask;
@@ -554,6 +555,8 @@ static int parse_test_spec(struct test_loader *tester,
update_flags(&spec->prog_flags, BPF_F_XDP_HAS_FRAGS, clear);
} else if (strcmp(val, "BPF_F_TEST_REG_INVARIANTS") == 0) {
update_flags(&spec->prog_flags, BPF_F_TEST_REG_INVARIANTS, clear);
+ } else if (strcmp(val, "BPF_F_TEST_SKB_NON_LINEAR") == 0) {
+ update_flags(&spec->run_flags, BPF_F_TEST_SKB_NON_LINEAR, clear);
} else /* assume numeric value */ {
err = parse_int(val, &flags, "test prog flags");
if (err)
@@ -854,7 +857,7 @@ static bool is_unpriv_capable_map(struct bpf_map *map)
}
}
-static int do_prog_test_run(int fd_prog, int *retval, bool empty_opts)
+static int do_prog_test_run(int fd_prog, int *retval, bool empty_opts, int run_flags)
{
__u8 tmp_out[TEST_DATA_LEN << 2] = {};
__u8 tmp_in[TEST_DATA_LEN] = {};
@@ -864,6 +867,7 @@ static int do_prog_test_run(int fd_prog, int *retval, bool empty_opts)
.data_size_in = sizeof(tmp_in),
.data_out = tmp_out,
.data_size_out = sizeof(tmp_out),
+ .flags = run_flags,
.repeat = 1,
);
@@ -1103,7 +1107,8 @@ void run_subtest(struct test_loader *tester,
}
err = do_prog_test_run(bpf_program__fd(tprog), &retval,
- bpf_program__type(tprog) == BPF_PROG_TYPE_SYSCALL ? true : false);
+ bpf_program__type(tprog) == BPF_PROG_TYPE_SYSCALL ? true : false,
+ spec->run_flags);
if (!err && retval != subspec->retval && subspec->retval != POINTER_VALUE) {
PRINT_FAIL("Unexpected retval: %d != %d\n", retval, subspec->retval);
goto tobj_cleanup;
--
2.43.0
^ permalink raw reply related [flat|nested] 16+ messages in thread
* [PATCH bpf-next 4/4] selftests/bpf: Test direct packet access on non-linear skbs
2025-09-04 12:07 [PATCH bpf-next 0/4] bpf: Support non-linear skbs for BPF_PROG_TEST_RUN Paul Chaignon
` (2 preceding siblings ...)
2025-09-04 12:13 ` [PATCH bpf-next 3/4] selftests/bpf: Support non-linear flag in test loader Paul Chaignon
@ 2025-09-04 12:13 ` Paul Chaignon
2025-09-04 18:08 ` [syzbot ci] Re: bpf: Support non-linear skbs for BPF_PROG_TEST_RUN syzbot ci
4 siblings, 0 replies; 16+ messages in thread
From: Paul Chaignon @ 2025-09-04 12:13 UTC (permalink / raw)
To: bpf; +Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Eduard Zingerman
This patch adds two new selftests in the direct packet access suite, to
cover the non-linear case with BPF_F_TEST_SKB_NON_LINEAR. The first
tests the behavior of the bounds check with a non-linear skb. The second
extends the first with a call to bpf_skb_pull_data() to be able to
access the packet.
Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com>
---
.../bpf/progs/verifier_direct_packet_access.c | 48 +++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/tools/testing/selftests/bpf/progs/verifier_direct_packet_access.c b/tools/testing/selftests/bpf/progs/verifier_direct_packet_access.c
index 28b602ac9cbe..fe06d7323f2f 100644
--- a/tools/testing/selftests/bpf/progs/verifier_direct_packet_access.c
+++ b/tools/testing/selftests/bpf/progs/verifier_direct_packet_access.c
@@ -800,4 +800,52 @@ l0_%=: /* exit(0) */ \
: __clobber_all);
}
+SEC("tc")
+__description("direct packet access: test31 (non-linear, bad access)")
+__success __retval(1)
+__flag(BPF_F_TEST_SKB_NON_LINEAR)
+__naked void access_test31_non_linear_bad_access(void)
+{
+ asm volatile (" \
+ r2 = *(u32*)(r1 + %[__sk_buff_data]); \
+ r3 = *(u32*)(r1 + %[__sk_buff_data_end]); \
+ r0 = r2; \
+ r0 += 22; \
+ if r0 > r3 goto l0_%=; \
+ r0 = *(u8*)(r0 - 1); \
+ exit; \
+l0_%=: r0 = 1; \
+ exit; \
+" :
+ : __imm_const(__sk_buff_data, offsetof(struct __sk_buff, data)),
+ __imm_const(__sk_buff_data_end, offsetof(struct __sk_buff, data_end))
+ : __clobber_all);
+}
+
+SEC("tc")
+__description("direct packet access: test32 (non-linear, good access)")
+__success __retval(0)
+__flag(BPF_F_TEST_SKB_NON_LINEAR)
+__naked void access_test32_non_linear_good_access(void)
+{
+ asm volatile (" \
+ r6 = r1; \
+ r2 = 22; \
+ call %[bpf_skb_pull_data]; \
+ r2 = *(u32*)(r6 + %[__sk_buff_data]); \
+ r3 = *(u32*)(r6 + %[__sk_buff_data_end]); \
+ r0 = r2; \
+ r0 += 22; \
+ if r0 > r3 goto l0_%=; \
+ r0 = *(u8*)(r0 - 1); \
+ exit; \
+l0_%=: r0 = 1; \
+ exit; \
+" :
+ : __imm(bpf_skb_pull_data),
+ __imm_const(__sk_buff_data, offsetof(struct __sk_buff, data)),
+ __imm_const(__sk_buff_data_end, offsetof(struct __sk_buff, data_end))
+ : __clobber_all);
+}
+
char _license[] SEC("license") = "GPL";
--
2.43.0
^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCH bpf-next 2/4] bpf: Craft non-linear skbs in BPF_PROG_TEST_RUN
2025-09-04 12:11 ` [PATCH bpf-next 2/4] bpf: Craft non-linear skbs in BPF_PROG_TEST_RUN Paul Chaignon
@ 2025-09-04 15:56 ` Alexei Starovoitov
2025-09-04 16:02 ` Daniel Borkmann
0 siblings, 1 reply; 16+ messages in thread
From: Alexei Starovoitov @ 2025-09-04 15:56 UTC (permalink / raw)
To: Paul Chaignon
Cc: bpf, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Eduard Zingerman
On Thu, Sep 4, 2025 at 5:11 AM Paul Chaignon <paul.chaignon@gmail.com> wrote:
>
> This patch adds support for crafting non-linear skbs in BPF test runs
> for tc programs, via a new flag BPF_F_TEST_SKB_NON_LINEAR. When this
> flag is set, only the L2 header is pulled in the linear area.
...
> + /* eth_type_trans expects the Ethernet header in the linear area. */
> + __pskb_pull_tail(skb, ETH_HLEN);
Looks useful, but only L2 ? Is it realistic ?
I don't recall any driver that would do L2 only.
Is L2 only enough to cover all corner cases in your progs ?
Should the linear size be a configurable parameter for prog_run() ?
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH bpf-next 2/4] bpf: Craft non-linear skbs in BPF_PROG_TEST_RUN
2025-09-04 15:56 ` Alexei Starovoitov
@ 2025-09-04 16:02 ` Daniel Borkmann
2025-09-04 16:27 ` Amery Hung
0 siblings, 1 reply; 16+ messages in thread
From: Daniel Borkmann @ 2025-09-04 16:02 UTC (permalink / raw)
To: Alexei Starovoitov, Paul Chaignon
Cc: bpf, Alexei Starovoitov, Andrii Nakryiko, Eduard Zingerman
On 9/4/25 5:56 PM, Alexei Starovoitov wrote:
> On Thu, Sep 4, 2025 at 5:11 AM Paul Chaignon <paul.chaignon@gmail.com> wrote:
>>
>> This patch adds support for crafting non-linear skbs in BPF test runs
>> for tc programs, via a new flag BPF_F_TEST_SKB_NON_LINEAR. When this
>> flag is set, only the L2 header is pulled in the linear area.
>
> ...
>
>> + /* eth_type_trans expects the Ethernet header in the linear area. */
>> + __pskb_pull_tail(skb, ETH_HLEN);
>
> Looks useful, but only L2 ? Is it realistic ?
> I don't recall any driver that would do L2 only.
> Is L2 only enough to cover all corner cases in your progs ?
> Should the linear size be a configurable parameter for prog_run() ?
Yeah perhaps we could make this configurable. The ETH_HLEN is a common case
we've seen and also what virtual drivers pull in at min, but with NICs doing
header/data split its probably better to let the user define this as part
of the testing. Then we're more flexible.
Cheers,
Daniel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH bpf-next 2/4] bpf: Craft non-linear skbs in BPF_PROG_TEST_RUN
2025-09-04 16:02 ` Daniel Borkmann
@ 2025-09-04 16:27 ` Amery Hung
2025-09-05 13:23 ` Paul Chaignon
0 siblings, 1 reply; 16+ messages in thread
From: Amery Hung @ 2025-09-04 16:27 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Paul Chaignon
Cc: bpf, Alexei Starovoitov, Andrii Nakryiko, Eduard Zingerman
On 9/4/25 9:02 AM, Daniel Borkmann wrote:
> On 9/4/25 5:56 PM, Alexei Starovoitov wrote:
>> On Thu, Sep 4, 2025 at 5:11 AM Paul Chaignon
>> <paul.chaignon@gmail.com> wrote:
>>>
>>> This patch adds support for crafting non-linear skbs in BPF test runs
>>> for tc programs, via a new flag BPF_F_TEST_SKB_NON_LINEAR. When this
>>> flag is set, only the L2 header is pulled in the linear area.
>>
>> ...
>>
>>> + /* eth_type_trans expects the Ethernet header in the
>>> linear area. */
>>> + __pskb_pull_tail(skb, ETH_HLEN);
>>
>> Looks useful, but only L2 ? Is it realistic ?
>> I don't recall any driver that would do L2 only.
>> Is L2 only enough to cover all corner cases in your progs ?
>> Should the linear size be a configurable parameter for prog_run() ?
>
> Yeah perhaps we could make this configurable. The ETH_HLEN is a common
> case
> we've seen and also what virtual drivers pull in at min, but with NICs
> doing
> header/data split its probably better to let the user define this as part
> of the testing. Then we're more flexible.
>
How about letting users specify the linear size through ctx->data_end? I
am working on a set that introduces a kfunc, bpf_xdp_pull_data(). A part
of is to support non-linear xdp_buff in test_run_xdp, and I am doing it
through ctx->data_end. Is it something reasonable for test_run_skb?
> Cheers,
> Daniel
^ permalink raw reply [flat|nested] 16+ messages in thread
* [syzbot ci] Re: bpf: Support non-linear skbs for BPF_PROG_TEST_RUN
2025-09-04 12:07 [PATCH bpf-next 0/4] bpf: Support non-linear skbs for BPF_PROG_TEST_RUN Paul Chaignon
` (3 preceding siblings ...)
2025-09-04 12:13 ` [PATCH bpf-next 4/4] selftests/bpf: Test direct packet access on non-linear skbs Paul Chaignon
@ 2025-09-04 18:08 ` syzbot ci
4 siblings, 0 replies; 16+ messages in thread
From: syzbot ci @ 2025-09-04 18:08 UTC (permalink / raw)
To: andrii, ast, bpf, daniel, eddyz87, paul.chaignon; +Cc: syzbot, syzkaller-bugs
syzbot ci has tested the following series
[v1] bpf: Support non-linear skbs for BPF_PROG_TEST_RUN
https://lore.kernel.org/all/cover.1756983951.git.paul.chaignon@gmail.com
* [PATCH bpf-next 1/4] bpf: Refactor cleanup of bpf_prog_test_run_skb
* [PATCH bpf-next 2/4] bpf: Craft non-linear skbs in BPF_PROG_TEST_RUN
* [PATCH bpf-next 3/4] selftests/bpf: Support non-linear flag in test loader
* [PATCH bpf-next 4/4] selftests/bpf: Test direct packet access on non-linear skbs
and found the following issue:
kernel BUG in bpf_prog_test_run_skb
Full report is available here:
https://ci.syzbot.org/series/94d30edd-8375-4788-b43c-b4f85290f7e8
***
kernel BUG in bpf_prog_test_run_skb
tree: bpf-next
URL: https://kernel.googlesource.com/pub/scm/linux/kernel/git/bpf/bpf-next.git
base: c9110e6f7237f4a314e2b87b75a8a158b9877a7b
arch: amd64
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
config: https://ci.syzbot.org/builds/f23c9149-2bb8-4751-96fa-a1ef3b28cee2/config
syz repro: https://ci.syzbot.org/findings/4d88c169-3df8-4aac-b20a-ff80d8b2eff5/syz_repro
------------[ cut here ]------------
kernel BUG at arch/x86/mm/physaddr.c:23!
Oops: invalid opcode: 0000 [#1] SMP KASAN PTI
CPU: 1 UID: 0 PID: 6005 Comm: syz.2.19 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
RIP: 0010:__phys_addr+0x17b/0x180 arch/x86/mm/physaddr.c:23
Code: 50 cf fa 8d 48 89 de 4c 89 f2 e8 10 9a 8a 03 e9 4d ff ff ff e8 66 25 4b 00 90 0f 0b e8 5e 25 4b 00 90 0f 0b e8 56 25 4b 00 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3
RSP: 0018:ffffc90002c0fba8 EFLAGS: 00010293
RAX: ffffffff817486fa RBX: 000000007ffffff9 RCX: ffff888107c99cc0
RDX: 0000000000000000 RSI: 000000007ffffff9 RDI: 000000001fffffff
RBP: 00000000fffffff9 R08: ffffffff8fa38037 R09: 1ffffffff1f47006
R10: dffffc0000000000 R11: fffffbfff1f47007 R12: 0000000000000000
R13: 0000000000000000 R14: 000000007ffffff9 R15: dffffc0000000000
FS: 00007fae773f76c0(0000) GS:ffff8881a3c1c000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b31a63fff CR3: 000000001f48c000 CR4: 00000000000006f0
Call Trace:
<TASK>
virt_to_folio include/linux/mm.h:1180 [inline]
kfree+0x77/0x440 mm/slub.c:4871
bpf_prog_test_run_skb+0xceb/0x16e0 net/bpf/test_run.c:1179
bpf_prog_test_run+0x2c7/0x340 kernel/bpf/syscall.c:4590
__sys_bpf+0x581/0x870 kernel/bpf/syscall.c:6047
__do_sys_bpf kernel/bpf/syscall.c:6139 [inline]
__se_sys_bpf kernel/bpf/syscall.c:6137 [inline]
__x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:6137
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fae7658ebe9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fae773f7038 EFLAGS: 00000246 ORIG_RAX: 0000000000000141
RAX: ffffffffffffffda RBX: 00007fae767c5fa0 RCX: 00007fae7658ebe9
RDX: 0000000000000050 RSI: 0000200000000080 RDI: 000000000000000a
RBP: 00007fae76611e19 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fae767c6038 R14: 00007fae767c5fa0 R15: 00007ffe5431da58
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:__phys_addr+0x17b/0x180 arch/x86/mm/physaddr.c:23
Code: 50 cf fa 8d 48 89 de 4c 89 f2 e8 10 9a 8a 03 e9 4d ff ff ff e8 66 25 4b 00 90 0f 0b e8 5e 25 4b 00 90 0f 0b e8 56 25 4b 00 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3
RSP: 0018:ffffc90002c0fba8 EFLAGS: 00010293
RAX: ffffffff817486fa RBX: 000000007ffffff9 RCX: ffff888107c99cc0
RDX: 0000000000000000 RSI: 000000007ffffff9 RDI: 000000001fffffff
RBP: 00000000fffffff9 R08: ffffffff8fa38037 R09: 1ffffffff1f47006
R10: dffffc0000000000 R11: fffffbfff1f47007 R12: 0000000000000000
R13: 0000000000000000 R14: 000000007ffffff9 R15: dffffc0000000000
FS: 00007fae773f76c0(0000) GS:ffff8881a3c1c000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b31a63fff CR3: 000000001f48c000 CR4: 00000000000006f0
***
If these findings have caused you to resend the series or submit a
separate fix, please add the following tag to your commit message:
Tested-by: syzbot@syzkaller.appspotmail.com
---
This report is generated by a bot. It may contain errors.
syzbot ci engineers can be reached at syzkaller@googlegroups.com.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH bpf-next 1/4] bpf: Refactor cleanup of bpf_prog_test_run_skb
2025-09-04 12:09 ` [PATCH bpf-next 1/4] bpf: Refactor cleanup of bpf_prog_test_run_skb Paul Chaignon
@ 2025-09-05 12:57 ` kernel test robot
0 siblings, 0 replies; 16+ messages in thread
From: kernel test robot @ 2025-09-05 12:57 UTC (permalink / raw)
To: Paul Chaignon, bpf
Cc: llvm, oe-kbuild-all, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Eduard Zingerman
Hi Paul,
kernel test robot noticed the following build warnings:
[auto build test WARNING on bpf-next/master]
url: https://github.com/intel-lab-lkp/linux/commits/Paul-Chaignon/bpf-Refactor-cleanup-of-bpf_prog_test_run_skb/20250904-201515
base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
patch link: https://lore.kernel.org/r/6fda7c7fd57e6134ff70d12b622c9c7c3cf0b226.1756983952.git.paul.chaignon%40gmail.com
patch subject: [PATCH bpf-next 1/4] bpf: Refactor cleanup of bpf_prog_test_run_skb
config: i386-buildonly-randconfig-006-20250905 (https://download.01.org/0day-ci/archive/20250905/202509052000.sL96WwEb-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250905/202509052000.sL96WwEb-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202509052000.sL96WwEb-lkp@intel.com/
All warnings (new ones prefixed by >>):
>> net/bpf/test_run.c:1011:6: warning: variable 'sk' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
1011 | if (IS_ERR(ctx)) {
| ^~~~~~~~~~~
net/bpf/test_run.c:1142:6: note: uninitialized use occurs here
1142 | if (sk)
| ^~
net/bpf/test_run.c:1011:2: note: remove the 'if' if its condition is always false
1011 | if (IS_ERR(ctx)) {
| ^~~~~~~~~~~~~~~~~~
1012 | ret = PTR_ERR(ctx);
| ~~~~~~~~~~~~~~~~~~~
1013 | goto out;
| ~~~~~~~~~
1014 | }
| ~
net/bpf/test_run.c:996:17: note: initialize the variable 'sk' to silence this warning
996 | struct sock *sk;
| ^
| = NULL
>> net/bpf/test_run.c:1032:6: warning: variable 'skb' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
1032 | if (!sk) {
| ^~~
net/bpf/test_run.c:1140:12: note: uninitialized use occurs here
1140 | kfree_skb(skb);
| ^~~
net/bpf/test_run.c:1032:2: note: remove the 'if' if its condition is always false
1032 | if (!sk) {
| ^~~~~~~~~~
1033 | ret = -ENOMEM;
| ~~~~~~~~~~~~~~
1034 | goto out;
| ~~~~~~~~~
1035 | }
| ~
net/bpf/test_run.c:1011:6: warning: variable 'skb' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
1011 | if (IS_ERR(ctx)) {
| ^~~~~~~~~~~
net/bpf/test_run.c:1140:12: note: uninitialized use occurs here
1140 | kfree_skb(skb);
| ^~~
net/bpf/test_run.c:1011:2: note: remove the 'if' if its condition is always false
1011 | if (IS_ERR(ctx)) {
| ^~~~~~~~~~~~~~~~~~
1012 | ret = PTR_ERR(ctx);
| ~~~~~~~~~~~~~~~~~~~
1013 | goto out;
| ~~~~~~~~~
1014 | }
| ~
net/bpf/test_run.c:995:21: note: initialize the variable 'skb' to silence this warning
995 | struct sk_buff *skb;
| ^
| = NULL
3 warnings generated.
vim +1011 net/bpf/test_run.c
435b08ec0094ac Daniel Borkmann 2021-09-27 983
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 984 int bpf_prog_test_run_skb(struct bpf_prog *prog, const union bpf_attr *kattr,
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 985 union bpf_attr __user *uattr)
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 986 {
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 987 bool is_l2 = false, is_direct_pkt_access = false;
21594c44083c37 Dmitry Yakunin 2020-08-03 988 struct net *net = current->nsproxy->net_ns;
21594c44083c37 Dmitry Yakunin 2020-08-03 989 struct net_device *dev = net->loopback_dev;
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 990 u32 size = kattr->test.data_size_in;
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 991 u32 repeat = kattr->test.repeat;
b0b9395d865e30 Stanislav Fomichev 2019-04-09 992 struct __sk_buff *ctx = NULL;
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 993 u32 retval, duration;
6e6fddc7832353 Daniel Borkmann 2018-07-11 994 int hh_len = ETH_HLEN;
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 995 struct sk_buff *skb;
2cb494a36c9827 Song Liu 2018-10-19 996 struct sock *sk;
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 997 void *data;
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 998 int ret;
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 999
a3cfe84cca28f2 Vadim Fedorenko 2024-06-06 1000 if ((kattr->test.flags & ~BPF_F_TEST_SKB_CHECKSUM_COMPLETE) ||
a3cfe84cca28f2 Vadim Fedorenko 2024-06-06 1001 kattr->test.cpu || kattr->test.batch_size)
1b4d60ec162f82 Song Liu 2020-09-25 1002 return -EINVAL;
1b4d60ec162f82 Song Liu 2020-09-25 1003
be3d72a2896cb2 Lorenzo Bianconi 2022-01-21 1004 data = bpf_test_init(kattr, kattr->test.data_size_in,
be3d72a2896cb2 Lorenzo Bianconi 2022-01-21 1005 size, NET_SKB_PAD + NET_IP_ALIGN,
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 1006 SKB_DATA_ALIGN(sizeof(struct skb_shared_info)));
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 1007 if (IS_ERR(data))
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 1008 return PTR_ERR(data);
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 1009
b0b9395d865e30 Stanislav Fomichev 2019-04-09 1010 ctx = bpf_ctx_init(kattr, sizeof(struct __sk_buff));
b0b9395d865e30 Stanislav Fomichev 2019-04-09 @1011 if (IS_ERR(ctx)) {
ed22fb43432aaa Paul Chaignon 2025-09-04 1012 ret = PTR_ERR(ctx);
ed22fb43432aaa Paul Chaignon 2025-09-04 1013 goto out;
b0b9395d865e30 Stanislav Fomichev 2019-04-09 1014 }
b0b9395d865e30 Stanislav Fomichev 2019-04-09 1015
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 1016 switch (prog->type) {
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 1017 case BPF_PROG_TYPE_SCHED_CLS:
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 1018 case BPF_PROG_TYPE_SCHED_ACT:
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 1019 is_l2 = true;
df561f6688fef7 Gustavo A. R. Silva 2020-08-23 1020 fallthrough;
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 1021 case BPF_PROG_TYPE_LWT_IN:
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 1022 case BPF_PROG_TYPE_LWT_OUT:
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 1023 case BPF_PROG_TYPE_LWT_XMIT:
ed3e469d021cba Mahe Tardy 2024-11-25 1024 case BPF_PROG_TYPE_CGROUP_SKB:
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 1025 is_direct_pkt_access = true;
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 1026 break;
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 1027 default:
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 1028 break;
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 1029 }
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 1030
435b08ec0094ac Daniel Borkmann 2021-09-27 1031 sk = sk_alloc(net, AF_UNSPEC, GFP_USER, &bpf_dummy_proto, 1);
2cb494a36c9827 Song Liu 2018-10-19 @1032 if (!sk) {
ed22fb43432aaa Paul Chaignon 2025-09-04 1033 ret = -ENOMEM;
ed22fb43432aaa Paul Chaignon 2025-09-04 1034 goto out;
2cb494a36c9827 Song Liu 2018-10-19 1035 }
2cb494a36c9827 Song Liu 2018-10-19 1036 sock_init_data(NULL, sk);
2cb494a36c9827 Song Liu 2018-10-19 1037
ce098da1497c6d Kees Cook 2022-12-07 1038 skb = slab_build_skb(data);
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 1039 if (!skb) {
ed22fb43432aaa Paul Chaignon 2025-09-04 1040 ret = -ENOMEM;
ed22fb43432aaa Paul Chaignon 2025-09-04 1041 goto out;
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 1042 }
2cb494a36c9827 Song Liu 2018-10-19 1043 skb->sk = sk;
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 1044
586f8525979ad9 David Miller 2017-05-02 1045 skb_reserve(skb, NET_SKB_PAD + NET_IP_ALIGN);
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 1046 __skb_put(skb, size);
a3cfe84cca28f2 Vadim Fedorenko 2024-06-06 1047
ed22fb43432aaa Paul Chaignon 2025-09-04 1048 data = NULL; /* data released via kfree_skb */
ed22fb43432aaa Paul Chaignon 2025-09-04 1049
21594c44083c37 Dmitry Yakunin 2020-08-03 1050 if (ctx && ctx->ifindex > 1) {
21594c44083c37 Dmitry Yakunin 2020-08-03 1051 dev = dev_get_by_index(net, ctx->ifindex);
21594c44083c37 Dmitry Yakunin 2020-08-03 1052 if (!dev) {
21594c44083c37 Dmitry Yakunin 2020-08-03 1053 ret = -ENODEV;
21594c44083c37 Dmitry Yakunin 2020-08-03 1054 goto out;
21594c44083c37 Dmitry Yakunin 2020-08-03 1055 }
21594c44083c37 Dmitry Yakunin 2020-08-03 1056 }
21594c44083c37 Dmitry Yakunin 2020-08-03 1057 skb->protocol = eth_type_trans(skb, dev);
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 1058 skb_reset_network_header(skb);
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 1059
fa5cb548ced61b Dmitry Yakunin 2020-08-03 1060 switch (skb->protocol) {
fa5cb548ced61b Dmitry Yakunin 2020-08-03 1061 case htons(ETH_P_IP):
fa5cb548ced61b Dmitry Yakunin 2020-08-03 1062 sk->sk_family = AF_INET;
fa5cb548ced61b Dmitry Yakunin 2020-08-03 1063 if (sizeof(struct iphdr) <= skb_headlen(skb)) {
fa5cb548ced61b Dmitry Yakunin 2020-08-03 1064 sk->sk_rcv_saddr = ip_hdr(skb)->saddr;
fa5cb548ced61b Dmitry Yakunin 2020-08-03 1065 sk->sk_daddr = ip_hdr(skb)->daddr;
fa5cb548ced61b Dmitry Yakunin 2020-08-03 1066 }
fa5cb548ced61b Dmitry Yakunin 2020-08-03 1067 break;
fa5cb548ced61b Dmitry Yakunin 2020-08-03 1068 #if IS_ENABLED(CONFIG_IPV6)
fa5cb548ced61b Dmitry Yakunin 2020-08-03 1069 case htons(ETH_P_IPV6):
fa5cb548ced61b Dmitry Yakunin 2020-08-03 1070 sk->sk_family = AF_INET6;
fa5cb548ced61b Dmitry Yakunin 2020-08-03 1071 if (sizeof(struct ipv6hdr) <= skb_headlen(skb)) {
fa5cb548ced61b Dmitry Yakunin 2020-08-03 1072 sk->sk_v6_rcv_saddr = ipv6_hdr(skb)->saddr;
fa5cb548ced61b Dmitry Yakunin 2020-08-03 1073 sk->sk_v6_daddr = ipv6_hdr(skb)->daddr;
fa5cb548ced61b Dmitry Yakunin 2020-08-03 1074 }
fa5cb548ced61b Dmitry Yakunin 2020-08-03 1075 break;
fa5cb548ced61b Dmitry Yakunin 2020-08-03 1076 #endif
fa5cb548ced61b Dmitry Yakunin 2020-08-03 1077 default:
fa5cb548ced61b Dmitry Yakunin 2020-08-03 1078 break;
fa5cb548ced61b Dmitry Yakunin 2020-08-03 1079 }
fa5cb548ced61b Dmitry Yakunin 2020-08-03 1080
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 1081 if (is_l2)
6e6fddc7832353 Daniel Borkmann 2018-07-11 1082 __skb_push(skb, hh_len);
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 1083 if (is_direct_pkt_access)
6aaae2b6c4330a Daniel Borkmann 2017-09-25 1084 bpf_compute_data_pointers(skb);
a3cfe84cca28f2 Vadim Fedorenko 2024-06-06 1085
b0b9395d865e30 Stanislav Fomichev 2019-04-09 1086 ret = convert___skb_to_skb(skb, ctx);
b0b9395d865e30 Stanislav Fomichev 2019-04-09 1087 if (ret)
b0b9395d865e30 Stanislav Fomichev 2019-04-09 1088 goto out;
a3cfe84cca28f2 Vadim Fedorenko 2024-06-06 1089
a3cfe84cca28f2 Vadim Fedorenko 2024-06-06 1090 if (kattr->test.flags & BPF_F_TEST_SKB_CHECKSUM_COMPLETE) {
a3cfe84cca28f2 Vadim Fedorenko 2024-06-06 1091 const int off = skb_network_offset(skb);
a3cfe84cca28f2 Vadim Fedorenko 2024-06-06 1092 int len = skb->len - off;
a3cfe84cca28f2 Vadim Fedorenko 2024-06-06 1093
a3cfe84cca28f2 Vadim Fedorenko 2024-06-06 1094 skb->csum = skb_checksum(skb, off, len, 0);
a3cfe84cca28f2 Vadim Fedorenko 2024-06-06 1095 skb->ip_summed = CHECKSUM_COMPLETE;
a3cfe84cca28f2 Vadim Fedorenko 2024-06-06 1096 }
a3cfe84cca28f2 Vadim Fedorenko 2024-06-06 1097
f23c4b3924d2e9 Björn Töpel 2019-12-13 1098 ret = bpf_test_run(prog, skb, repeat, &retval, &duration, false);
b0b9395d865e30 Stanislav Fomichev 2019-04-09 1099 if (ret)
b0b9395d865e30 Stanislav Fomichev 2019-04-09 1100 goto out;
6e6fddc7832353 Daniel Borkmann 2018-07-11 1101 if (!is_l2) {
6e6fddc7832353 Daniel Borkmann 2018-07-11 1102 if (skb_headroom(skb) < hh_len) {
6e6fddc7832353 Daniel Borkmann 2018-07-11 1103 int nhead = HH_DATA_ALIGN(hh_len - skb_headroom(skb));
6e6fddc7832353 Daniel Borkmann 2018-07-11 1104
6e6fddc7832353 Daniel Borkmann 2018-07-11 1105 if (pskb_expand_head(skb, nhead, 0, GFP_USER)) {
b0b9395d865e30 Stanislav Fomichev 2019-04-09 1106 ret = -ENOMEM;
b0b9395d865e30 Stanislav Fomichev 2019-04-09 1107 goto out;
6e6fddc7832353 Daniel Borkmann 2018-07-11 1108 }
6e6fddc7832353 Daniel Borkmann 2018-07-11 1109 }
6e6fddc7832353 Daniel Borkmann 2018-07-11 1110 memset(__skb_push(skb, hh_len), 0, hh_len);
6e6fddc7832353 Daniel Borkmann 2018-07-11 1111 }
a3cfe84cca28f2 Vadim Fedorenko 2024-06-06 1112
a3cfe84cca28f2 Vadim Fedorenko 2024-06-06 1113 if (kattr->test.flags & BPF_F_TEST_SKB_CHECKSUM_COMPLETE) {
a3cfe84cca28f2 Vadim Fedorenko 2024-06-06 1114 const int off = skb_network_offset(skb);
a3cfe84cca28f2 Vadim Fedorenko 2024-06-06 1115 int len = skb->len - off;
a3cfe84cca28f2 Vadim Fedorenko 2024-06-06 1116 __wsum csum;
a3cfe84cca28f2 Vadim Fedorenko 2024-06-06 1117
a3cfe84cca28f2 Vadim Fedorenko 2024-06-06 1118 csum = skb_checksum(skb, off, len, 0);
a3cfe84cca28f2 Vadim Fedorenko 2024-06-06 1119
a3cfe84cca28f2 Vadim Fedorenko 2024-06-06 1120 if (csum_fold(skb->csum) != csum_fold(csum)) {
a3cfe84cca28f2 Vadim Fedorenko 2024-06-06 1121 ret = -EBADMSG;
a3cfe84cca28f2 Vadim Fedorenko 2024-06-06 1122 goto out;
a3cfe84cca28f2 Vadim Fedorenko 2024-06-06 1123 }
a3cfe84cca28f2 Vadim Fedorenko 2024-06-06 1124 }
a3cfe84cca28f2 Vadim Fedorenko 2024-06-06 1125
b0b9395d865e30 Stanislav Fomichev 2019-04-09 1126 convert_skb_to___skb(skb, ctx);
6e6fddc7832353 Daniel Borkmann 2018-07-11 1127
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 1128 size = skb->len;
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 1129 /* bpf program can never convert linear skb to non-linear */
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 1130 if (WARN_ON_ONCE(skb_is_nonlinear(skb)))
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 1131 size = skb_headlen(skb);
7855e0db150ad8 Lorenzo Bianconi 2022-01-21 1132 ret = bpf_test_finish(kattr, uattr, skb->data, NULL, size, retval,
7855e0db150ad8 Lorenzo Bianconi 2022-01-21 1133 duration);
b0b9395d865e30 Stanislav Fomichev 2019-04-09 1134 if (!ret)
b0b9395d865e30 Stanislav Fomichev 2019-04-09 1135 ret = bpf_ctx_finish(kattr, uattr, ctx,
b0b9395d865e30 Stanislav Fomichev 2019-04-09 1136 sizeof(struct __sk_buff));
b0b9395d865e30 Stanislav Fomichev 2019-04-09 1137 out:
21594c44083c37 Dmitry Yakunin 2020-08-03 1138 if (dev && dev != net->loopback_dev)
21594c44083c37 Dmitry Yakunin 2020-08-03 1139 dev_put(dev);
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 1140 kfree_skb(skb);
ed22fb43432aaa Paul Chaignon 2025-09-04 1141 kfree(data);
ed22fb43432aaa Paul Chaignon 2025-09-04 1142 if (sk)
435b08ec0094ac Daniel Borkmann 2021-09-27 1143 sk_free(sk);
b0b9395d865e30 Stanislav Fomichev 2019-04-09 1144 kfree(ctx);
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 1145 return ret;
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 1146 }
1cf1cae963c2e6 Alexei Starovoitov 2017-03-30 1147
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH bpf-next 2/4] bpf: Craft non-linear skbs in BPF_PROG_TEST_RUN
2025-09-04 16:27 ` Amery Hung
@ 2025-09-05 13:23 ` Paul Chaignon
2025-09-05 16:34 ` Amery Hung
0 siblings, 1 reply; 16+ messages in thread
From: Paul Chaignon @ 2025-09-05 13:23 UTC (permalink / raw)
To: Amery Hung
Cc: Daniel Borkmann, Alexei Starovoitov, bpf, Alexei Starovoitov,
Andrii Nakryiko, Eduard Zingerman
On Thu, Sep 04, 2025 at 09:27:58AM -0700, Amery Hung wrote:
>
>
> On 9/4/25 9:02 AM, Daniel Borkmann wrote:
> > On 9/4/25 5:56 PM, Alexei Starovoitov wrote:
> > > On Thu, Sep 4, 2025 at 5:11 AM Paul Chaignon
> > > <paul.chaignon@gmail.com> wrote:
> > > >
> > > > This patch adds support for crafting non-linear skbs in BPF test runs
> > > > for tc programs, via a new flag BPF_F_TEST_SKB_NON_LINEAR. When this
> > > > flag is set, only the L2 header is pulled in the linear area.
> > >
> > > ...
> > >
> > > > + /* eth_type_trans expects the Ethernet header in
> > > > the linear area. */
> > > > + __pskb_pull_tail(skb, ETH_HLEN);
> > >
> > > Looks useful, but only L2 ? Is it realistic ?
> > > I don't recall any driver that would do L2 only.
> > > Is L2 only enough to cover all corner cases in your progs ?
> > > Should the linear size be a configurable parameter for prog_run() ?
I think it's enough for Cilium. It's a bit of a worst case for us AFAIU.
In any case, I'm definitely not against making it configurable.
> >
> > Yeah perhaps we could make this configurable. The ETH_HLEN is a common
> > case
> > we've seen and also what virtual drivers pull in at min, but with NICs
> > doing
> > header/data split its probably better to let the user define this as part
> > of the testing. Then we're more flexible.
> >
>
> How about letting users specify the linear size through ctx->data_end? I am
> working on a set that introduces a kfunc, bpf_xdp_pull_data(). A part of is
> to support non-linear xdp_buff in test_run_xdp, and I am doing it through
> ctx->data_end. Is it something reasonable for test_run_skb?
Oh, nice! That was next on my list :)
Why use data_end though? I guess it'd work for skb, but can't we just
add a new field to the anonymous struct for BPF_PROG_TEST_RUN?
>
> > Cheers,
> > Daniel
>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH bpf-next 2/4] bpf: Craft non-linear skbs in BPF_PROG_TEST_RUN
2025-09-05 13:23 ` Paul Chaignon
@ 2025-09-05 16:34 ` Amery Hung
2025-09-08 17:41 ` Paul Chaignon
0 siblings, 1 reply; 16+ messages in thread
From: Amery Hung @ 2025-09-05 16:34 UTC (permalink / raw)
To: Paul Chaignon
Cc: Daniel Borkmann, Alexei Starovoitov, bpf, Alexei Starovoitov,
Andrii Nakryiko, Eduard Zingerman
On Fri, Sep 5, 2025 at 6:24 AM Paul Chaignon <paul.chaignon@gmail.com> wrote:
>
> On Thu, Sep 04, 2025 at 09:27:58AM -0700, Amery Hung wrote:
> >
> >
> > On 9/4/25 9:02 AM, Daniel Borkmann wrote:
> > > On 9/4/25 5:56 PM, Alexei Starovoitov wrote:
> > > > On Thu, Sep 4, 2025 at 5:11 AM Paul Chaignon
> > > > <paul.chaignon@gmail.com> wrote:
> > > > >
> > > > > This patch adds support for crafting non-linear skbs in BPF test runs
> > > > > for tc programs, via a new flag BPF_F_TEST_SKB_NON_LINEAR. When this
> > > > > flag is set, only the L2 header is pulled in the linear area.
> > > >
> > > > ...
> > > >
> > > > > + /* eth_type_trans expects the Ethernet header in
> > > > > the linear area. */
> > > > > + __pskb_pull_tail(skb, ETH_HLEN);
> > > >
> > > > Looks useful, but only L2 ? Is it realistic ?
> > > > I don't recall any driver that would do L2 only.
> > > > Is L2 only enough to cover all corner cases in your progs ?
> > > > Should the linear size be a configurable parameter for prog_run() ?
>
> I think it's enough for Cilium. It's a bit of a worst case for us AFAIU.
> In any case, I'm definitely not against making it configurable.
>
> > >
> > > Yeah perhaps we could make this configurable. The ETH_HLEN is a common
> > > case
> > > we've seen and also what virtual drivers pull in at min, but with NICs
> > > doing
> > > header/data split its probably better to let the user define this as part
> > > of the testing. Then we're more flexible.
> > >
> >
> > How about letting users specify the linear size through ctx->data_end? I am
> > working on a set that introduces a kfunc, bpf_xdp_pull_data(). A part of is
> > to support non-linear xdp_buff in test_run_xdp, and I am doing it through
> > ctx->data_end. Is it something reasonable for test_run_skb?
>
> Oh, nice! That was next on my list :)
>
> Why use data_end though? I guess it'd work for skb, but can't we just
> add a new field to the anonymous struct for BPF_PROG_TEST_RUN?
>
I choose to use ctx_in because it doesn't change the interface and
feels natural. kattr->test.ctx_in is already copied from users and
shows users' expectation about the input ctx. I think we should honor
that (as long as the value makes sense). WDYT?
Thanks for working on this. It would be great if there is some
consistency between test_run_skb and test_run_xdp.
> >
> > > Cheers,
> > > Daniel
> >
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH bpf-next 2/4] bpf: Craft non-linear skbs in BPF_PROG_TEST_RUN
2025-09-05 16:34 ` Amery Hung
@ 2025-09-08 17:41 ` Paul Chaignon
2025-09-08 19:09 ` Martin KaFai Lau
2025-09-08 19:10 ` Amery Hung
0 siblings, 2 replies; 16+ messages in thread
From: Paul Chaignon @ 2025-09-08 17:41 UTC (permalink / raw)
To: Amery Hung
Cc: Daniel Borkmann, Alexei Starovoitov, bpf, Alexei Starovoitov,
Andrii Nakryiko, Eduard Zingerman
On Fri, Sep 05, 2025 at 09:34:54AM -0700, Amery Hung wrote:
> On Fri, Sep 5, 2025 at 6:24 AM Paul Chaignon <paul.chaignon@gmail.com> wrote:
> >
> > On Thu, Sep 04, 2025 at 09:27:58AM -0700, Amery Hung wrote:
[...]
> > > How about letting users specify the linear size through ctx->data_end? I am
> > > working on a set that introduces a kfunc, bpf_xdp_pull_data(). A part of is
> > > to support non-linear xdp_buff in test_run_xdp, and I am doing it through
> > > ctx->data_end. Is it something reasonable for test_run_skb?
> >
> > Oh, nice! That was next on my list :)
> >
> > Why use data_end though? I guess it'd work for skb, but can't we just
> > add a new field to the anonymous struct for BPF_PROG_TEST_RUN?
> >
>
> I choose to use ctx_in because it doesn't change the interface and
> feels natural. kattr->test.ctx_in is already copied from users and
> shows users' expectation about the input ctx. I think we should honor
> that (as long as the value makes sense). WDYT?
Ok, I think I see your point of view. To me, test.ctx_in *is* the
context and not metadata about it. I'm worried it would be weird to
users if we overload that field. I'm not against using that though if
it's the consensus.
>
> Thanks for working on this. It would be great if there is some
> consistency between test_run_skb and test_run_xdp.
Definitely agree! Do you have a prototype anywhere I could check? If
not, you can always flag any inconsistency when I send the v2.
[...]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH bpf-next 2/4] bpf: Craft non-linear skbs in BPF_PROG_TEST_RUN
2025-09-08 17:41 ` Paul Chaignon
@ 2025-09-08 19:09 ` Martin KaFai Lau
2025-09-08 19:10 ` Amery Hung
1 sibling, 0 replies; 16+ messages in thread
From: Martin KaFai Lau @ 2025-09-08 19:09 UTC (permalink / raw)
To: Paul Chaignon, Amery Hung
Cc: Daniel Borkmann, Alexei Starovoitov, bpf, Alexei Starovoitov,
Andrii Nakryiko, Eduard Zingerman
On 9/8/25 10:41 AM, Paul Chaignon wrote:
>>>> How about letting users specify the linear size through ctx->data_end? I am
>>>> working on a set that introduces a kfunc, bpf_xdp_pull_data(). A part of is
>>>> to support non-linear xdp_buff in test_run_xdp, and I am doing it through
>>>> ctx->data_end. Is it something reasonable for test_run_skb?
>>> Oh, nice! That was next on my list 🙂
>>>
>>> Why use data_end though? I guess it'd work for skb, but can't we just
>>> add a new field to the anonymous struct for BPF_PROG_TEST_RUN?
>>>
>> I choose to use ctx_in because it doesn't change the interface and
>> feels natural. kattr->test.ctx_in is already copied from users and
>> shows users' expectation about the input ctx. I think we should honor
>> that (as long as the value makes sense). WDYT?
> Ok, I think I see your point of view. To me, test.ctx_in*is* the
> context and not metadata about it. I'm worried it would be weird to
> users if we overload that field. I'm not against using that though if
> it's the consensus.
On the xdp side, the test_run_xdp has been using the ctx_in->data[_meta] to
allow the user to specify the meta data (since commit 47316f4a3053). Using
ctx_in->data_end [1] to specify the end of the linear part seems to be a
logical addition in xdp.
>
>> Thanks for working on this. It would be great if there is some
>> consistency between test_run_skb and test_run_xdp.
> Definitely agree! Do you have a prototype anywhere I could check? If
> not, you can always flag any inconsistency when I send the v2.
[1]: https://lore.kernel.org/bpf/20250905173352.3759457-6-ameryhung@gmail.com/
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH bpf-next 2/4] bpf: Craft non-linear skbs in BPF_PROG_TEST_RUN
2025-09-08 17:41 ` Paul Chaignon
2025-09-08 19:09 ` Martin KaFai Lau
@ 2025-09-08 19:10 ` Amery Hung
2025-09-08 19:16 ` Paul Chaignon
1 sibling, 1 reply; 16+ messages in thread
From: Amery Hung @ 2025-09-08 19:10 UTC (permalink / raw)
To: Paul Chaignon
Cc: Daniel Borkmann, Alexei Starovoitov, bpf, Alexei Starovoitov,
Andrii Nakryiko, Eduard Zingerman
On Mon, Sep 8, 2025 at 10:41 AM Paul Chaignon <paul.chaignon@gmail.com> wrote:
>
> On Fri, Sep 05, 2025 at 09:34:54AM -0700, Amery Hung wrote:
> > On Fri, Sep 5, 2025 at 6:24 AM Paul Chaignon <paul.chaignon@gmail.com> wrote:
> > >
> > > On Thu, Sep 04, 2025 at 09:27:58AM -0700, Amery Hung wrote:
>
> [...]
>
> > > > How about letting users specify the linear size through ctx->data_end? I am
> > > > working on a set that introduces a kfunc, bpf_xdp_pull_data(). A part of is
> > > > to support non-linear xdp_buff in test_run_xdp, and I am doing it through
> > > > ctx->data_end. Is it something reasonable for test_run_skb?
> > >
> > > Oh, nice! That was next on my list :)
> > >
> > > Why use data_end though? I guess it'd work for skb, but can't we just
> > > add a new field to the anonymous struct for BPF_PROG_TEST_RUN?
> > >
> >
> > I choose to use ctx_in because it doesn't change the interface and
> > feels natural. kattr->test.ctx_in is already copied from users and
> > shows users' expectation about the input ctx. I think we should honor
> > that (as long as the value makes sense). WDYT?
>
> Ok, I think I see your point of view. To me, test.ctx_in *is* the
> context and not metadata about it. I'm worried it would be weird to
> users if we overload that field. I'm not against using that though if
> it's the consensus.
Just about to say the same thing Martin mentioned.
bpf_prog_test_run_xdp() is already using test.ctx_in since
47316f4a3053 ("bpf: Support input xdp_md context in
BPF_PROG_TEST_RUN"). It allows users to supply metadata via
test.data_in. ctx_in->data_meta must be zero and the first
ctx_in->data - ctx_in->data_meta bytes in data_in will be copied into
metadata. So continuing using ctx_in for specifying the linear data
size is a logical next step.
>
> >
> > Thanks for working on this. It would be great if there is some
> > consistency between test_run_skb and test_run_xdp.
>
> Definitely agree! Do you have a prototype anywhere I could check? If
> not, you can always flag any inconsistency when I send the v2.
>
Here is the set I am working on
https://lore.kernel.org/bpf/20250905173352.3759457-1-ameryhung@gmail.com/
Patch 5 allows using ctx_in->data_end to specify the linear xdp_buff
size (i.e., ctx_in->data_end - ctx_in->data). Patch 6 uses it to test
a new kfunc, bpf_xdp_pull_data().
> [...]
>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH bpf-next 2/4] bpf: Craft non-linear skbs in BPF_PROG_TEST_RUN
2025-09-08 19:10 ` Amery Hung
@ 2025-09-08 19:16 ` Paul Chaignon
0 siblings, 0 replies; 16+ messages in thread
From: Paul Chaignon @ 2025-09-08 19:16 UTC (permalink / raw)
To: Amery Hung
Cc: Daniel Borkmann, Alexei Starovoitov, bpf, Alexei Starovoitov,
Andrii Nakryiko, Eduard Zingerman
On Mon, Sep 08, 2025 at 12:10:42PM -0700, Amery Hung wrote:
> On Mon, Sep 8, 2025 at 10:41 AM Paul Chaignon <paul.chaignon@gmail.com> wrote:
> >
> > On Fri, Sep 05, 2025 at 09:34:54AM -0700, Amery Hung wrote:
> > > On Fri, Sep 5, 2025 at 6:24 AM Paul Chaignon <paul.chaignon@gmail.com> wrote:
> > > >
> > > > On Thu, Sep 04, 2025 at 09:27:58AM -0700, Amery Hung wrote:
> >
> > [...]
> >
> > > > > How about letting users specify the linear size through ctx->data_end? I am
> > > > > working on a set that introduces a kfunc, bpf_xdp_pull_data(). A part of is
> > > > > to support non-linear xdp_buff in test_run_xdp, and I am doing it through
> > > > > ctx->data_end. Is it something reasonable for test_run_skb?
> > > >
> > > > Oh, nice! That was next on my list :)
> > > >
> > > > Why use data_end though? I guess it'd work for skb, but can't we just
> > > > add a new field to the anonymous struct for BPF_PROG_TEST_RUN?
> > > >
> > >
> > > I choose to use ctx_in because it doesn't change the interface and
> > > feels natural. kattr->test.ctx_in is already copied from users and
> > > shows users' expectation about the input ctx. I think we should honor
> > > that (as long as the value makes sense). WDYT?
> >
> > Ok, I think I see your point of view. To me, test.ctx_in *is* the
> > context and not metadata about it. I'm worried it would be weird to
> > users if we overload that field. I'm not against using that though if
> > it's the consensus.
>
> Just about to say the same thing Martin mentioned.
>
> bpf_prog_test_run_xdp() is already using test.ctx_in since
> 47316f4a3053 ("bpf: Support input xdp_md context in
> BPF_PROG_TEST_RUN"). It allows users to supply metadata via
> test.data_in. ctx_in->data_meta must be zero and the first
> ctx_in->data - ctx_in->data_meta bytes in data_in will be copied into
> metadata. So continuing using ctx_in for specifying the linear data
> size is a logical next step.
I didn't know about that. Okay, makes sense. I'll send the v2 using
data_end.
>
> >
> > >
> > > Thanks for working on this. It would be great if there is some
> > > consistency between test_run_skb and test_run_xdp.
> >
> > Definitely agree! Do you have a prototype anywhere I could check? If
> > not, you can always flag any inconsistency when I send the v2.
> >
>
> Here is the set I am working on
> https://lore.kernel.org/bpf/20250905173352.3759457-1-ameryhung@gmail.com/
>
> Patch 5 allows using ctx_in->data_end to specify the linear xdp_buff
> size (i.e., ctx_in->data_end - ctx_in->data). Patch 6 uses it to test
> a new kfunc, bpf_xdp_pull_data().
>
> > [...]
> >
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2025-09-08 19:16 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-09-04 12:07 [PATCH bpf-next 0/4] bpf: Support non-linear skbs for BPF_PROG_TEST_RUN Paul Chaignon
2025-09-04 12:09 ` [PATCH bpf-next 1/4] bpf: Refactor cleanup of bpf_prog_test_run_skb Paul Chaignon
2025-09-05 12:57 ` kernel test robot
2025-09-04 12:11 ` [PATCH bpf-next 2/4] bpf: Craft non-linear skbs in BPF_PROG_TEST_RUN Paul Chaignon
2025-09-04 15:56 ` Alexei Starovoitov
2025-09-04 16:02 ` Daniel Borkmann
2025-09-04 16:27 ` Amery Hung
2025-09-05 13:23 ` Paul Chaignon
2025-09-05 16:34 ` Amery Hung
2025-09-08 17:41 ` Paul Chaignon
2025-09-08 19:09 ` Martin KaFai Lau
2025-09-08 19:10 ` Amery Hung
2025-09-08 19:16 ` Paul Chaignon
2025-09-04 12:13 ` [PATCH bpf-next 3/4] selftests/bpf: Support non-linear flag in test loader Paul Chaignon
2025-09-04 12:13 ` [PATCH bpf-next 4/4] selftests/bpf: Test direct packet access on non-linear skbs Paul Chaignon
2025-09-04 18:08 ` [syzbot ci] Re: bpf: Support non-linear skbs for BPF_PROG_TEST_RUN syzbot ci
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox