77573e830e
For correct behaviour, pthread_mutex should not be locked after it has been destroyed. g_bdev_mgr.mutex is statically initialized. It is destroyed in bdev_mgr_unregister_cb, but not re-initialized in spdk_bdev_initialize. Repeated calls to initialize/unregister occur during unit tests. Remove the destroy from bdev_mgr_unregister_cb, which seems the simplest way of resolving the issue. The sequence: spdk_put_io_channel(), spdk_bdev_close(), spdk_bdev_unregister() occurs during unit tests. spdk_bdev_unregister() destroys internal.mutex which is then locked by a call to bdev_channel_destroy() resulting from the earlier spdk_put_io_channel(). Move the destroy and the free of internal.qos into bdev_destroy_cb so that they don't occur until all of the channels have been released. Remove the no longer required bdev_fini. Repeat calls to spdk_bdev_unregister that occur after an unregister has completed will lock internal.mutex which has been destroyed by the previous unregister. This occurs during unit tests. Defer locking internal.mutex until after the internal.status has been checked for SPDK_BDEV_STATUS_REMOVING. This is the only place where internal.status is set to removing and g_bdev_mgr.mutex alone is sufficient to ensure atomicity here. Tested with a pthreads library that contains debugging code to check the mutex state and a modified version of bdev_io_types_test to call get_io_channel on a different thread. Suggested-by: Jim Harris <james.r.harris@intel.com> Signed-off-by: Nick Connolly <nick.connolly@mayadata.io> Change-Id: I81cc46a1b8a766700253829b19cc86c7f0eb79f2 Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/6217 Reviewed-by: Ben Walker <benjamin.walker@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com> Community-CI: Broadcom CI Community-CI: Mellanox Build Bot Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> |
||
---|---|---|
.. | ||
bdev_internal.h | ||
bdev_rpc.c | ||
bdev_zone.c | ||
bdev.c | ||
Makefile | ||
part.c | ||
scsi_nvme.c | ||
spdk_bdev.map | ||
vtune.c |