Hi, First of all, that’s just a test tool that forces closing of sessions by “faking” a transport close request. It can potentially lead to other issues if afterwards the app calls the wrong apis into the transport. It shouldn’t be used on production traffic.
Having said that, your problem is probably solved by this [1]. That is, we know the thread for the session/ctx, so we can use the explicit api. Florin [1] https://gerrit.fd.io/r/c/vpp/+/22674 > On Oct 11, 2019, at 6:24 AM, jiangxiaom...@outlook.com wrote: > > code: g...@github.com:FDio/vpp.git <mailto:g...@github.com:FDio/vpp.git> > master : 1a41a35b27da6921d6d86a9f1ad5f1b46e1185f7 > > if i close tls session which is not in thread 0, VPP will assert error. > Below is more Info: > > > DBGvpp# sh session verbose > > Connection State Rx-f > Tx-f > > [0:0][CT:J] 0.0.0.0:5005->0.0.0.0:0 LISTEN 0 0 > > > [0:1][TLS] app_wrk 1 engine 2 tcp 0:20 0 > > [0:2][T] 0.0.0.0:5005->0.0.0.0:0 LISTEN 0 0 > > > Thread 0: active sessions 3 > > > Connection State Rx-f > Tx-f > > [1:0][T] 192.168.7.100:5005->192.168.7.101:54206 ESTABLISHED 0 0 > > > [1:1][TLS] app_wrk 1 index 0 engine 2 tcp 1:0 state: 4 0 0 > > > Thread 1: active sessions 2 > > DBGvpp# clear session thread 1 session 0 > > 0: /home/dev/code/vpp-master/src/plugins/tlsopenssl/tls_openssl.c:72 > (openssl_ctx_get) assertion `! pool_is_free > (openssl_main.ctx_pool[vlib_get_thread_index ()], _e)' fails > > Program received signal SIGABRT, Aborted. > > 0x00007ffff4a12337 in __GI_raise (sig=sig@entry=6) at > ../nptl/sysdeps/unix/sysv/linux/raise.c:55 > > 55 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); > > Missing separate debuginfos, use: debuginfo-install > libgcc-4.8.5-39.el7.x86_64 libuuid-2.23.2-61.el7.x86_64 > numactl-libs-2.0.12-3.el7.x86_64 > > (gdb) bt > > #0 0x00007ffff4a12337 in __GI_raise (sig=sig@entry=6) at > ../nptl/sysdeps/unix/sysv/linux/raise.c:55 > > #1 0x00007ffff4a13a28 in __GI_abort () at abort.c:90 > > #2 0x000000000040765a in os_panic () at > /home/dev/code/vpp-master/src/vpp/vnet/main.c:355 > > #3 0x00007ffff585ab29 in debugger () at > /home/dev/code/vpp-master/src/vppinfra/error.c:84 > > #4 0x00007ffff585aef8 in _clib_error (how_to_die=2, function_name=0x0, > line_number=0, fmt=0x7fffc9a96a40 "%s:%d (%s) assertion `%s' fails") at > /home/dev/code/vpp-master/src/vppinfra/error.c:143 > > #5 0x00007fffc9a9110e in openssl_ctx_get (ctx_index=0) at > /home/dev/code/vpp-master/src/plugins/tlsopenssl/tls_openssl.c:71 > > #6 0x00007ffff747f20b in tls_ctx_get (ctx_handle=1073741824) at > /home/dev/code/vpp-master/src/vnet/tls/tls.c:298 > > #7 0x00007ffff747f522 in tls_session_disconnect_callback > (tls_session=0x7fffdaaa54c0) at > /home/dev/code/vpp-master/src/vnet/tls/tls.c:389 > > #8 0x00007ffff7445b9a in app_worker_close_notify (app_wrk=0x7fffda55d280, > s=0x7fffdaaa54c0) at > /home/dev/code/vpp-master/src/vnet/session/application_worker.c:324 > > #9 0x00007ffff744a45b in clear_session (s=0x7fffdaaa54c0) at > /home/dev/code/vpp-master/src/vnet/session/session_cli.c:594 > > #10 0x00007ffff744a681 in clear_session_command_fn (vm=0x7ffff66b3d80 > <vlib_global_main>, input=0x7fffda82af00, cmd=0x7fffda3ff2c0) at > /home/dev/code/vpp-master/src/vnet/session/session_cli.c:635 > > #11 0x00007ffff63c5105 in vlib_cli_dispatch_sub_commands (vm=0x7ffff66b3d80 > <vlib_global_main>, cm=0x7ffff66b3fb0 <vlib_global_main+560>, > input=0x7fffda82af00, parent_command_index=59) at > /home/dev/code/vpp-master/src/vlib/cli.c:645 > > #12 0x00007ffff63c4f9a in vlib_cli_dispatch_sub_commands (vm=0x7ffff66b3d80 > <vlib_global_main>, cm=0x7ffff66b3fb0 <vlib_global_main+560>, > input=0x7fffda82af00, parent_command_index=0) at > /home/dev/code/vpp-master/src/vlib/cli.c:606 > > #13 0x00007ffff63c5530 in vlib_cli_input (vm=0x7ffff66b3d80 > <vlib_global_main>, input=0x7fffda82af00, function=0x7ffff646b44c > <unix_vlib_cli_output>, function_arg=0) at > /home/dev/code/vpp-master/src/vlib/cli.c:746 > > #14 0x00007ffff6471626 in unix_cli_process_input (cm=0x7ffff66b4720 > <unix_cli_main>, cli_file_index=0) at > /home/dev/code/vpp-master/src/vlib/unix/cli.c:2572 > > #15 0x00007ffff6472198 in unix_cli_process (vm=0x7ffff66b3d80 > <vlib_global_main>, rt=0x7fffda7ea000, f=0x0) at > /home/dev/code/vpp-master/src/vlib/unix/cli.c:2688 > > #16 0x00007ffff6412884 in vlib_process_bootstrap (_a=140736833976688) at > /home/dev/code/vpp-master/src/vlib/main.c:1472 > > #17 0x00007ffff587b9a0 in clib_calljmp () from > /home/dev/code/vpp-master/build-root/install-vpp_debug-native/vpp/lib/libvppinfra.so.20.01 > > #18 0x00007fffd8fef940 in ?? () > > #19 0x00007ffff641298c in vlib_process_startup (vm=0x7ffff66b3d80 > <vlib_global_main>, p=0x267, f=0x0) at > /home/dev/code/vpp-master/src/vlib/main.c:1494 > > The reason is that: > tls_ctx_t struct is create in openssl_main.ctx_pool[1], but when close form > cli, it search from openssl_main.ctx_pool[0], and lead to crash > > The ctx_index isi 32bits, and can support 4Gs ctx, but in practice we not > need so much. > I think we can use the high 8bits for thread info, and left 24bits for pool > index, because 4Ms ctx is already enough! > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > > View/Reply Online (#14164): https://lists.fd.io/g/vpp-dev/message/14164 > Mute This Topic: https://lists.fd.io/mt/34487071/675152 > Group Owner: vpp-dev+ow...@lists.fd.io > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [fcoras.li...@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#14167): https://lists.fd.io/g/vpp-dev/message/14167 Mute This Topic: https://lists.fd.io/mt/34487071/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
