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)
