> Or, is there other ways to hit this that you are seeing? If there are > then forget what I wrote in the last mail :)
No, I don't know of another way to hit this organically. With the change you suggested, if someone sets a scsi device to the "running" state concurrently with the kernel onlining devices (kicked off by iscsid), it's possible that the kernel will observe the current state of the device as SDEV_RUNNING in scsi_internal_device_unblock_nowait. That function will then return -EINVAL and the device queue will remain quiesced. AFAIK there's no way to recover from this situation without a reboot. (This is actually the bug as I encountered it first, in Redhat kernel 4.18.0-348.20.1). This is not a great situation, but maybe it can be argued that if you're fiddling with things in sysfs you should really know what you're doing, and avoid doing stuff like this. I did write up the change you suggested though, and a couple of questions before I mail it here and to linux-scsi: - Can I credit you as "Suggested-by" ? - Currently I only have the new capability in TCP's iscsi_transport struct, because that's the one I care about. But I think it should go everywhere? -- 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/20220908182252.GA3378789%40dev-ushankar.dev.purestorage.com.
