[PATCH bpf-next 0/4] bpf: Support non-linear skbs for BPF_PROG_TEST_RUN

[PATCH bpf-next 0/4] bpf: Support non-linear skbs for BPF_PROG_TEST_RUN

[Paul Chaignon]

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

[PATCH bpf-next 1/4] bpf: Refactor cleanup of bpf_prog_test_run_skb

[Paul Chaignon]

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

Re: [PATCH bpf-next 1/4] bpf: Refactor cleanup of bpf_prog_test_run_skb

[kernel test robot]

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

[PATCH bpf-next 2/4] bpf: Craft non-linear skbs in BPF_PROG_TEST_RUN

[Paul Chaignon]

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

Re: [PATCH bpf-next 2/4] bpf: Craft non-linear skbs in BPF_PROG_TEST_RUN

[Alexei Starovoitov]

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() ?

Re: [PATCH bpf-next 2/4] bpf: Craft non-linear skbs in BPF_PROG_TEST_RUN

[Daniel Borkmann]

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

Re: [PATCH bpf-next 2/4] bpf: Craft non-linear skbs in BPF_PROG_TEST_RUN

[Amery Hung]

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

Re: [PATCH bpf-next 2/4] bpf: Craft non-linear skbs in BPF_PROG_TEST_RUN

[Paul Chaignon]

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
> 

Re: [PATCH bpf-next 2/4] bpf: Craft non-linear skbs in BPF_PROG_TEST_RUN

[Amery Hung]

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

Re: [PATCH bpf-next 2/4] bpf: Craft non-linear skbs in BPF_PROG_TEST_RUN

[Paul Chaignon]

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.

[...]

Re: [PATCH bpf-next 2/4] bpf: Craft non-linear skbs in BPF_PROG_TEST_RUN

[Martin KaFai Lau]

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/

Re: [PATCH bpf-next 2/4] bpf: Craft non-linear skbs in BPF_PROG_TEST_RUN

[Amery Hung]

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

> [...]
>

Re: [PATCH bpf-next 2/4] bpf: Craft non-linear skbs in BPF_PROG_TEST_RUN

[Paul Chaignon]

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().
> 
> > [...]
> >

[PATCH bpf-next 3/4] selftests/bpf: Support non-linear flag in test loader

[Paul Chaignon]

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

[PATCH bpf-next 4/4] selftests/bpf: Test direct packet access on non-linear skbs

[Paul Chaignon]

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

[syzbot ci] Re: bpf: Support non-linear skbs for BPF_PROG_TEST_RUN

[syzbot ci]

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.