On 8/29/22 4:51 PM, Uday Shankar wrote: >> So we could just add a CAP_SCSI_EH_TRANSPORT OFFLINE flag to >> the iscsi_transport->caps struct. When userspace sees that then >> it knows the kernel will now do the right thing. >> >> The drawback is that we have to patch userspace and then also >> get the the new CAP_SCSI_EH_TRANSPORT_OFFLINE patch in the stable >> kernels. > > Another drawback of this approach is that we are covering up a bug in > the kernel, which is still possible to hit if someone/something besides
I'm still not sure if it's a bug in the kernel or not. I've been thinking it's not a kernel bug. Maybe it depends on if you feel there was a guarantee that writing to that file was non-blocking. If so, then yeah I think it's a kernel bug that we now do all this new work from that call. I don't think there is anything that documents the behavior for that sysfs file though. If there was no guarantee, then I think it's an issue with our design where we assumed it was non-blocking from reading the kernel code and thinking that was always going to be the case. If writing to that file is allowed to block, then our design is wrong since we can't be sleeping in that main thread. > iscsid decides to write to the sysfs state field at the unlucky timing. > Not sure how much we care about this. If it's considered a non-issue, > then I'll put together the change you described and send it to > linux-scsi as well. > > 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 open-iscsi+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/open-iscsi/9c5a4232-5933-35c7-ac5d-745138de49a9%40oracle.com.
