Change Details

In some more scenarios, the socket is listening on 127.0.0.1:xxx, and the agent also use 127.0.0.1 to connect to 127.0.0.1:xxx， and it connect more than one TCP session, when use operate to disconnect it, this TCP sockets are close almost at the same time. When TCP socket enter FIN_WAIT_2 state, it activate a TCP timer. So, this sockets activate TCP timer at the same time, all TCP socket have in_pcb data, which have the same inp_infolist member, and tcp_close() cause in_pcbfree() to be called, in_pcbfree() need modify inp_infolist, so it lock it, but it is belonging to clock thread, and it lead in recurse lock. but freebsd14 has removed recurse clock use，so this issue happened. So I suggest temporarily allowing the use of recursive lock before resolve this softclock timer issue. this is my This is a panic stack that I experienced: login: panic: Assertion v != tid failed at /build/workspace/ThinOS-DTOSKernel-FeatureBuild/sys/kern/kern_mutex.c:918 cpuid = 1 time = 1695702213 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0084b1d950 vpanic() at vpanic+0x132/frame 0xfffffe0084b1da80 kassert_panic() at kassert_panic+0x169/frame 0xfffffe0084b1db00 thread_lock_flags_() at thread_lock_flags_+0x14f/frame 0xfffffe0084b1db70 propagate_priority() at propagate_priority+0x89/frame 0xfffffe0084b1dbb0 turnstile_wait() at turnstile_wait+0x39a/frame 0xfffffe0084b1dc00 __mtx_lock_sleep() at __mtx_lock_sleep+0x1cf/frame 0xfffffe0084b1dc90 __mtx_lock_flags() at __mtx_lock_flags+0xf4/frame 0xfffffe0084b1dce0 in_pcbfree() at in_pcbfree+0x6d/frame 0xfffffe0084b1dd10 sorele_locked() at sorele_locked+0xe0/frame 0xfffffe0084b1dd40 tcp_close() at tcp_close+0x1bd/frame 0xfffffe0084b1dd80 tcp_timer_2msl() at tcp_timer_2msl+0xfa/frame 0xfffffe0084b1ddc0 tcp_timer_enter() at tcp_timer_enter+0x15e/frame 0xfffffe0084b1de00 softclock_call_cc() at softclock_call_cc+0x159/frame 0xfffffe0084b1dec0 softclock_thread() at softclock_thread+0xc6/frame 0xfffffe0084b1def0 fork_exit() at fork_exit+0x82/frame 0xfffffe0084b1df30 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0084b1df30 --- trap 0x4be4eec, rip = 0xfc543a65b606aec0, rsp = 0x299e00d45240f769, rbp = 0x9d116aac85d75b20 --- KDB: enter: panic [ thread pid 2 tid 100038 ]

In some more scenarios, the socket is listening on 127.0.0.1:xxx, and the agent also use 127.0.0.1 to connect to 127.0.0.1:xxx，and it connect more than one TCP session, when user operate to trigger disconnect sessions, these TCP sockets are closed almost at the same time. When TCP socket enter FIN_WAIT_2 state, it activate a TCP timer. So, these sockets activate TCP timer at the same time, all TCP sockets have in_pcb data, which has the same inp_infolist member, and tcp_close() cause in_pcbfree() to be called, in_pcbfree() need modify inp_infolist, so it lock it, but it is belonging to clock thread, and it lead in recurse lock. but freebsd14 has removed recurse clock use，so this issue happened. So I suggest temporarily allowing the use of recursive lock before resolve this softclock timer issue. this is my This is a panic stack that I experienced: login: panic: Assertion v != tid failed at /build/workspace/ThinOS-DTOSKernel-FeatureBuild/sys/kern/kern_mutex.c:918 cpuid = 1 time = 1695702213 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0084b1d950 vpanic() at vpanic+0x132/frame 0xfffffe0084b1da80 kassert_panic() at kassert_panic+0x169/frame 0xfffffe0084b1db00 thread_lock_flags_() at thread_lock_flags_+0x14f/frame 0xfffffe0084b1db70 propagate_priority() at propagate_priority+0x89/frame 0xfffffe0084b1dbb0 turnstile_wait() at turnstile_wait+0x39a/frame 0xfffffe0084b1dc00 __mtx_lock_sleep() at __mtx_lock_sleep+0x1cf/frame 0xfffffe0084b1dc90 __mtx_lock_flags() at __mtx_lock_flags+0xf4/frame 0xfffffe0084b1dce0 in_pcbfree() at in_pcbfree+0x6d/frame 0xfffffe0084b1dd10 sorele_locked() at sorele_locked+0xe0/frame 0xfffffe0084b1dd40 tcp_close() at tcp_close+0x1bd/frame 0xfffffe0084b1dd80 tcp_timer_2msl() at tcp_timer_2msl+0xfa/frame 0xfffffe0084b1ddc0 tcp_timer_enter() at tcp_timer_enter+0x15e/frame 0xfffffe0084b1de00 softclock_call_cc() at softclock_call_cc+0x159/frame 0xfffffe0084b1dec0 softclock_thread() at softclock_thread+0xc6/frame 0xfffffe0084b1def0 fork_exit() at fork_exit+0x82/frame 0xfffffe0084b1df30 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0084b1df30 --- trap 0x4be4eec, rip = 0xfc543a65b606aec0, rsp = 0x299e00d45240f769, rbp = 0x9d116aac85d75b20 --- KDB: enter: panic [ thread pid 2 tid 100038 ]

