[Bug 206310] The vnic driver may lock an uninitialised mutex
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Sat Jan 16 12:31:47 UTC 2016
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206310
Bug ID: 206310
Summary: The vnic driver may lock an uninitialised mutex
Product: Base System
Version: 11.0-CURRENT
Hardware: arm64
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: Andrew at FreeBSD.org
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.
b> bt
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
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the freebsd-bugs
mailing list