If you configure the ThunderX vnic with iovctl -C, then before using it delete the children the kernel will panic with NULL pointer dereference in __mtx_lock_sleep.
The issue is nicvf_free_cmp_queue will attempt to lock it's mutex, however the mutex may not have been initialised. The call to mtx_init is in nicvf_init_cmp_queue, this seems to only be called when ioctl configures the interface.
There is a second issue where, if nicvf_alloc_resources fails we could call nicvf_free_cmp_queue where the queue_set may have not been initialised.
I would expect a correct solution will have either the nicvf_free_* functions will handle being called on when the object they are freeing has not been initialised, or they will not be called when this is the case.
The stacktrace is as follows.
Tracing pid 9149 tid 100575 td 0xffffffc0540e8000
db_trace_self() at db_stack_trace+0xf0
pc = 0xffffff80005af4e4 lr = 0xffffff8000072440
sp = 0xffffff87ccb4ae90 fp = 0xffffff87ccb4aec0
db_stack_trace() at db_command+0x248
pc = 0xffffff8000072440 lr = 0xffffff80000720cc
sp = 0xffffff87ccb4aed0 fp = 0xffffff87ccb4afb0
db_command() at db_command_loop+0x60
pc = 0xffffff80000720cc lr = 0xffffff8000071e68
sp = 0xffffff87ccb4afc0 fp = 0xffffff87ccb4afe0
db_command_loop() at db_trap+0xf0
pc = 0xffffff8000071e68 lr = 0xffffff80000748fc
sp = 0xffffff87ccb4aff0 fp = 0xffffff87ccb4b220
db_trap() at kdb_trap+0x180
pc = 0xffffff80000748fc lr = 0xffffff800030772c
sp = 0xffffff87ccb4b230 fp = 0xffffff87ccb4b290
kdb_trap() at data_abort+0x17c
pc = 0xffffff800030772c lr = 0xffffff80005c2d38
sp = 0xffffff87ccb4b2a0 fp = 0xffffff87ccb4b350
data_abort() at handle_el1h_sync+0x6c
pc = 0xffffff80005c2d38 lr = 0xffffff80005b086c
sp = 0xffffff87ccb4b360 fp = 0xffffff87ccb4b470
handle_el1h_sync() at __mtx_lock_sleep+0x70
pc = 0xffffff80005b086c lr = 0xffffff80002a2a08
sp = 0xffffff87ccb4b480 fp = 0xffffff87ccb4b550
__mtx_lock_sleep() at nicvf_free_resources+0x37c
pc = 0xffffff80002a2a08 lr = 0xffffff80005d059c
sp = 0xffffff87ccb4b560 fp = 0xffffff87ccb4b5c0
nicvf_free_resources() at nicvf_config_data_transfer+0xa2c
pc = 0xffffff80005d059c lr = 0xffffff80005cfad0
sp = 0xffffff87ccb4b5d0 fp = 0xffffff87ccb4b690
nicvf_config_data_transfer() at nicvf_stop_locked+0xc8
pc = 0xffffff80005cfad0 lr = 0xffffff80005ceadc
sp = 0xffffff87ccb4b6a0 fp = 0xffffff87ccb4b6d0
nicvf_stop_locked() at nicvf_detach+0x94
pc = 0xffffff80005ceadc lr = 0xffffff80005cda78
sp = 0xffffff87ccb4b6e0 fp = 0xffffff87ccb4b700
Move to 13.x tracking PR - if we're able to take on work for the Cavium Octeon TX family (i.e., basically embedded ThunderX) this issue will be investigated as part of that work.