In some more scenarios, the socket is listening on 127.0.0.1:xxx, and the agent also use 127.0.0.1 to connect to 127.0.0.1:xxx， and it connect more than one TCP session, when user operate to trigger disconnect itsessions, thisthese TCP sockets are closed almost at the same time. When TCP socket enter FIN_WAIT_2 state, it activate a TCP timer. So, thisthese sockets activate TCP timer at the same time, all TCP sockets have in_pcb data, which haves the same inp_infolist member, and tcp_close() cause in_pcbfree() to be called, in_pcbfree() need modify inp_infolist, so it lock it, but it is belonging to clock thread, and it lead in recurse lock. but freebsd14 has removed recurse clock use，so this issue happened. So I suggest temporarily allowing the use of recursive lock before resolve this softclock timer issue. this is my This is a panic stack that I experienced: login: panic: Assertion v != tid failed at /build/workspace/ThinOS-DTOSKernel-FeatureBuild/sys/kern/kern_mutex.c:918 cpuid = 1 time = 1695702213 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0084b1d950 vpanic() at vpanic+0x132/frame 0xfffffe0084b1da80 kassert_panic() at kassert_panic+0x169/frame 0xfffffe0084b1db00 thread_lock_flags_() at thread_lock_flags_+0x14f/frame 0xfffffe0084b1db70 propagate_priority() at propagate_priority+0x89/frame 0xfffffe0084b1dbb0 turnstile_wait() at turnstile_wait+0x39a/frame 0xfffffe0084b1dc00 __mtx_lock_sleep() at __mtx_lock_sleep+0x1cf/frame 0xfffffe0084b1dc90 __mtx_lock_flags() at __mtx_lock_flags+0xf4/frame 0xfffffe0084b1dce0 in_pcbfree() at in_pcbfree+0x6d/frame 0xfffffe0084b1dd10 sorele_locked() at sorele_locked+0xe0/frame 0xfffffe0084b1dd40 tcp_close() at tcp_close+0x1bd/frame 0xfffffe0084b1dd80 tcp_timer_2msl() at tcp_timer_2msl+0xfa/frame 0xfffffe0084b1ddc0 tcp_timer_enter() at tcp_timer_enter+0x15e/frame 0xfffffe0084b1de00 softclock_call_cc() at softclock_call_cc+0x159/frame 0xfffffe0084b1dec0 softclock_thread() at softclock_thread+0xc6/frame 0xfffffe0084b1def0 fork_exit() at fork_exit+0x82/frame 0xfffffe0084b1df30 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0084b1df30 --- trap 0x4be4eec, rip = 0xfc543a65b606aec0, rsp = 0x299e00d45240f769, rbp = 0x9d116aac85d75b20 --- KDB: enter: panic [ thread pid 2 tid 100038 ]