* [PATCH v2 0/2] bpf-next: Introduced to support the ULP to get or set sockets @ 2025-02-10 13:45 zhangmingyi 2025-02-10 13:45 ` [PATCH v2 1/2] " zhangmingyi 2025-02-10 13:45 ` [PATCH v2 2/2] bpf-next: selftest for TCP_ULP in bpf_setsockopt zhangmingyi 0 siblings, 2 replies; 11+ messages in thread From: zhangmingyi @ 2025-02-10 13:45 UTC (permalink / raw) To: ast, daniel, andrii, martin.lau, song, yhs, john.fastabend, kpsingh, sdf, haoluo, jolsa Cc: bpf, linux-kernel, yanan, wuchangye, xiesongyang, liuxin350, liwei883, tianmuyang, zhangmingyi5 From: Mingyi Zhang <zhangmingyi5@huawei.com> We want call bpf_setsockopt to replace the kernel module in the TCP_ULP case. The purpose is to customize the behavior in connect and sendmsg after the user-defined ko file is loaded. We have an open source community project kmesh (kmesh.net). Based on this, we refer to some processes of tcp fastopen to implement delayed connet and perform HTTP DNAT when sendmsg.In this case, we need to parse HTTP packets in the bpf program and set TCP_ULP for the specified socket. Note that tcp_getsockopt and tcp_setsockopt support TCP_ULP, while bpf_getsockopt and bpf_setsockopt do not support TCP_ULP. I'm not sure why there is such a difference, but I noticed that tcp_setsockopt is called in bpf_setsockopt.I think we can add the handling of this case. Change list: - v1 -> v2: - modified the do_tcp_setsockopt(TCP_ULP) process by referring to section do_tcp_setsockopt(TCP_CONGESTION), avoid sleep - The selftest case is modified. An independent file is selected for the test to avoid affecting the original file in setget_sockopt.c - fixed some formatting errors, such as Signed and Subject Revisions: - v1 https://lore.kernel.org/bpf/20250127090724.3168791-1-zhangmingyi5@huawei.com/ Mingyi Zhang (2): bpf-next: Introduced to support the ULP to get or set sockets bpf-next: selftest for TCP_ULP in bpf_setsockopt include/net/tcp.h | 2 +- net/core/filter.c | 1 + net/ipv4/tcp.c | 2 +- net/ipv4/tcp_ulp.c | 28 +++---- net/mptcp/subflow.c | 2 +- .../bpf/prog_tests/setget_sockopt_tcp_ulp.c | 78 +++++++++++++++++++ .../bpf/progs/setget_sockopt_tcp_ulp.c | 33 ++++++++ 7 files changed, 130 insertions(+), 16 deletions(-) create mode 100644 tools/testing/selftests/bpf/prog_tests/setget_sockopt_tcp_ulp.c create mode 100644 tools/testing/selftests/bpf/progs/setget_sockopt_tcp_ulp.c -- 2.43.0 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH v2 1/2] bpf-next: Introduced to support the ULP to get or set sockets 2025-02-10 13:45 [PATCH v2 0/2] bpf-next: Introduced to support the ULP to get or set sockets zhangmingyi @ 2025-02-10 13:45 ` zhangmingyi 2025-02-13 23:17 ` Martin KaFai Lau 2025-02-14 2:13 ` kernel test robot 2025-02-10 13:45 ` [PATCH v2 2/2] bpf-next: selftest for TCP_ULP in bpf_setsockopt zhangmingyi 1 sibling, 2 replies; 11+ messages in thread From: zhangmingyi @ 2025-02-10 13:45 UTC (permalink / raw) To: ast, daniel, andrii, martin.lau, song, yhs, john.fastabend, kpsingh, sdf, haoluo, jolsa Cc: bpf, linux-kernel, yanan, wuchangye, xiesongyang, liuxin350, liwei883, tianmuyang, zhangmingyi5 From: Mingyi Zhang <zhangmingyi5@huawei.com> Note that tcp_getsockopt and tcp_setsockopt support TCP_ULP, while bpf_getsockopt and bpf_setsockopt do not support TCP_ULP. I think we can add the handling of this case. We want call bpf_setsockopt to replace the kernel module in the TCP_ULP case. The purpose is to customize the behavior in connect and sendmsg. We have an open source community project kmesh (kmesh.net). Based on this, we refer to some processes of tcp fastopen to implement delayed connet and perform HTTP DNAT when sendmsg.In this case, we need to parse HTTP packets in the bpf program and set TCP_ULP for the specified socket. Signed-off-by: Mingyi Zhang <zhangmingyi5@huawei.com> Signed-off-by: Xin Liu <liuxin350@huawei.com> --- include/net/tcp.h | 2 +- net/core/filter.c | 1 + net/ipv4/tcp.c | 2 +- net/ipv4/tcp_ulp.c | 28 +++++++++++++++------------- net/mptcp/subflow.c | 2 +- 5 files changed, 19 insertions(+), 16 deletions(-) diff --git a/include/net/tcp.h b/include/net/tcp.h index e9b37b76e894..f26e92099b86 100644 --- a/include/net/tcp.h +++ b/include/net/tcp.h @@ -2582,7 +2582,7 @@ struct tcp_ulp_ops { }; int tcp_register_ulp(struct tcp_ulp_ops *type); void tcp_unregister_ulp(struct tcp_ulp_ops *type); -int tcp_set_ulp(struct sock *sk, const char *name); +int tcp_set_ulp(struct sock *sk, const char *name, bool load); void tcp_get_available_ulp(char *buf, size_t len); void tcp_cleanup_ulp(struct sock *sk); void tcp_update_ulp(struct sock *sk, struct proto *p, diff --git a/net/core/filter.c b/net/core/filter.c index 713d6f454df3..bdb5c43d6fb0 100644 --- a/net/core/filter.c +++ b/net/core/filter.c @@ -5380,6 +5380,7 @@ static int sol_tcp_sockopt(struct sock *sk, int optname, case TCP_CONGESTION: return sol_tcp_sockopt_congestion(sk, optval, optlen, getopt); case TCP_SAVED_SYN: + case TCP_ULP: if (*optlen < 1) return -EINVAL; break; diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c index 0d704bda6c41..88ccd0e211f9 100644 --- a/net/ipv4/tcp.c +++ b/net/ipv4/tcp.c @@ -3744,7 +3744,7 @@ int do_tcp_setsockopt(struct sock *sk, int level, int optname, name[val] = 0; sockopt_lock_sock(sk); - err = tcp_set_ulp(sk, name); + err = tcp_set_ulp(sk, name, !has_current_bpf_ctx()); sockopt_release_sock(sk); return err; } diff --git a/net/ipv4/tcp_ulp.c b/net/ipv4/tcp_ulp.c index 2aa442128630..c1c39dbef417 100644 --- a/net/ipv4/tcp_ulp.c +++ b/net/ipv4/tcp_ulp.c @@ -33,10 +33,7 @@ static struct tcp_ulp_ops *tcp_ulp_find(const char *name) static const struct tcp_ulp_ops *__tcp_ulp_find_autoload(const char *name) { - const struct tcp_ulp_ops *ulp = NULL; - - rcu_read_lock(); - ulp = tcp_ulp_find(name); + const struct tcp_ulp_ops *ulp = tcp_ulp_find(name); #ifdef CONFIG_MODULES if (!ulp && capable(CAP_NET_ADMIN)) { @@ -46,10 +43,6 @@ static const struct tcp_ulp_ops *__tcp_ulp_find_autoload(const char *name) ulp = tcp_ulp_find(name); } #endif - if (!ulp || !try_module_get(ulp->owner)) - ulp = NULL; - - rcu_read_unlock(); return ulp; } @@ -154,15 +147,24 @@ static int __tcp_set_ulp(struct sock *sk, const struct tcp_ulp_ops *ulp_ops) return err; } -int tcp_set_ulp(struct sock *sk, const char *name) +int tcp_set_ulp(struct sock *sk, const char *name, bool load) { const struct tcp_ulp_ops *ulp_ops; + int err = 0; sock_owned_by_me(sk); - ulp_ops = __tcp_ulp_find_autoload(name); - if (!ulp_ops) - return -ENOENT; + rcu_read_lock(); + if (!load) + ulp_ops = tcp_ulp_find(name); + else + ulp_ops = __tcp_ulp_find_autoload(name); + + if (!ulp_ops || !try_module_get(ulp_ops->owner)) + err = -ENOENT; + else + err = __tcp_set_ulp(sk, ulp_ops); - return __tcp_set_ulp(sk, ulp_ops); + rcu_read_unlock(); + return err; } diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c index fd021cf8286e..fb936d280b83 100644 --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -1776,7 +1776,7 @@ int mptcp_subflow_create_socket(struct sock *sk, unsigned short family, sf->sk->sk_net_refcnt = 1; get_net_track(net, &sf->sk->ns_tracker, GFP_KERNEL); sock_inuse_add(net, 1); - err = tcp_set_ulp(sf->sk, "mptcp"); + err = tcp_set_ulp(sf->sk, "mptcp", true); if (err) goto err_free; -- 2.43.0 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH v2 1/2] bpf-next: Introduced to support the ULP to get or set sockets 2025-02-10 13:45 ` [PATCH v2 1/2] " zhangmingyi @ 2025-02-13 23:17 ` Martin KaFai Lau 2025-02-14 2:13 ` kernel test robot 1 sibling, 0 replies; 11+ messages in thread From: Martin KaFai Lau @ 2025-02-13 23:17 UTC (permalink / raw) To: zhangmingyi Cc: ast, daniel, andrii, song, yhs, john.fastabend, kpsingh, haoluo, jolsa, bpf, linux-kernel, yanan, wuchangye, xiesongyang, liuxin350, liwei883, tianmuyang On 2/10/25 5:45 AM, zhangmingyi wrote: > From: Mingyi Zhang <zhangmingyi5@huawei.com> > > Note that tcp_getsockopt and tcp_setsockopt support TCP_ULP, while > bpf_getsockopt and bpf_setsockopt do not support TCP_ULP. > I think we can add the handling of this case. The commit message should talk about the "bool load" related changes in v2 and why it is needed. The subject line is confusing. How about, "Support TCP_ULP in bpf_get/setsockopt" The code changes lgtm. > > We want call bpf_setsockopt to replace the kernel module in the TCP_ULP > case. The purpose is to customize the behavior in connect and sendmsg. > We have an open source community project kmesh (kmesh.net). Based on > this, we refer to some processes of tcp fastopen to implement delayed > connet and perform HTTP DNAT when sendmsg.In this case, we need to parse > HTTP packets in the bpf program and set TCP_ULP for the specified socket. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2 1/2] bpf-next: Introduced to support the ULP to get or set sockets 2025-02-10 13:45 ` [PATCH v2 1/2] " zhangmingyi 2025-02-13 23:17 ` Martin KaFai Lau @ 2025-02-14 2:13 ` kernel test robot 2025-02-14 6:23 ` Martin KaFai Lau 1 sibling, 1 reply; 11+ messages in thread From: kernel test robot @ 2025-02-14 2:13 UTC (permalink / raw) To: zhangmingyi Cc: oe-lkp, lkp, Xin Liu, netdev, bpf, mptcp, ast, daniel, andrii, martin.lau, song, yhs, john.fastabend, kpsingh, sdf, haoluo, jolsa, linux-kernel, yanan, wuchangye, xiesongyang, liwei883, tianmuyang, zhangmingyi5, oliver.sang Hello, kernel test robot noticed "BUG:sleeping_function_called_from_invalid_context_at_kernel/locking/mutex.c" on: commit: 8f510de3f26b2fabaf47eacd59053469e9c32754 ("[PATCH v2 1/2] bpf-next: Introduced to support the ULP to get or set sockets") url: https://github.com/intel-lab-lkp/linux/commits/zhangmingyi/bpf-next-Introduced-to-support-the-ULP-to-get-or-set-sockets/20250210-215203 base: https://git.kernel.org/cgit/linux/kernel/git/bpf/bpf-next.git master patch link: https://lore.kernel.org/all/20250210134550.3189616-2-zhangmingyi5@huawei.com/ patch subject: [PATCH v2 1/2] bpf-next: Introduced to support the ULP to get or set sockets in testcase: trinity version: trinity-i386-abe9de86-1_20230429 with following parameters: runtime: 300s group: group-03 nr_groups: 5 config: i386-randconfig-054-20250212 compiler: gcc-12 test machine: qemu-system-i386 -enable-kvm -cpu SandyBridge -smp 2 -m 4G (please refer to attached dmesg/kmsg for entire log/backtrace) +-----------------------------------------------------------------------------+------------+------------+ | | 9b6cdaf2ac | 8f510de3f2 | +-----------------------------------------------------------------------------+------------+------------+ | BUG:sleeping_function_called_from_invalid_context_at_kernel/locking/mutex.c | 0 | 6 | +-----------------------------------------------------------------------------+------------+------------+ 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 <oliver.sang@intel.com> | Closes: https://lore.kernel.org/oe-lkp/202502140959.f66e2ba6-lkp@intel.com [ 71.099773][ T3759] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:562 [ 71.101798][ T3759] in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 3759, name: trinity-c4 [ 71.103659][ T3759] preempt_count: 0, expected: 0 [ 71.104658][ T3759] RCU nest depth: 1, expected: 0 [ 71.105669][ T3759] 2 locks held by trinity-c4/3759: [ 71.106777][ T3759] #0: ecffcd80 (sk_lock-AF_INET){+.+.}-{0:0}, at: lock_sock (include/net/sock.h:1625) [ 71.108460][ T3759] #1: c3500498 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire (include/linux/rcupdate.h:336) [ 71.110397][ T3759] CPU: 1 UID: 65534 PID: 3759 Comm: trinity-c4 Tainted: G T 6.14.0-rc1-00030-g8f510de3f26b #1 8ad64aae41fa4cb8babad52c8f50e0a7d5e34569 [ 71.110406][ T3759] Tainted: [T]=RANDSTRUCT [ 71.110407][ T3759] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 [ 71.110410][ T3759] Call Trace: [ 71.110416][ T3759] dump_stack_lvl (lib/dump_stack.c:123) [ 71.110423][ T3759] dump_stack (lib/dump_stack.c:130) [ 71.110428][ T3759] __might_resched (kernel/sched/core.c:8767) [ 71.110440][ T3759] __might_sleep (kernel/sched/core.c:8696 (discriminator 17)) [ 71.110446][ T3759] __mutex_lock (include/linux/kernel.h:73 kernel/locking/mutex.c:562 kernel/locking/mutex.c:730) [ 71.110452][ T3759] ? rcu_read_unlock (include/linux/rcupdate.h:335) [ 71.110462][ T3759] ? mark_held_locks (kernel/locking/lockdep.c:4323) [ 71.110470][ T3759] ? lock_sock_nested (net/core/sock.c:3653) [ 71.110481][ T3759] mutex_lock_nested (kernel/locking/mutex.c:783) [ 71.110486][ T3759] ? tls_init (net/tls/tls_main.c:934 net/tls/tls_main.c:993) [ 71.110494][ T3759] tls_init (net/tls/tls_main.c:934 net/tls/tls_main.c:993) [ 71.110505][ T3759] tcp_set_ulp (net/ipv4/tcp_ulp.c:140 net/ipv4/tcp_ulp.c:166) [ 71.110513][ T3759] do_tcp_setsockopt (net/ipv4/tcp.c:3747) [ 71.110534][ T3759] tcp_setsockopt (net/ipv4/tcp.c:4032) [ 71.110542][ T3759] ? sock_common_recvmsg (net/core/sock.c:3833) [ 71.110548][ T3759] sock_common_setsockopt (net/core/sock.c:3838) [ 71.110561][ T3759] do_sock_setsockopt (net/socket.c:2298) [ 71.110577][ T3759] __sys_setsockopt (net/socket.c:2323) [ 71.110592][ T3759] __ia32_sys_setsockopt (net/socket.c:2326) [ 71.110599][ T3759] ia32_sys_call (kbuild/obj/consumer/i386-randconfig-054-20250212/./arch/x86/include/generated/asm/syscalls_32.h:367) [ 71.110607][ T3759] do_int80_syscall_32 (arch/x86/entry/common.c:165 arch/x86/entry/common.c:339) [ 71.110616][ T3759] entry_INT80_32 (arch/x86/entry/entry_32.S:942) [ 71.110621][ T3759] EIP: 0xb4014092 [ 71.110626][ T3759] Code: 00 00 00 e9 90 ff ff ff ff a3 24 00 00 00 68 30 00 00 00 e9 80 ff ff ff ff a3 f8 ff ff ff 66 90 00 00 00 00 00 00 00 00 cd 80 <c3> 8d b4 26 00 00 00 00 8d b6 00 00 00 00 8b 1c 24 c3 8d b4 26 00 All code ======== 0: 00 00 add %al,(%rax) 2: 00 e9 add %ch,%cl 4: 90 nop 5: ff (bad) 6: ff (bad) 7: ff (bad) 8: ff a3 24 00 00 00 jmp *0x24(%rbx) e: 68 30 00 00 00 push $0x30 13: e9 80 ff ff ff jmp 0xffffffffffffff98 18: ff a3 f8 ff ff ff jmp *-0x8(%rbx) 1e: 66 90 xchg %ax,%ax ... 28: cd 80 int $0x80 2a:* c3 ret <-- trapping instruction 2b: 8d b4 26 00 00 00 00 lea 0x0(%rsi,%riz,1),%esi 32: 8d b6 00 00 00 00 lea 0x0(%rsi),%esi 38: 8b 1c 24 mov (%rsp),%ebx 3b: c3 ret 3c: 8d .byte 0x8d 3d: b4 26 mov $0x26,%ah ... Code starting with the faulting instruction =========================================== 0: c3 ret 1: 8d b4 26 00 00 00 00 lea 0x0(%rsi,%riz,1),%esi 8: 8d b6 00 00 00 00 lea 0x0(%rsi),%esi e: 8b 1c 24 mov (%rsp),%ebx 11: c3 ret 12: 8d .byte 0x8d 13: b4 26 mov $0x26,%ah ... [ 71.110630][ T3759] EAX: ffffffda EBX: 00000134 ECX: 00000006 EDX: 0000001f [ 71.110634][ T3759] ESI: 08fee650 EDI: 00000004 EBP: 000012cf ESP: bfc1c538 [ 71.110638][ T3759] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000296 [ 71.182507][ T3759] [ 71.182999][ T3759] ============================= [ 71.183907][ T3759] [ BUG: Invalid wait context ] [ 71.184819][ T3759] 6.14.0-rc1-00030-g8f510de3f26b #1 Tainted: G W T [ 71.186327][ T3759] ----------------------------- [ 71.187265][ T3759] trinity-c4/3759 is trying to lock: [ 71.188287][ T3759] c37b35e0 (tcpv4_prot_mutex){....}-{4:4}, at: tls_init (net/tls/tls_main.c:934 net/tls/tls_main.c:993) [ 71.189847][ T3759] other info that might help us debug this: [ 71.191018][ T3759] context-{5:5} [ 71.191678][ T3759] 2 locks held by trinity-c4/3759: [ 71.192635][ T3759] #0: ecffcd80 (sk_lock-AF_INET){+.+.}-{0:0}, at: lock_sock (include/net/sock.h:1625) [ 71.194220][ T3759] #1: c3500498 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire (include/linux/rcupdate.h:336) [ 71.196078][ T3759] stack backtrace: [ 71.196797][ T3759] CPU: 0 UID: 65534 PID: 3759 Comm: trinity-c4 Tainted: G W T 6.14.0-rc1-00030-g8f510de3f26b #1 8ad64aae41fa4cb8babad52c8f50e0a7d5e34569 [ 71.196807][ T3759] Tainted: [W]=WARN, [T]=RANDSTRUCT [ 71.196809][ T3759] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 [ 71.196812][ T3759] Call Trace: [ 71.196818][ T3759] dump_stack_lvl (lib/dump_stack.c:123) [ 71.196825][ T3759] dump_stack (lib/dump_stack.c:130) [ 71.196830][ T3759] __lock_acquire (kernel/locking/lockdep.c:4830 kernel/locking/lockdep.c:4900 kernel/locking/lockdep.c:5178) [ 71.196840][ T3759] lock_acquire (kernel/locking/lockdep.c:469 kernel/locking/lockdep.c:5853) [ 71.196846][ T3759] ? tls_init (net/tls/tls_main.c:934 net/tls/tls_main.c:993) [ 71.196856][ T3759] ? __schedule (kernel/sched/core.c:5380) [ 71.196866][ T3759] __mutex_lock (kernel/locking/mutex.c:587 kernel/locking/mutex.c:730) [ 71.196872][ T3759] ? tls_init (net/tls/tls_main.c:934 net/tls/tls_main.c:993) [ 71.196878][ T3759] ? rcu_read_unlock (include/linux/rcupdate.h:335) [ 71.196885][ T3759] ? mark_held_locks (kernel/locking/lockdep.c:4323) [ 71.196889][ T3759] ? lock_sock_nested (net/core/sock.c:3653) [ 71.196898][ T3759] mutex_lock_nested (kernel/locking/mutex.c:783) [ 71.196904][ T3759] ? tls_init (net/tls/tls_main.c:934 net/tls/tls_main.c:993) [ 71.196909][ T3759] tls_init (net/tls/tls_main.c:934 net/tls/tls_main.c:993) [ 71.196916][ T3759] tcp_set_ulp (net/ipv4/tcp_ulp.c:140 net/ipv4/tcp_ulp.c:166) [ 71.196923][ T3759] do_tcp_setsockopt (net/ipv4/tcp.c:3747) [ 71.196934][ T3759] tcp_setsockopt (net/ipv4/tcp.c:4032) [ 71.196939][ T3759] ? sock_common_recvmsg (net/core/sock.c:3833) [ 71.196946][ T3759] sock_common_setsockopt (net/core/sock.c:3838) [ 71.196952][ T3759] do_sock_setsockopt (net/socket.c:2298) [ 71.196961][ T3759] __sys_setsockopt (net/socket.c:2323) [ 71.196967][ T3759] __ia32_sys_setsockopt (net/socket.c:2326) [ 71.196972][ T3759] ia32_sys_call (kbuild/obj/consumer/i386-randconfig-054-20250212/./arch/x86/include/generated/asm/syscalls_32.h:367) [ 71.196979][ T3759] do_int80_syscall_32 (arch/x86/entry/common.c:165 arch/x86/entry/common.c:339) [ 71.196985][ T3759] entry_INT80_32 (arch/x86/entry/entry_32.S:942) [ 71.196990][ T3759] EIP: 0xb4014092 [ 71.196995][ T3759] Code: 00 00 00 e9 90 ff ff ff ff a3 24 00 00 00 68 30 00 00 00 e9 80 ff ff ff ff a3 f8 ff ff ff 66 90 00 00 00 00 00 00 00 00 cd 80 <c3> 8d b4 26 00 00 00 00 8d b6 00 00 00 00 8b 1c 24 c3 8d b4 26 00 All code ======== 0: 00 00 add %al,(%rax) 2: 00 e9 add %ch,%cl 4: 90 nop 5: ff (bad) 6: ff (bad) 7: ff (bad) 8: ff a3 24 00 00 00 jmp *0x24(%rbx) e: 68 30 00 00 00 push $0x30 13: e9 80 ff ff ff jmp 0xffffffffffffff98 18: ff a3 f8 ff ff ff jmp *-0x8(%rbx) 1e: 66 90 xchg %ax,%ax ... 28: cd 80 int $0x80 2a:* c3 ret <-- trapping instruction 2b: 8d b4 26 00 00 00 00 lea 0x0(%rsi,%riz,1),%esi 32: 8d b6 00 00 00 00 lea 0x0(%rsi),%esi 38: 8b 1c 24 mov (%rsp),%ebx 3b: c3 ret 3c: 8d .byte 0x8d 3d: b4 26 mov $0x26,%ah ... Code starting with the faulting instruction =========================================== 0: c3 ret 1: 8d b4 26 00 00 00 00 lea 0x0(%rsi,%riz,1),%esi 8: 8d b6 00 00 00 00 lea 0x0(%rsi),%esi e: 8b 1c 24 mov (%rsp),%ebx 11: c3 ret 12: 8d .byte 0x8d 13: b4 26 mov $0x26,%ah ... [ 71.196999][ T3759] EAX: ffffffda EBX: 00000134 ECX: 00000006 EDX: 0000001f [ 71.197004][ T3759] ESI: 08fee650 EDI: 00000004 EBP: 000012cf ESP: bfc1c538 [ 71.197008][ T3759] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000296 The kernel config and materials to reproduce are available at: https://download.01.org/0day-ci/archive/20250214/202502140959.f66e2ba6-lkp@intel.com -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2 1/2] bpf-next: Introduced to support the ULP to get or set sockets 2025-02-14 2:13 ` kernel test robot @ 2025-02-14 6:23 ` Martin KaFai Lau 2025-02-14 21:20 ` Jakub Kicinski 0 siblings, 1 reply; 11+ messages in thread From: Martin KaFai Lau @ 2025-02-14 6:23 UTC (permalink / raw) To: zhangmingyi Cc: kernel test robot, oe-lkp, lkp, Xin Liu, netdev, bpf, mptcp, ast, daniel, andrii, song, yhs, john.fastabend, kpsingh, sdf, haoluo, jolsa, linux-kernel, yanan, wuchangye, xiesongyang, liwei883, tianmuyang On 2/13/25 6:13 PM, kernel test robot wrote: > [ 71.182999][ T3759] ============================= > [ 71.183907][ T3759] [ BUG: Invalid wait context ] > [ 71.184819][ T3759] 6.14.0-rc1-00030-g8f510de3f26b #1 Tainted: G W T > [ 71.186327][ T3759] ----------------------------- > [ 71.187265][ T3759] trinity-c4/3759 is trying to lock: > [ 71.188287][ T3759] c37b35e0 (tcpv4_prot_mutex){....}-{4:4}, at: tls_init (net/tls/tls_main.c:934 net/tls/tls_main.c:993) > [ 71.189847][ T3759] other info that might help us debug this: > [ 71.191018][ T3759] context-{5:5} > [ 71.191678][ T3759] 2 locks held by trinity-c4/3759: > [ 71.192635][ T3759] #0: ecffcd80 (sk_lock-AF_INET){+.+.}-{0:0}, at: lock_sock (include/net/sock.h:1625) > [ 71.194220][ T3759] #1: c3500498 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire (include/linux/rcupdate.h:336) > [ 71.196078][ T3759] stack backtrace: > [ 71.196797][ T3759] CPU: 0 UID: 65534 PID: 3759 Comm: trinity-c4 Tainted: G W T 6.14.0-rc1-00030-g8f510de3f26b #1 8ad64aae41fa4cb8babad52c8f50e0a7d5e34569 > [ 71.196807][ T3759] Tainted: [W]=WARN, [T]=RANDSTRUCT > [ 71.196809][ T3759] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 > [ 71.196812][ T3759] Call Trace: > [ 71.196818][ T3759] dump_stack_lvl (lib/dump_stack.c:123) > [ 71.196825][ T3759] dump_stack (lib/dump_stack.c:130) > [ 71.196830][ T3759] __lock_acquire (kernel/locking/lockdep.c:4830 kernel/locking/lockdep.c:4900 kernel/locking/lockdep.c:5178) > [ 71.196840][ T3759] lock_acquire (kernel/locking/lockdep.c:469 kernel/locking/lockdep.c:5853) > [ 71.196846][ T3759] ? tls_init (net/tls/tls_main.c:934 net/tls/tls_main.c:993) > [ 71.196856][ T3759] ? __schedule (kernel/sched/core.c:5380) > [ 71.196866][ T3759] __mutex_lock (kernel/locking/mutex.c:587 kernel/locking/mutex.c:730) > [ 71.196872][ T3759] ? tls_init (net/tls/tls_main.c:934 net/tls/tls_main.c:993) > [ 71.196878][ T3759] ? rcu_read_unlock (include/linux/rcupdate.h:335) > [ 71.196885][ T3759] ? mark_held_locks (kernel/locking/lockdep.c:4323) > [ 71.196889][ T3759] ? lock_sock_nested (net/core/sock.c:3653) > [ 71.196898][ T3759] mutex_lock_nested (kernel/locking/mutex.c:783) This is probably because __tcp_set_ulp is now under the rcu_read_lock() in patch 1. Even fixing patch 1 will not be enough. The bpf cgrp prog (e.g. sockops) cannot sleep now, so it still cannot call bpf_setsockopt(TCP_ULP, "tls") which will take a mutex. This is a blocker :( > [ 71.196904][ T3759] ? tls_init (net/tls/tls_main.c:934 net/tls/tls_main.c:993) > [ 71.196909][ T3759] tls_init (net/tls/tls_main.c:934 net/tls/tls_main.c:993) > [ 71.196916][ T3759] tcp_set_ulp (net/ipv4/tcp_ulp.c:140 net/ipv4/tcp_ulp.c:166) > [ 71.196923][ T3759] do_tcp_setsockopt (net/ipv4/tcp.c:3747) > [ 71.196934][ T3759] tcp_setsockopt (net/ipv4/tcp.c:4032) > [ 71.196939][ T3759] ? sock_common_recvmsg (net/core/sock.c:3833) > [ 71.196946][ T3759] sock_common_setsockopt (net/core/sock.c:3838) > [ 71.196952][ T3759] do_sock_setsockopt (net/socket.c:2298) > [ 71.196961][ T3759] __sys_setsockopt (net/socket.c:2323) > [ 71.196967][ T3759] __ia32_sys_setsockopt (net/socket.c:2326) > [ 71.196972][ T3759] ia32_sys_call (kbuild/obj/consumer/i386-randconfig-054-20250212/./arch/x86/include/generated/asm/syscalls_32.h:367) > [ 71.196979][ T3759] do_int80_syscall_32 (arch/x86/entry/common.c:165 arch/x86/entry/common.c:339) > [ 71.196985][ T3759] entry_INT80_32 (arch/x86/entry/entry_32.S:942) ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2 1/2] bpf-next: Introduced to support the ULP to get or set sockets 2025-02-14 6:23 ` Martin KaFai Lau @ 2025-02-14 21:20 ` Jakub Kicinski 2025-02-14 22:11 ` Martin KaFai Lau 0 siblings, 1 reply; 11+ messages in thread From: Jakub Kicinski @ 2025-02-14 21:20 UTC (permalink / raw) To: Martin KaFai Lau Cc: zhangmingyi, kernel test robot, oe-lkp, lkp, Xin Liu, netdev, bpf, mptcp, ast, daniel, andrii, song, yhs, john.fastabend, kpsingh, sdf, haoluo, jolsa, linux-kernel, yanan, wuchangye, xiesongyang, liwei883, tianmuyang On Thu, 13 Feb 2025 22:23:39 -0800 Martin KaFai Lau wrote: > On 2/13/25 6:13 PM, kernel test robot wrote: > > [ 71.196846][ T3759] ? tls_init (net/tls/tls_main.c:934 net/tls/tls_main.c:993) > > [ 71.196856][ T3759] ? __schedule (kernel/sched/core.c:5380) > > [ 71.196866][ T3759] __mutex_lock (kernel/locking/mutex.c:587 kernel/locking/mutex.c:730) > > [ 71.196872][ T3759] ? tls_init (net/tls/tls_main.c:934 net/tls/tls_main.c:993) > > [ 71.196878][ T3759] ? rcu_read_unlock (include/linux/rcupdate.h:335) > > [ 71.196885][ T3759] ? mark_held_locks (kernel/locking/lockdep.c:4323) > > [ 71.196889][ T3759] ? lock_sock_nested (net/core/sock.c:3653) > > [ 71.196898][ T3759] mutex_lock_nested (kernel/locking/mutex.c:783) > > This is probably because __tcp_set_ulp is now under the rcu_read_lock() in patch 1. > > Even fixing patch 1 will not be enough. The bpf cgrp prog (e.g. sockops) cannot > sleep now, so it still cannot call bpf_setsockopt(TCP_ULP, "tls") which will > take a mutex. This is a blocker :( Oh, kbuild bot was nice enough to CC netdev, it wasn't CCed on the submission. I'd really rather we didn't allow setting ULP from BPF unless there is a strong and clear use case. The ULP configuration and stacking is a source of many bugs. And the use case here AFAIU is to allow attaching some ULP from an OOT module to a socket, which I think won't make core BPF folks happy either, right? ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2 1/2] bpf-next: Introduced to support the ULP to get or set sockets 2025-02-14 21:20 ` Jakub Kicinski @ 2025-02-14 22:11 ` Martin KaFai Lau 0 siblings, 0 replies; 11+ messages in thread From: Martin KaFai Lau @ 2025-02-14 22:11 UTC (permalink / raw) To: Jakub Kicinski Cc: zhangmingyi, kernel test robot, oe-lkp, lkp, Xin Liu, netdev, bpf, mptcp, ast, daniel, andrii, song, yhs, john.fastabend, kpsingh, sdf, haoluo, jolsa, linux-kernel, yanan, wuchangye, xiesongyang, liwei883, tianmuyang On 2/14/25 1:20 PM, Jakub Kicinski wrote: > On Thu, 13 Feb 2025 22:23:39 -0800 Martin KaFai Lau wrote: >> On 2/13/25 6:13 PM, kernel test robot wrote: >>> [ 71.196846][ T3759] ? tls_init (net/tls/tls_main.c:934 net/tls/tls_main.c:993) >>> [ 71.196856][ T3759] ? __schedule (kernel/sched/core.c:5380) >>> [ 71.196866][ T3759] __mutex_lock (kernel/locking/mutex.c:587 kernel/locking/mutex.c:730) >>> [ 71.196872][ T3759] ? tls_init (net/tls/tls_main.c:934 net/tls/tls_main.c:993) >>> [ 71.196878][ T3759] ? rcu_read_unlock (include/linux/rcupdate.h:335) >>> [ 71.196885][ T3759] ? mark_held_locks (kernel/locking/lockdep.c:4323) >>> [ 71.196889][ T3759] ? lock_sock_nested (net/core/sock.c:3653) >>> [ 71.196898][ T3759] mutex_lock_nested (kernel/locking/mutex.c:783) >> >> This is probably because __tcp_set_ulp is now under the rcu_read_lock() in patch 1. >> >> Even fixing patch 1 will not be enough. The bpf cgrp prog (e.g. sockops) cannot >> sleep now, so it still cannot call bpf_setsockopt(TCP_ULP, "tls") which will >> take a mutex. This is a blocker :( > > Oh, kbuild bot was nice enough to CC netdev, it wasn't CCed on > the submission. Ah. I also didn't notice netdev was not cc-ed. will pay attention in the future. > > I'd really rather we didn't allow setting ULP from BPF unless there > is a strong and clear use case. The ULP configuration and stacking > is a source of many bugs. And the use case here AFAIU is to allow > attaching some ULP from an OOT module to a socket, which I think > won't make core BPF folks happy either, right? If the in-tree ulp does not work, there is little reason to do it for the out-of-tree module only. My question on the ulp use case went to silence in v1, so we can assume it is out-of-tree ulp only. I also asked to replace the "smc" ulp testing with a more real "tls" ulp testing to see how it goes first. It does not work as the bot reported it. ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH v2 2/2] bpf-next: selftest for TCP_ULP in bpf_setsockopt 2025-02-10 13:45 [PATCH v2 0/2] bpf-next: Introduced to support the ULP to get or set sockets zhangmingyi 2025-02-10 13:45 ` [PATCH v2 1/2] " zhangmingyi @ 2025-02-10 13:45 ` zhangmingyi 2025-02-13 23:19 ` Martin KaFai Lau 2025-02-14 17:44 ` kernel test robot 1 sibling, 2 replies; 11+ messages in thread From: zhangmingyi @ 2025-02-10 13:45 UTC (permalink / raw) To: ast, daniel, andrii, martin.lau, song, yhs, john.fastabend, kpsingh, sdf, haoluo, jolsa Cc: bpf, linux-kernel, yanan, wuchangye, xiesongyang, liuxin350, liwei883, tianmuyang, zhangmingyi5 From: Mingyi Zhang <zhangmingyi5@huawei.com> We try to use bpf_set/getsockopt to set/get TCP_ULP in sockops, and "tls" need connect is established.To avoid impacting other test cases, I have written a separate test case file. Signed-off-by: Mingyi Zhang <zhangmingyi5@huawei.com> Signed-off-by: Xin Liu <liuxin350@huawei.com> --- .../bpf/prog_tests/setget_sockopt_tcp_ulp.c | 78 +++++++++++++++++++ .../bpf/progs/setget_sockopt_tcp_ulp.c | 33 ++++++++ 2 files changed, 111 insertions(+) create mode 100644 tools/testing/selftests/bpf/prog_tests/setget_sockopt_tcp_ulp.c create mode 100644 tools/testing/selftests/bpf/progs/setget_sockopt_tcp_ulp.c diff --git a/tools/testing/selftests/bpf/prog_tests/setget_sockopt_tcp_ulp.c b/tools/testing/selftests/bpf/prog_tests/setget_sockopt_tcp_ulp.c new file mode 100644 index 000000000000..748da2c7d255 --- /dev/null +++ b/tools/testing/selftests/bpf/prog_tests/setget_sockopt_tcp_ulp.c @@ -0,0 +1,78 @@ +// SPDX-License-Identifier: GPL-2.0 +/* Copyright (c) Meta Platforms, Inc. and affiliates. */ + +#define _GNU_SOURCE +#include <net/if.h> + +#include "test_progs.h" +#include "network_helpers.h" + +#include "setget_sockopt_tcp_ulp.skel.h" + +#define CG_NAME "/setget-sockopt-tcp-ulp-test" + +static const char addr4_str[] = "127.0.0.1"; +static const char addr6_str[] = "::1"; +static struct setget_sockopt_tcp_ulp *skel; +static int cg_fd; + +static int create_netns(void) +{ + if (!ASSERT_OK(unshare(CLONE_NEWNET), "create netns")) + return -1; + if (!ASSERT_OK(system("ip link set dev lo up"), "set lo up")) + return -1; + return 0; +} + +static int modprobe_tls(void) +{ + if (!ASSERT_OK(system("modprobe tls"), "tls modprobe failed")) + return -1; + return 0; +} + +static void test_tcp_ulp(int family) +{ + struct setget_sockopt_tcp_ulp__bss *bss = skel->bss; + int sfd, cfd; + + memset(bss, 0, sizeof(*bss)); + sfd = start_server(family, SOCK_STREAM, + family == AF_INET6 ? addr6_str : addr4_str, 0, 0); + if (!ASSERT_GE(sfd, 0, "start_server")) + return; + + cfd = connect_to_fd(sfd, 0); + if (!ASSERT_GE(cfd, 0, "connect_to_fd_server")) { + close(sfd); + return; + } + close(sfd); + close(cfd); + + ASSERT_EQ(bss->nr_tcp_ulp, 3, "nr_tcp_ulp"); +} + +void test_setget_sockopt_tcp_ulp(void) +{ + cg_fd = test__join_cgroup(CG_NAME); + if (cg_fd < 0) + return; + if (create_netns() && modprobe_tls()) + goto done; + skel = setget_sockopt_tcp_ulp__open(); + if (!ASSERT_OK_PTR(skel, "open skel")) + goto done; + if (!ASSERT_OK(setget_sockopt_tcp_ulp__load(skel), "load skel")) + goto done; + skel->links.skops_sockopt_tcp_ulp = + bpf_program__attach_cgroup(skel->progs.skops_sockopt_tcp_ulp, cg_fd); + if (!ASSERT_OK_PTR(skel->links.skops_sockopt_tcp_ulp, "attach_cgroup")) + goto done; + test_tcp_ulp(AF_INET); + test_tcp_ulp(AF_INET6); +done: + setget_sockopt_tcp_ulp__destroy(skel); + close(cg_fd); +} diff --git a/tools/testing/selftests/bpf/progs/setget_sockopt_tcp_ulp.c b/tools/testing/selftests/bpf/progs/setget_sockopt_tcp_ulp.c new file mode 100644 index 000000000000..bd1009766463 --- /dev/null +++ b/tools/testing/selftests/bpf/progs/setget_sockopt_tcp_ulp.c @@ -0,0 +1,33 @@ +// SPDX-License-Identifier: GPL-2.0 +/* Copyright (c) Meta Platforms, Inc. and affiliates. */ + +#include "vmlinux.h" +#include "bpf_tracing_net.h" +#include <bpf/bpf_helpers.h> + +int nr_tcp_ulp; + +SEC("sockops") +int skops_sockopt_tcp_ulp(struct bpf_sock_ops *skops) +{ + static const char target_ulp[] = "tls"; + char verify_ulp[sizeof(target_ulp)]; + + switch (skops->op) { + case BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB: + if (bpf_setsockopt(skops, IPPROTO_TCP, TCP_ULP, (void *)target_ulp, + sizeof(target_ulp)) != 0) + return 1; + nr_tcp_ulp++; + if (bpf_getsockopt(skops, IPPROTO_TCP, TCP_ULP, verify_ulp, + sizeof(verify_ulp)) != 0) + return 1; + nr_tcp_ulp++; + if (bpf_strncmp(verify_ulp, sizeof(target_ulp), "tls") != 0) + return 1; + nr_tcp_ulp++; + } + return 1; +} + +char _license[] SEC("license") = "GPL"; \ No newline at end of file -- 2.43.0 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH v2 2/2] bpf-next: selftest for TCP_ULP in bpf_setsockopt 2025-02-10 13:45 ` [PATCH v2 2/2] bpf-next: selftest for TCP_ULP in bpf_setsockopt zhangmingyi @ 2025-02-13 23:19 ` Martin KaFai Lau 2025-02-28 6:44 ` zhangmingyi 2025-02-14 17:44 ` kernel test robot 1 sibling, 1 reply; 11+ messages in thread From: Martin KaFai Lau @ 2025-02-13 23:19 UTC (permalink / raw) To: zhangmingyi Cc: ast, daniel, andrii, song, yhs, john.fastabend, kpsingh, sdf, haoluo, jolsa, bpf, linux-kernel, yanan, wuchangye, xiesongyang, liuxin350, liwei883, tianmuyang On 2/10/25 5:45 AM, zhangmingyi wrote: > From: Mingyi Zhang <zhangmingyi5@huawei.com> > > We try to use bpf_set/getsockopt to set/get TCP_ULP in sockops, and "tls" > need connect is established.To avoid impacting other test cases, I have > written a separate test case file. > > Signed-off-by: Mingyi Zhang <zhangmingyi5@huawei.com> > Signed-off-by: Xin Liu <liuxin350@huawei.com> > --- > .../bpf/prog_tests/setget_sockopt_tcp_ulp.c | 78 +++++++++++++++++++ > .../bpf/progs/setget_sockopt_tcp_ulp.c | 33 ++++++++ > 2 files changed, 111 insertions(+) > create mode 100644 tools/testing/selftests/bpf/prog_tests/setget_sockopt_tcp_ulp.c > create mode 100644 tools/testing/selftests/bpf/progs/setget_sockopt_tcp_ulp.c > > diff --git a/tools/testing/selftests/bpf/prog_tests/setget_sockopt_tcp_ulp.c b/tools/testing/selftests/bpf/prog_tests/setget_sockopt_tcp_ulp.c > new file mode 100644 > index 000000000000..748da2c7d255 > --- /dev/null > +++ b/tools/testing/selftests/bpf/prog_tests/setget_sockopt_tcp_ulp.c > @@ -0,0 +1,78 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* Copyright (c) Meta Platforms, Inc. and affiliates. */ This is not right. > + > +#define _GNU_SOURCE > +#include <net/if.h> > + > +#include "test_progs.h" > +#include "network_helpers.h" > + > +#include "setget_sockopt_tcp_ulp.skel.h" > + > +#define CG_NAME "/setget-sockopt-tcp-ulp-test" > + > +static const char addr4_str[] = "127.0.0.1"; > +static const char addr6_str[] = "::1"; > +static struct setget_sockopt_tcp_ulp *skel; > +static int cg_fd; > + > +static int create_netns(void) > +{ > + if (!ASSERT_OK(unshare(CLONE_NEWNET), "create netns")) > + return -1; > + if (!ASSERT_OK(system("ip link set dev lo up"), "set lo up")) > + return -1; > + return 0; > +} > + > +static int modprobe_tls(void) > +{ > + if (!ASSERT_OK(system("modprobe tls"), "tls modprobe failed")) > + return -1; > + return 0; > +} > + > +static void test_tcp_ulp(int family) First, the bpf CI still fails to compile for the same reason as v1. You should have received an email from bpf CI bot. Please ensure it is addressed first before reposting. This repeated bpf CI error is an automatic nack. pw-bot: cr The subject tagging should be "[PATCH v2 bpf-next ...] selftests/bpf: ... ". There are many examples to follow in the mailing list if it is not clear. Regarding the v1 comment: "...separate it out into its own BPF program..." The comment was made at the bpf prog file, "progs/setget_sockopt.c". I meant only create a separate bpf program. The user space part can stay in prog_tests/setget_sockopt.c. Move this function, test_tcp_ulp, to prog_tests/setget_sockopt.c. Then all the above config preparation codes and the test_setget_sockopt_tcp_ulp() can be saved. modprobe_tls() is not needed also. Do it after the test_ktls(). Take a look at test_nonstandard_opt() in prog_tests/setget_sockopt.c. It is testing another bpf prog in the same prog_tests/setget_sockopt.c. Also, for the bpf prog, do you really need to test at BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB? If not, just testing at SEC("lsm_cgroup/socket_post_create") will be easier. You can detach the previously attached skel->links.socket_post_create by using bpf_link__destroy() first and then attach yours bpf prog to do the test. > +{ > + struct setget_sockopt_tcp_ulp__bss *bss = skel->bss; > + int sfd, cfd; > + > + memset(bss, 0, sizeof(*bss)); > + sfd = start_server(family, SOCK_STREAM, > + family == AF_INET6 ? addr6_str : addr4_str, 0, 0); > + if (!ASSERT_GE(sfd, 0, "start_server")) > + return; > + > + cfd = connect_to_fd(sfd, 0); > + if (!ASSERT_GE(cfd, 0, "connect_to_fd_server")) { > + close(sfd); > + return; > + } > + close(sfd); > + close(cfd); > + > + ASSERT_EQ(bss->nr_tcp_ulp, 3, "nr_tcp_ulp"); > +} > + > +void test_setget_sockopt_tcp_ulp(void) > +{ > + cg_fd = test__join_cgroup(CG_NAME); > + if (cg_fd < 0) > + return; > + if (create_netns() && modprobe_tls()) > + goto done; > + skel = setget_sockopt_tcp_ulp__open(); > + if (!ASSERT_OK_PTR(skel, "open skel")) > + goto done; > + if (!ASSERT_OK(setget_sockopt_tcp_ulp__load(skel), "load skel")) > + goto done; > + skel->links.skops_sockopt_tcp_ulp = > + bpf_program__attach_cgroup(skel->progs.skops_sockopt_tcp_ulp, cg_fd); > + if (!ASSERT_OK_PTR(skel->links.skops_sockopt_tcp_ulp, "attach_cgroup")) > + goto done; > + test_tcp_ulp(AF_INET); > + test_tcp_ulp(AF_INET6); > +done: > + setget_sockopt_tcp_ulp__destroy(skel); > + close(cg_fd); > +} > diff --git a/tools/testing/selftests/bpf/progs/setget_sockopt_tcp_ulp.c b/tools/testing/selftests/bpf/progs/setget_sockopt_tcp_ulp.c > new file mode 100644 > index 000000000000..bd1009766463 > --- /dev/null > +++ b/tools/testing/selftests/bpf/progs/setget_sockopt_tcp_ulp.c > @@ -0,0 +1,33 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* Copyright (c) Meta Platforms, Inc. and affiliates. */ Same here. > + > +#include "vmlinux.h" > +#include "bpf_tracing_net.h" > +#include <bpf/bpf_helpers.h> > + > +int nr_tcp_ulp; > + > +SEC("sockops") > +int skops_sockopt_tcp_ulp(struct bpf_sock_ops *skops) > +{ > + static const char target_ulp[] = "tls"; > + char verify_ulp[sizeof(target_ulp)]; > + > + switch (skops->op) { > + case BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB: > + if (bpf_setsockopt(skops, IPPROTO_TCP, TCP_ULP, (void *)target_ulp, > + sizeof(target_ulp)) != 0) > + return 1; > + nr_tcp_ulp++; > + if (bpf_getsockopt(skops, IPPROTO_TCP, TCP_ULP, verify_ulp, > + sizeof(verify_ulp)) != 0) > + return 1; > + nr_tcp_ulp++; > + if (bpf_strncmp(verify_ulp, sizeof(target_ulp), "tls") != 0) > + return 1; > + nr_tcp_ulp++; > + } > + return 1; > +} > + > +char _license[] SEC("license") = "GPL"; > \ No newline at end of file ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2 2/2] bpf-next: selftest for TCP_ULP in bpf_setsockopt 2025-02-13 23:19 ` Martin KaFai Lau @ 2025-02-28 6:44 ` zhangmingyi 0 siblings, 0 replies; 11+ messages in thread From: zhangmingyi @ 2025-02-28 6:44 UTC (permalink / raw) To: martin.lau Cc: ast, daniel, andrii, song, yhs, john.fastabend, kpsingh, sdf, haoluo, jolsa, bpf, linux-kernel, yanan, wuchangye, xiesongyang, liuxin350, liwei883, tianmuyang, zhangmingyi5 On 2/13/25 3:19 PM, Martin KaFai Lau wrote: > On 2/10/25 5:45 AM, zhangmingyi wrote: > > From: Mingyi Zhang <zhangmingyi5@huawei.com> > > > > We try to use bpf_set/getsockopt to set/get TCP_ULP in sockops, and "tls" > > need connect is established.To avoid impacting other test cases, I > > have written a separate test case file. > > > > Signed-off-by: Mingyi Zhang <zhangmingyi5@huawei.com> > > Signed-off-by: Xin Liu <liuxin350@huawei.com> > > --- > > .../bpf/prog_tests/setget_sockopt_tcp_ulp.c | 78 +++++++++++++++++++ > > .../bpf/progs/setget_sockopt_tcp_ulp.c | 33 ++++++++ > > 2 files changed, 111 insertions(+) > > create mode 100644 tools/testing/selftests/bpf/prog_tests/setget_sockopt_tcp_ulp.c > > create mode 100644 > > tools/testing/selftests/bpf/progs/setget_sockopt_tcp_ulp.c > > > > diff --git > > a/tools/testing/selftests/bpf/prog_tests/setget_sockopt_tcp_ulp.c > > b/tools/testing/selftests/bpf/prog_tests/setget_sockopt_tcp_ulp.c > > new file mode 100644 > > index 000000000000..748da2c7d255 > > --- /dev/null > > +++ b/tools/testing/selftests/bpf/prog_tests/setget_sockopt_tcp_ulp.c > > @@ -0,0 +1,78 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* Copyright (c) Meta Platforms, Inc. and affiliates. */ > > This is not right. > > > + > > +#define _GNU_SOURCE > > +#include <net/if.h> > > + > > +#include "test_progs.h" > > +#include "network_helpers.h" > > + > > +#include "setget_sockopt_tcp_ulp.skel.h" > > + > > +#define CG_NAME "/setget-sockopt-tcp-ulp-test" > > + > > +static const char addr4_str[] = "127.0.0.1"; static const char > > +addr6_str[] = "::1"; static struct setget_sockopt_tcp_ulp *skel; > > +static int cg_fd; > > + > > +static int create_netns(void) > > +{ > > + if (!ASSERT_OK(unshare(CLONE_NEWNET), "create netns")) > > + return -1; > > + if (!ASSERT_OK(system("ip link set dev lo up"), "set lo up")) > > + return -1; > > + return 0; > > +} > > + > > +static int modprobe_tls(void) > > +{ > > + if (!ASSERT_OK(system("modprobe tls"), "tls modprobe failed")) > > + return -1; > > + return 0; > > +} > > + > > +static void test_tcp_ulp(int family) > > First, the bpf CI still fails to compile for the same reason as v1. You should > have received an email from bpf CI bot. Please ensure it is addressed first > before reposting. This repeated bpf CI error is an automatic nack. > I'm sorry I didn't notice this and I'll fix this in the next patch > pw-bot: cr > > The subject tagging should be "[PATCH v2 bpf-next ...] selftests/bpf: ... ". > There are many examples to follow in the mailing list if it is not clear. > > Regarding the v1 comment: "...separate it out into its own BPF program..." > > The comment was made at the bpf prog file, "progs/setget_sockopt.c". I meant > only create a separate bpf program. The user space part can stay in > prog_tests/setget_sockopt.c. > > Move this function, test_tcp_ulp, to prog_tests/setget_sockopt.c. Then all the > above config preparation codes and the test_setget_sockopt_tcp_ulp() can be > saved. modprobe_tls() is not needed also. Do it after the test_ktls(). > Take a look at test_nonstandard_opt() in prog_tests/setget_sockopt.c. > It is testing another bpf prog in the same prog_tests/setget_sockopt.c. > Well, it seems that I misunderstood you, and I'll change it according to your intentions. > Also, for the bpf prog, do you really need to test at > BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB? If not, just testing at > SEC("lsm_cgroup/socket_post_create") will be easier. You can detach the > previously attached skel->links.socket_post_create by using bpf_link__destroy() > first and then attach yours bpf prog to do the test. My idea is that since tls needs to be setockopt after the link is established, it would be easier for me to test BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB in sockops ebpf program. > > +{ > > + struct setget_sockopt_tcp_ulp__bss *bss = skel->bss; > > + int sfd, cfd; > > + > > + memset(bss, 0, sizeof(*bss)); > > + sfd = start_server(family, SOCK_STREAM, > > + family == AF_INET6 ? addr6_str : addr4_str, 0, 0); > > + if (!ASSERT_GE(sfd, 0, "start_server")) > > + return; > > + > > + cfd = connect_to_fd(sfd, 0); > > + if (!ASSERT_GE(cfd, 0, "connect_to_fd_server")) { > > + close(sfd); > > + return; > > + } > > + close(sfd); > > + close(cfd); > > + > > + ASSERT_EQ(bss->nr_tcp_ulp, 3, "nr_tcp_ulp"); } > > + > > +void test_setget_sockopt_tcp_ulp(void) { > > + cg_fd = test__join_cgroup(CG_NAME); > > + if (cg_fd < 0) > > + return; > > + if (create_netns() && modprobe_tls()) > > + goto done; > > + skel = setget_sockopt_tcp_ulp__open(); > > + if (!ASSERT_OK_PTR(skel, "open skel")) > > + goto done; > > + if (!ASSERT_OK(setget_sockopt_tcp_ulp__load(skel), "load skel")) > > + goto done; > > + skel->links.skops_sockopt_tcp_ulp = > > + bpf_program__attach_cgroup(skel->progs.skops_sockopt_tcp_ulp, cg_fd); > > + if (!ASSERT_OK_PTR(skel->links.skops_sockopt_tcp_ulp, "attach_cgroup")) > > + goto done; > > + test_tcp_ulp(AF_INET); > > + test_tcp_ulp(AF_INET6); > > +done: > > + setget_sockopt_tcp_ulp__destroy(skel); > > + close(cg_fd); > > +} > > diff --git > > a/tools/testing/selftests/bpf/progs/setget_sockopt_tcp_ulp.c > > b/tools/testing/selftests/bpf/progs/setget_sockopt_tcp_ulp.c > > new file mode 100644 > > index 000000000000..bd1009766463 > > --- /dev/null > > +++ b/tools/testing/selftests/bpf/progs/setget_sockopt_tcp_ulp.c > > @@ -0,0 +1,33 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* Copyright (c) Meta Platforms, Inc. and affiliates. */ > > Same here. > > > + > > +#include "vmlinux.h" > > +#include "bpf_tracing_net.h" > > +#include <bpf/bpf_helpers.h> > > + > > +int nr_tcp_ulp; > > + > > +SEC("sockops") > > +int skops_sockopt_tcp_ulp(struct bpf_sock_ops *skops) { > > + static const char target_ulp[] = "tls"; > > + char verify_ulp[sizeof(target_ulp)]; > > + > > + switch (skops->op) { > > + case BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB: > > + if (bpf_setsockopt(skops, IPPROTO_TCP, TCP_ULP, (void *)target_ulp, > > + sizeof(target_ulp)) != 0) > > + return 1; > > + nr_tcp_ulp++; > > + if (bpf_getsockopt(skops, IPPROTO_TCP, TCP_ULP, verify_ulp, > > + sizeof(verify_ulp)) != 0) > > + return 1; > > + nr_tcp_ulp++; > > + if (bpf_strncmp(verify_ulp, sizeof(target_ulp), "tls") != 0) > > + return 1; > > + nr_tcp_ulp++; > > + } > > + return 1; > > +} > > + > > +char _license[] SEC("license") = "GPL"; > > \ No newline at end of file > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v2 2/2] bpf-next: selftest for TCP_ULP in bpf_setsockopt 2025-02-10 13:45 ` [PATCH v2 2/2] bpf-next: selftest for TCP_ULP in bpf_setsockopt zhangmingyi 2025-02-13 23:19 ` Martin KaFai Lau @ 2025-02-14 17:44 ` kernel test robot 1 sibling, 0 replies; 11+ messages in thread From: kernel test robot @ 2025-02-14 17:44 UTC (permalink / raw) To: zhangmingyi, ast, daniel, andrii, martin.lau, song, yhs, john.fastabend, kpsingh, sdf, haoluo, jolsa Cc: oe-kbuild-all, bpf, linux-kernel, yanan, wuchangye, xiesongyang, liuxin350, liwei883, tianmuyang, zhangmingyi5 Hi zhangmingyi, kernel test robot noticed the following build errors: [auto build test ERROR on bpf-next/master] [also build test ERROR on bpf/master mptcp/export mptcp/export-net linus/master v6.14-rc2 next-20250214] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/zhangmingyi/bpf-next-Introduced-to-support-the-ULP-to-get-or-set-sockets/20250210-215203 base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master patch link: https://lore.kernel.org/r/20250210134550.3189616-3-zhangmingyi5%40huawei.com patch subject: [PATCH v2 2/2] bpf-next: selftest for TCP_ULP in bpf_setsockopt compiler: clang version 19.1.3 (https://github.com/llvm/llvm-project ab51eccf88f5321e7c60591c5546b254b6afab99) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250215/202502150104.1LKDPqiq-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/202502150104.1LKDPqiq-lkp@intel.com/ All errors (new ones prefixed by >>): >> progs/setget_sockopt_tcp_ulp.c:18:42: error: use of undeclared identifier 'TCP_ULP'; did you mean 'MCP_UC'? 18 | if (bpf_setsockopt(skops, IPPROTO_TCP, TCP_ULP, (void *)target_ulp, | ^~~~~~~ | MCP_UC tools/testing/selftests/bpf/tools/include/vmlinux.h:18434:2: note: 'MCP_UC' declared here 18434 | MCP_UC = 2, | ^ progs/setget_sockopt_tcp_ulp.c:22:42: error: use of undeclared identifier 'TCP_ULP'; did you mean 'MCP_UC'? 22 | if (bpf_getsockopt(skops, IPPROTO_TCP, TCP_ULP, verify_ulp, | ^~~~~~~ | MCP_UC tools/testing/selftests/bpf/tools/include/vmlinux.h:18434:2: note: 'MCP_UC' declared here 18434 | MCP_UC = 2, | ^ 2 errors generated. -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2025-02-28 6:47 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-02-10 13:45 [PATCH v2 0/2] bpf-next: Introduced to support the ULP to get or set sockets zhangmingyi 2025-02-10 13:45 ` [PATCH v2 1/2] " zhangmingyi 2025-02-13 23:17 ` Martin KaFai Lau 2025-02-14 2:13 ` kernel test robot 2025-02-14 6:23 ` Martin KaFai Lau 2025-02-14 21:20 ` Jakub Kicinski 2025-02-14 22:11 ` Martin KaFai Lau 2025-02-10 13:45 ` [PATCH v2 2/2] bpf-next: selftest for TCP_ULP in bpf_setsockopt zhangmingyi 2025-02-13 23:19 ` Martin KaFai Lau 2025-02-28 6:44 ` zhangmingyi 2025-02-14 17:44 ` kernel test robot
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).