> I hit the hang below and it should be fixed in this set:
>
> https://lore.kernel.org/all/[email protected]/
I hit the hang I described while running a kernel with your fix in. My
hang does not involve scsi-eh; it happens when a transport error is
detected by the kernel while iscsid is in the process of handling a
previous transport error. If the second transport error happens at an
unlucky timing (after iscsid does start_conn when handling the first
error, but before it sets the device state to running via sysfs), the
device queues can be quiesced (in the block layer sense) when iscsid
writes to sysfs and ends up in scsi_rescan_device.
I wanted to avoid this by just removing the write to sysfs from iscsid,
but it seems that interferes with scsi-eh flow:
> The user space online code in your patch handles the scsi-eh case.
So I will need to try another approach. Simply adding a call to
scsi_start_queue like so
if (rescan_dev) {
/* ...
*/
+ scsi_start_queue(sdev);
blk_mq_run_hw_queues(sdev->request_queue, true);
scsi_rescan_device(dev);
}
does not fix the issue either, since your linked patch moves the
run_hw_queues and rescan calls out of the area protected by state_mutex.
A race window still exists where the kernel could detect the second
transport error and quiesce sdev's request queue after we unquiesce it
but before we run the queues and rescan the device above.
It seems that the most straightforward way to fix my issue without
undoing your patch is to add another sync primitive that guards the sdev
queue quiesced/unquiesced state so that we can guarantee the queues are
unquiesced when we do the rescan above. Unless you have other
suggestions, I'll try that approach.
Thanks,
Uday
--
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/open-iscsi/20220829200008.GA442899%40dev-ushankar.dev.purestorage.com.
