iSCSI hotremove is broken. It relies on C undefined
behavior. Some bdev_io may be put after their bdev_channel
has been put (freed) and spdk_bdev_put_io may be reading
freed bdev_channel memory.
iSCSI tasks targetting hotremoved devices are finished
immediately. That's usually fine, but these tasks might
be subtasks of an r2t chain. Once subtasks are freed, their
parent task may be eventually freed as well. If the parent
has finished before the hotremoval, its bdev_io has been
assigned, so freeing the task will put that bdev_io and that's
where undefined behavior hits.
There's an ongoing work towards deferring iSCSI hotremove
if r2t tasks are present, so this test should be reenabled
once that's done.
Change-Id: I7fa741b8749d542bcabb211a0969da5d7742eda3
Signed-off-by: Dariusz Stojaczyk <dariuszx.stojaczyk@intel.com>
Reviewed-on: https://review.gerrithub.io/410176
Tested-by: SPDK Automated Test System <sys_sgsw@intel.com>
Reviewed-by: Jim Harris <james.r.harris@intel.com>
Reviewed-by: Daniel Verkamp <daniel.verkamp@intel.com>
331887f7e2