Hannes Reinecke wrote:
>> scsi-ml eh only allows one eh operation, and injecting tmfs tries to
>> only allow one (there is a race though).
>>
> Yes, but this disregards user-space initiated resets.


Yes, the scsi-ml comment disregards userspace.

The injecting tmfs comment is about injecting the tmfs from userspace. 
scsi_reset_provider sets tmf_in_progress, so later if another call to 
scsi_nonblockable_ioctl is called scsi_block_when_processing_errors will 
wait for the running tmf to complete. Or in sg.c's case it calls 
scsi_block_when_processing_errors and scsi_reset_provider itself.

Either way the locking kinda sucks since it looks like it was trying to 
only allow one TMF to be injected at a time, but we can end up getting 
multiple ones sometimes. scsi_reset_provider sets tmf_in_progress, but 
before it has done this another call could have passed the 
scsi_block_when_processing_errors call so we could get multiple resets 
going.

I thought I asked before if we should just fix the locking with 
scsi_block_when_processing_errors/scsi_reset_provider so we only allow 
one tmf like was probably intended. Or, we maybe we should remove that 
code since it probably does not work as intended. And then we can make 
iscsi able to handle multiple tmfs like you really want.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~----------~----~----~----~------~----~------~--~---

Reply via email to