Imagine the following code flow: 1. `spdk_put_io_channel();` 2. `spdk_io_device_unregister();` Since putting an io_channel is always deferred, it is likely that spdk_io_device_unregister will lock the io_channel mutex first. It will set dev->unregistered flag and then quickly realize there are still open channels for this device (refcnt > 0) - so it'll return. All fine here. However, if the deferred put_io_channel happens to lock the mutex first from other thread, it will decrement the refcnt and attempt to free the device. Both the decrementation and freeing are done under a mutex, but there is a slight window inbetween where the mutex is re-locked. spdk_io_device_unregister is already sleeping on a mutex_lock(), so it might strike now. It'll see there are no more io_channels for this device and free the device. Once put_io_channels regains the lock again, it will attempt freeing the device for a second time. This patch removes the slight window mentioned above. Related to #278 Change-Id: I6c0f6014353529028d658211135196d97f1d8547 Signed-off-by: Dariusz Stojaczyk <dariuszx.stojaczyk@intel.com> Reviewed-on: https://review.gerrithub.io/408193 Reviewed-by: Jim Harris <james.r.harris@intel.com> Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com> Tested-by: SPDK Automated Test System <sys_sgsw@intel.com> |
||
---|---|---|
.. | ||
bit_array.c | ||
cpuset.c | ||
crc16.c | ||
crc32_ieee.c | ||
crc32.c | ||
crc32c.c | ||
fd.c | ||
io_channel.c | ||
Makefile | ||
strerror_tls.c | ||
string.c | ||
uuid.c |