b326e51219
Even after the bdev is removed, the underlying virtio device may be still alive for some time. The user may then try to recreate the virtio bdev and could technically initialize a second simultaneous connection to a vhost target. It does not cause any technical problems, but the target may reject such connection if it reached a connection cap or doesn't support more than one connection per target (like SPDK vhost does as of today). Since the fix is straightforward, here it is. Note: Virtio SCSI is already safe, because it uses a separate completion callback to indicate virtio device destruction. Change-Id: I2989780ef9b13c19d0432224ff4602a14be48315 Signed-off-by: Dariusz Stojaczyk <dariuszx.stojaczyk@intel.com> Reviewed-on: https://review.gerrithub.io/420576 Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> Chandler-Test-Pool: SPDK Automated Test System <sys_sgsw@intel.com> Reviewed-by: Changpeng Liu <changpeng.liu@intel.com> Reviewed-by: Ben Walker <benjamin.walker@intel.com> Reviewed-by: Shuhei Matsumoto <shuhei.matsumoto.xt@hitachi.com> |
||
---|---|---|
.. | ||
bdev | ||
blob | ||
blobfs | ||
conf | ||
copy | ||
env_dpdk | ||
event | ||
ioat | ||
iscsi | ||
json | ||
jsonrpc | ||
log | ||
lvol | ||
nbd | ||
net | ||
nvme | ||
nvmf | ||
rocksdb | ||
rpc | ||
scsi | ||
sock | ||
thread | ||
trace | ||
ut_mock | ||
util | ||
vhost | ||
virtio | ||
Makefile |